[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