Encouraged by Timo Sintonen's great posts, I decided to spend some time trying to build a Cortex-M toolchain for D-programming.
So this morning, I've successfully built my first toolchain supporting C, C++ and D for the first time.
I wanted to take the new language out for a spin, but I ran into some trouble...

Referring to the tutorial on this page:
<http://wiki.dlang.org/Minimal_semihosted_ARM_Cortex-M_%22Hello_World%22>

-I'm getting the following error:

start.d:45:11: error: mismatched array lengths, 0 and 3
   uint[3] message =
           ^

... for this part of the code:

void OnReset()
{
	while(true)
	{
		// Create semihosting message
		uint[3] message =
			[
				2,							// stderr
				cast(uint)"hello\r\n".ptr,	// ptr to string
				7							// size of string
			];
		// Send semihosting command
		SendCommand(0x05, &message);
	}
}

... I've carefully checked the code, but found no difference. Is this the expected behaviour ?
When I change the square brackets to parantheses, the error goes away, but I'm not sure that is the correct fix ?

(I just found out that I should probably have posted this in the digitalmars.D.learn forum instead, sorry for the inconvenience)

I belive the following information is slightly incorrect:
"GDC requires the following minimal object.d file in the same folder as start.d. It is imported automatically."

My tests have shown that object.d needs to be in the CWD, not in the same directory as "start.d".

This is my command-line:

arm-none-eabi-gdc -DF_CPU=48000000 -D__BUILD_WITH_EXAMPLE__=1 -mcpu=cortex-m4 -mthumb -mthumb-interwork -fno-emit-moduleinfo -fdata-sections  -c src/start.d -o output/src/start.o


Here's a summary of the directories when the build works:
./object.d
src/start.d
output/src/start.o

However, the following does not work:
src/object.d
src/start.d
output/src/start.o

-Is this directory behaviour a bug ?

On Tuesday, 31 March 2015 at 10:39:05 UTC, Jens Bauer wrote:

> Referring to the tutorial on this page:
> <http://wiki.dlang.org/Minimal_semihosted_ARM_Cortex-M_%22Hello_World%22>
>
> -I'm getting the following error:
>
> start.d:45:11: error: mismatched array lengths, 0 and 3
>    uint[3] message =
>            ^
[snip]
>
> ... I've carefully checked the code, but found no difference. Is this the expected behaviour ?
> When I change the square brackets to parantheses, the error goes away, but I'm not sure that is the correct fix ?

I just cut and pasted the code from the wiki myself and compiled with my arm-none-eabi-gdc cross-compiler and it works fine.  I'm sorry, but I'm not sure what the problem could be.

Mike

On Tuesday, 31 March 2015 at 11:19:29 UTC, Jens Bauer wrote:
> I belive the following information is slightly incorrect:
> "GDC requires the following minimal object.d file in the same folder as start.d. It is imported automatically."
>
> My tests have shown that object.d needs to be in the CWD, not in the same directory as "start.d".

I don't believe it is the current working directory, but rather the compiler's import path.  See the -I switch.  By default, I believe that is the current working directory.

>
> This is my command-line:
>
> arm-none-eabi-gdc -DF_CPU=48000000 -D__BUILD_WITH_EXAMPLE__=1 -mcpu=cortex-m4 -mthumb -mthumb-interwork -fno-emit-moduleinfo -fdata-sections  -c src/start.d -o output/src/start.o
>
>
> Here's a summary of the directories when the build works:
> ./object.d
> src/start.d
> output/src/start.o
>
> However, the following does not work:
> src/object.d
> src/start.d
> output/src/start.o
>
> -Is this directory behaviour a bug ?

I believe it is working as designed, but I'm not an authority on the compiler.

Mike

"Mike" <none@none.com> writes:

> On Tuesday, 31 March 2015 at 10:39:05 UTC, Jens Bauer wrote:
>
>> Referring to the tutorial on this page: <http://wiki.dlang.org/Minimal_semihosted_ARM_Cortex-M_%22Hello_World%22>
>>
>> -I'm getting the following error:
>>
>> start.d:45:11: error: mismatched array lengths, 0 and 3
>>    uint[3] message =
>>            ^
> [snip]
> I just cut and pasted the code from the wiki myself and compiled with
> my arm-none-eabi-gdc cross-compiler and it works fine.  I'm sorry, but
> I'm not sure what the problem could be.
>
> Mike

