[GP2X] [BUG] byte offset in Type

[Sandman]

Consider the following code:

Code Select Expand


import "mod_say"

Type _test
byte b; // important! causes the bug
int i;
End

Process Main()
Begin
test(1);
test(2);
test(3);
test(4);
test(5);
test(256);
test(65536);
test(16777216);
End

Function int test(int i)
Private
_test t;
Begin
t.i = i;
say("====================");
say("i = " + i);
say("t.i = " + t.i);
End


On Windows this produces:

Code Select Expand


====================
i = 1
t.i = 1
====================
i = 2
t.i = 2
====================
i = 3
t.i = 3
====================
i = 4
t.i = 4
====================
i = 5
t.i = 5
====================
i = 256
t.i = 256
====================
i = 65536
t.i = 65536
====================
i = 16777216
t.i = 16777216


On GP2X this produces:

Code Select Expand


====================
i = 1
t.i = 16777216
====================
i = 2
t.i = 33554432
====================
i = 3
t.i = 50331648
====================
i = 4
t.i = 67108864
====================
i = 5
t.i = 83886080
====================
i = 256
t.i = 1
====================
i = 65536
t.i = 256
====================
i = 16777216
t.i = 65536


Now, x86 is little endian, but ARM can be switched between big and little. It is possible that I should use some compile flag somewhere, but I doubt it, as it doesn't look like an endian-bug to me (the bytes are shifted 1, not reversed). So this leaves the possibility that there is a bug in Bennu. Notice that the Type test has a byte before the int, this is important.

[SplinterGU]

I don't know... you know that I don't compile Bennu in gp2x... you did...
but, yes... is byteorder bug... if you compile your dcb in little endian you can't use it in big endian... or big->little... the save/load dcb byteorder is incomplete.
maybe you must include an exception in configure (configure.ac) for gp2x with right flag that use same byte order like x86

[Sandman]

The default endianness of ARM is little, just like x86. The binaries are also in little endian, so I don't think that's the problem. Moreover, the bytes seem to be shifted and not reversed.

Consider the following code:

Code Select Expand


import "mod_say"

Process Main()
Private
int i;
byte* b;
Begin
i = 1 + 2*256 + 3 * 65536 + 4 * 16777216;
b = &i;
say("b[0] = " + b[0]);
say("b[1] = " + b[1]);
say("b[2] = " + b[2]);
say("b[3] = " + b[3]);
End

This will separate little endian from big endian, right?

On Windows:

Code Select Expand


b[0] = 1
b[1] = 2
b[2] = 3
b[3] = 4


On GP2X:

Code Select Expand


b[0] = 1
b[1] = 2
b[2] = 3
b[3] = 4


So, well, I don't know what's going on; if I did, I wouldn't be posting here. ;) Could you just doublecheck if the Bennu code is really correct?

[SplinterGU]

copy here output of configure and config.log and output of make...

[Sandman]

I did not compile it using configure and make, I compiled it using Code Blocks and the official GP2XSDK, but you can see the log of this build in the attachments. You will also find the Bennu code, C code and the output when Bennu is run. Moreover you will find the output of the failed configure and config.log.

Output:

Code Select Expand


======================================
[B] i = 33554433
[B] b.i[0] = 1
[B] b.i[1] = 0
[B] b.i[2] = 0
[B] b.i[3] = 2
====================
[B] t.b = 1
[B] t.b[0] = 1
[B] t.b[1] = 0
[B] t.b[2] = 0
[B] t.b[3] = 2
[B] t.i = 16908288
[B] b.i[0] = 0
[B] b.i[1] = 0
[B] b.i[2] = 2
[B] b.i[3] = 0
====================
[C] z->b = 1
[C] z->b[0] = 1
[C] z->b[1] = 0
[C] z->b[2] = 0
[C] z->b[3] = 2
[C] z->i = 0
[C] z->i[0] = 0
[C] z->i[1] = 0
[C] z->i[2] = 0
[C] z->i[3] = 0
====================
[C] i[0] = 1
[C] i[1] = 0
[C] i[2] = 0
[C] i[3] = 0
[C] z->b = 0
[C] z->b[0] = 0
[C] z->b[1] = 0
[C] z->b[2] = 0
[C] z->b[3] = 0
[C] z->i = 4
[C] z->i[0] = 4
[C] z->i[1] = 0
[C] z->i[2] = 0
[C] z->i[3] = 0
[B] t.b = 0
[B] t.b[0] = 0
[B] t.b[1] = 0
[B] t.b[2] = 0
[B] t.b[3] = 0
[B] t.i = 0
[B] b.i[0] = 0
[B] b.i[1] = 0
[B] b.i[2] = 0
[B] b.i[3] = 4
*/

In C everything is OK, but Bennu just reads the memory differently. I checked that __BYTEORDER is indeed __LIL_ENDIAN.

I tried compiling Bennu using configure and make, but it did not work. You got the SDK too, so if you compile it yourself, then I will check this again with your version. To 'install' the SDK for MSYS is not hard; all I did was add Tools/bin (containing arm-gp2x-linux.gcc.exe) to the PATH, Tools/arm-gp2x-linux/lib to LDFLAGS, adding Tools/arm-gp2x-linux/include to CPPFLAGS and setting CFLAGS to "-O2". Maybe I missed something, though, because configure complains it cannot find zlib (though with the EXACT same call to arm-gp2x-linux-gcc.exe, there is no problem).
How I tried configure:

Code Select Expand


./configure --prefix=/d/GP2XSDK/Tools/arm-gp2x-linux/ --host=arm-gp2x-linux
./configure --prefix=/d/gp2x/root --host=arm-gp2x-linux

d/gp2x/root is an empty directory.
It also can't find libdl it seems, so I don't know what this configure is thinking...

PS: please enable to use of .prg as attachments and maybe .c too

[SplinterGU]

well... I can't see it next days...
but if zlib is the problem you must put an exception for gp2x in configure...
please forget codeblocks... configure dectect stuffs that if you want do it manual is very hard...