Page 1 of 1

Development on Big-Endian Platforms

Posted: Wed Mar 09, 2005 12:28 pm
by Krevnik
I discovered a minor issue with bin2o, bin2c, and bin2s. While a great tool, they are written solely for little-endian use. So, when you use these tools on a big-endian system, such as PPC, it creates a byte swapped version of the IRX, which is wrong. Because of this, no IRX merged into an ELF on a PPC system will load on the PS2. I have made a couple of changes to bin2s which makes it platform neutral (but the resulting .s file is much larger, since it simply defines a series of bytes, rather than words). I am doing a couple of things to get the size back down a little, but retain the platform neutrality. Also, I am working on similar patches for bin2o and bin2c.

Also, there are a few module calls in the IOP section of PS2SDK which aren't entirely wired up yet (import stub missing declaration in a header, or vice versa). I have wired up a few of these, and would also like to submit the patch for these as well.

Who should I send the patch to for submission into CVS if it is useful? ;)

Posted: Wed Mar 09, 2005 2:51 pm
by ooPo
Generally you can post a patch here, or if its large you can pop by the irc channel (#ps2dev on efnet) and either ask for cvs write access or for someone to test/merge for you.

Its always good to see someone who tests AND fixes. Welcome to ps2dev! :)

Posted: Wed Mar 09, 2005 3:12 pm
by Guest
As a fellow PPC'er (and there are quite a few of us around) I feel for ya, I run into the same thing alot too. ;)

The main thing is, the x86 architecture is the more common development platform, and it fortunately it is already little-endian. So when people write little utilities that are intended to execute *on* the dev platform, endianness isn't always realized as an important consideration while coding.

Us PPC'ers need to stand tall and beat up the little guys. :)

Posted: Wed Mar 09, 2005 3:35 pm
by Guest
ooPo wrote:... you can pop by the irc channel (#ps2dev on efnet) and either ask for cvs write access or for someone to test/merge for you.
Oh, Oopo didn't mention that thick skin is required on the irc channel. The people on #ps2dev are actually very nice folx, in a playfully trolling sort of way. ;)

Posted: Wed Mar 09, 2005 10:59 pm
by pixel
gorim wrote:Oh, Oopo didn't mention that thick skin is required on the irc channel. The people on #ps2dev are actually very nice folx, in a playfully trolling sort of way. ;)
GRrouummpff?

Okay, seriously, post your patch here, or give it to some random cvs-writer guy in IRC, that'll be commited asap.

But, that doesn't affect bin2c, does it ? Only bin2s should be affected.

Posted: Thu Mar 10, 2005 12:48 am
by Krevnik
I haven't checked bin2c, although bin2s and bin2o are definitely broken on PPC. (bin2o produces a completely unreadable object file on PPC)

I will take a look tonight when I have some time, and make the needed diffs.

Posted: Thu Mar 10, 2005 4:24 am
by pixel
Funny: bin2o is only a script to ee-ld.

Posted: Thu Mar 10, 2005 8:29 am
by Krevnik
Heh, whadda know, it is. Hmm, seems like there was something else interfering, or I was using the wrong nm (dear god, I realized I have over 8 gcc toolchains on this machine, with only ONE per platform, *shudder*). bin2o seems to be working again... odd. Ignore my bin2o complaints. :)

bin2s is still borked, but not for long. It was a pretty simple patch. ;)

Anyways, the patches of work I have done so far... isn't much:

bin2s diff
iop sources diff

Posted: Wed Apr 13, 2005 11:45 am
by rinco

Code: Select all

 		fprintf(dest, "\n\t.byte 0x%02x,0x%02x,0x%02x,0x%02x", 
 			buffer[i], buffer[i+1], buffer[i+2], buffer[i+3]);
i see where you're going with the bin2s patch... but I still seem to get the
wrong order.

however this works for me:

Code: Select all

 		fprintf(dest, "\n\t.byte 0x%02x,0x%02x,0x%02x,0x%02x", 
 			buffer[i+3], buffer[i+2], buffer[i+1], buffer[i]);
but i'm guessing it won't work for the x86 crowd.

perhaps it would be best to use one of the functions from arpa/inet.h?

Posted: Wed Apr 13, 2005 12:01 pm
by Guest
Or you can look at code I included in my PARAM.SFO parsing code on the psp forums that will convert a number into the proper endian version needed.

Posted: Wed Apr 13, 2005 12:38 pm
by rinco
ok this works great, thanks gorim

Code: Select all

diff -u bin2s.c le32_bin2s.c 
--- bin2s.c     Wed Apr 13 12:40:10 2005
+++ le32_bin2s.c        Wed Apr 13 12:40:49 2005
@@ -19,6 +19,15 @@
 
 unsigned char *buffer;
 
+/* For endian neutrality */ 
+u_int32_t le32(u_int32_t bits) 
+{ 
+       u_int8_t *bytes; 
+       bytes = (u_int8_t*)&bits; 
+       return&#40;bytes&#91;0&#93; | &#40;bytes&#91;1&#93;<<8&#41; | &#40;bytes&#91;2&#93;<<16&#41; | &#40;bytes&#91;3&#93;<<24&#41;&#41;; 
+&#125; 
+
+
 int main&#40;int argc, char *argv&#91;&#93;&#41;
 &#123;
        int fd_size;
@@ -65,8 +74,8 @@
        fprintf&#40;dest, "%s&#58;\n\n",argv&#91;3&#93;&#41;;
 
        for&#40;i=0;i<fd_size;i+=4&#41; &#123;
-               if&#40;&#40;i % 16&#41; == 0&#41; fprintf&#40;dest, "\n\t.word 0x%08x", *&#40;int*&#41;&buffer&#91;i&#93;&#41;;
-               else fprintf&#40;dest, ", 0x%08x", *&#40;int*&#41;&buffer&#91;i&#93;&#41;;
+               if&#40;&#40;i % 16&#41; == 0&#41; fprintf&#40;dest, "\n\t.word 0x%08x", le32&#40;*&#40;int*&#41;&buffer&#91;i&#93;&#41;&#41;;
+               else fprintf&#40;dest, ", 0x%08x", le32&#40;*&#40;int*&#41;&buffer&#91;i&#93;&#41;&#41;;
        &#125;
 
        fprintf&#40;dest, "\n"&#41;;