Yeah, something strange.  The start.d on the webpage compiles fine for me too.  I am using LDC as cross compiler to ARM, but you should also be able to compile start.d fine with regular dmd too even though it can't target ARM.

It is as if your message array declaration line is being read by compiler as:

    uint[0] message =


>> When I change the square brackets to parantheses, the error goes away, but I'm not sure that is the correct fix ?

Changing the square brackets to parens is doing something different. You do want the square brackets.
--
Dan

On Tuesday, 31 March 2015 at 15:50:17 UTC, Dan Olson wrote:
> "Mike" <none@none.com> writes:
>> I just cut and pasted the code from the wiki myself and compiled with
>> my arm-none-eabi-gdc cross-compiler and it works fine.  I'm sorry, but I'm not sure what the problem could be.
>>
>> Mike
>
> Yeah, something strange.  The start.d on the webpage compiles fine for me too.  I am using LDC as cross compiler to ARM, but you should also be able to compile start.d fine with regular dmd too even though it can't target ARM.
>
> It is as if your message array declaration line is being read by
> compiler as:
>
>     uint[0] message =

I've also tried putting it all on one line, but that didn't help:

src/start.d:46:12: error: mismatched array lengths, 0 and 3
     uint[3]message=[2,cast(uint)"hello\r\n".ptr,7];
            ^

-So it's not because there's a problem with spaces, tabs and linefeeds.

>>> When I change the square brackets to parantheses, the error goes
>>> away, but I'm not sure that is the correct fix ?
>
> Changing the square brackets to parens is doing something different.
> You do want the square brackets.

I expected that. :)

Thank you both Mike and Dan for the replies.

This could be something related to big endian issues, as my compiler is hosted on a big endian machine (PowerMac G5). Note: Just in case it's important; I'm using GCC+GDC, not LLVM+LDC.

I hope I'll be able to make a build on my CubieBoard2, so I can try the test there.

Unfortunately, my attempt to build GDC on my CubieBoard2 failed.

However, I decided to change the line slightly, in order to find out exactly what's going wrong...


src/start.d:46:12: error: mismatched array lengths, 0 and 3
     uint[4]message=[2,cast(uint)"hello\r\n".ptr,7];
            ^
make: *** [output/src/start.o] Error 1

This means that the arry on the right hand side is actually parsed correctly.
It seems that the number [3] or [4] is parsed/read as zero ??

Am Wed, 01 Apr 2015 12:56:22 +0000
schrieb "Jens Bauer" <doctor@who.no>:

> Unfortunately, my attempt to build GDC on my CubieBoard2 failed.
> 
> However, I decided to change the line slightly, in order to find out exactly what's going wrong...
> 
> 
> src/start.d:46:12: error: mismatched array lengths, 0 and 3
>       uint[4]message=[2,cast(uint)"hello\r\n".ptr,7];
>              ^
> make: *** [output/src/start.o] Error 1
> 
> This means that the arry on the right hand side is actually
> parsed correctly.
> It seems that the number [3] or [4] is parsed/read as zero ??

I'm not sure if anybody ever used GDC/DMD/LDC on a big-endian system. It could be an endianess issue somewhere in the code. I debugged a misaligned-access bug in the frontend some time ago, bugs like these can result in the weirdest effects.

It should compile on the cubieboard though. What exactly failed?

On Wednesday, 1 April 2015 at 13:59:34 UTC, Johannes Pfau wrote:
> Am Wed, 01 Apr 2015 12:56:22 +0000
> It could be an endianess issue somewhere in the code. I debugged a misaligned-access bug in the frontend some time ago,
> bugs like these can result in the weirdest effects.

Indeed. I had some strange things happening until OpenOCD had the endian bugs squashed.
Endian problems does not necessarily have to mean crashes; it could just be some data's high an low bytes being swapped.

> It should compile on the cubieboard though. What exactly failed?

building GCC-4.9.2, so this is not an issue with D.
I'll probably be trying to make a build for the next 10 hours.

On my G5, however, I managed to get as complete a build as I could, but it involves compiling GCC 4 times total (!) - This gives me C/C++ and D - including libstdc++! -but it takes a couple of hours. ;)