[Coco] CCASM for Linux

KnudsenMJ at aol.com KnudsenMJ at aol.com
Sun Dec 12 23:32:12 EST 2004


 
In a message dated 12/12/04 11:04:32 PM Eastern Standard Time,  
mannslists at invigorated.org writes:

I've  seen people build in to their programs the capabilities to deal
with both  big and little endian issues. Maybe a separate function
dealing with the  issue based on input. But, for some reason unknown to
me, they never did  use the built in code and kept the thing x86 only.



Well, I think my UltiMusE source is now endian-independent.  You just  
#define a flag that tells whether it's for a Moto or x86.
 
First, my buddy and I took the various places where I was using cute  
byte-pointer casts (in C) to shift bytes around in integers, and converted them  to 
machine-independent shifts and masks.  Slower and bigger code, but this  ain't 
the Coco anymore :-)
 
Second, I wrote a set of byte-swabbers to convert shorts and ints between  
endian formats.
These are applied to shorts and integers before and after I/O operations --  
the legacy is that all my disk file formats are Moto-endian, so the x86 had to 
 deal with those.
 
When compiling for a big-endian (a la Moto) CPU, the macro switch just  
blanks out the code for these swabbing routines.
 
Actually, I wrote the swabbing functions when I ported UltiMusE from 6809  
and 68K to Linux on an Intel PC.  It was my buddy's idea to put the #ifdef  
wrappers around the swabbers, to turn them back off for his PPC (as in Moto)  Mac.
 
Top sum up -- there's no valid excuse for leaving endian dependencies in  
source code, unless you want ti to compile efficiently on the Coco as  well.
--Mike K.
 



More information about the Coco mailing list