[GP2X] [BUG] byte offset in Type

Started by Sandman, February 06, 2009, 06:57:15 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Sandman

Consider the following code:

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:

====================
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:

====================
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.
-- Sandman

SplinterGU

#1
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
Download Lastest BennuGD Release: http://www.bennugd.org/node/2

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:

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:

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


On GP2X:

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?
-- Sandman

SplinterGU

copy here output of configure and config.log and output of make...
Download Lastest BennuGD Release: http://www.bennugd.org/node/2

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:

======================================
[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:

./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
-- Sandman

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...
Download Lastest BennuGD Release: http://www.bennugd.org/node/2