Development on Big-Endian Platforms

Krevnik · Post by **Krevnik** » Wed Mar 09, 2005 12:28 pm

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? ;)

Post by **ooPo** » Wed Mar 09, 2005 2:51 pm

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! :)

Guest · Post by **Guest** » Wed Mar 09, 2005 3:12 pm

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. :)

Guest · Post by **Guest** » Wed Mar 09, 2005 3:35 pm

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. ;)

Post by **pixel** » Wed Mar 09, 2005 10:59 pm

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.

Krevnik · Post by **Krevnik** » Thu Mar 10, 2005 12:48 am

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.

Post by **pixel** » Thu Mar 10, 2005 4:24 am

Funny: bin2o is only a script to ee-ld.

Krevnik · Post by **Krevnik** » Thu Mar 10, 2005 8:29 am

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

rinco · Post by **rinco** » Wed Apr 13, 2005 11:45 am

Code: Select all

 		fprintf&#40;dest, "\n\t.byte 0x%02x,0x%02x,0x%02x,0x%02x", 
 			buffer&#91;i&#93;, buffer&#91;i+1&#93;, buffer&#91;i+2&#93;, buffer&#91;i+3&#93;&#41;;

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&#40;dest, "\n\t.byte 0x%02x,0x%02x,0x%02x,0x%02x", 
 			buffer&#91;i+3&#93;, buffer&#91;i+2&#93;, buffer&#91;i+1&#93;, buffer&#91;i&#93;&#41;;

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?

Guest · Post by **Guest** » Wed Apr 13, 2005 12:01 pm

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.

rinco · Post by **rinco** » Wed Apr 13, 2005 12:38 pm

ok this works great, thanks gorim

Code: Select all

diff -u bin2s.c le32_bin2s.c 
--- bin2s.c     Wed Apr 13 12&#58;40&#58;10 2005
+++ le32_bin2s.c        Wed Apr 13 12&#58;40&#58;49 2005
@@ -19,6 +19,15 @@
 
 unsigned char *buffer;
 
+/* For endian neutrality */ 
+u_int32_t le32&#40;u_int32_t bits&#41; 
+&#123; 
+       u_int8_t *bytes; 
+       bytes = &#40;u_int8_t*&#41;&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;;