Trouble with Cortex-M "Hello World"
Jens Bauer via Digitalmars-d
digitalmars-d at puremagic.com
Fri Apr 3 00:32:21 PDT 2015
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.
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.
More information about the Digitalmars-d
mailing list