This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

packing/unpacking 4-octet longs


I'm working on a DSP port (yes, I'm the one tossing the OCTETS_PER_BYTE
strangeness about) and TI has introduced yet another Really Strange Thing.

Longs on this chip are packed little-endian.  No wait, they're packed
big-endian.  No-wait, it's both!

Basically, words are packed little-endian w/r/t octets, but the two words are
big-endian, e.g.

0xaabbccdd is stored as 0xbb 0xaa 0xdd 0xcc.  This I can account for in the
long/float/double packing/unpacking routines (though I'm not sure how I'm
going to make a clean patch yet...).  The problem is that the word order
switches if the value is accessed at an odd address (apparently this made
sense to the hardware designers).  The MS word of a long is always the first
one accessed (they must have forgotten that the chip was little-endian).

Any ideas of how to make this happen?  I remember doing a fix for something
similar way back, but looking at the code now, by the time the data is
packed/unpacked, the target address is long gone.  I doubt I can reliably do
swapping every time I access a 4-octet block of target data.

T.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]