Trouble with Cortex-M "Hello World"

[Johannes Pfau via Digitalmars-d]

Am Fri, 03 Apr 2015 07:32:21 +0000
schrieb "Jens Bauer" <doctor at who.no>:

> Well, it seems I found the problem.
> 
> lexer.h, line 203 reads:
> 
>      union
>      {
>          d_int32 int32value;
>          d_uns32 uns32value;
>          d_int64 int64value;
>          d_uns64 uns64value;
>          ...
>          ...
>          ...
>      };
> 
> While this optimization is neat, it does not produce correct code 
> on Big Endian or Mixed Endian platforms.
> 
> If we write a value to int64value and read it from int32value, 
> then it will be 0 always.
> This is because the int32value is always read if the upper 32 
> bits of the int64value is zero.
> And since a Big Endian platform reads the most significant 
> bits/bytes first, they'll read the upper 32 bits, not the lower 
> 32 bits.
> 
> lexer.c:1874; Lexer::number(Token *t) correctly writes n to 
> t->uns64value.
> -But let's take parse.c:6384 - here token.uns32value is read, 
> thus we'll get a zero, no matter which value was written by 
> number(Token *).
> 
> In parse.c:6379 we would get a minus one always.

Nice find. If you open a pull request on
https://github.com/D-Programming-Language/dmd
please notify me (@jpf91). I'll make sure to backport the fix to gdc
once it's been committed to dmd upstream.

> Looking for union-"tricks", I also found ...
> stringtable.c:24 hash will not be the same value on Big Endian, 
> Mixed Endian and Little Endian machines.
> To hash correctly, read one byte at a time, then use bit-shifting 
> by 8 if another byte is to be read.

IIRC it does not really matter if the hash is different here as it's
only used internally in the compiler. So as long as it still hashes
correctly ('no' collisions) it shouldn't matter.