This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: packing/unpacking 4-octet longs
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Cc: twall at oculustech dot com, gdb at sources dot redhat dot com, Richard dot Earnshaw at arm dot com
- Date: Wed, 05 Dec 2001 16:45:39 +0000
- Subject: Re: packing/unpacking 4-octet longs
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
> > 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).
>
> Mutter something about hardware engineers taking short cuts :-)
As opposed to software engineers making invalid assumptions about the
world they operate in :-) In particular, by ignoring bits of the
standards that are inconveniently difficult to deal with...
> I'm
> pretty sure that there is another very old wacko architecture that did
> something similar to this, I'm trying to remember which. pdp11?
> original m68k?
PDP11, I think. It's a bit before my time, but IIRC it's because earlier
PDPS (8? 9?) were 16-bit machines, so there wasn't really any concept of
word-ordering beyond that: 16-bit words were little-endian, but the most
significant word was always at the lowest address (or the other way
around). When the pdp-11 came out, with 32-bit operations, all this
caused carnage. I'm told that it was this that convinced Digital that all
the world would in future be little-endian (and hence, I believe, why MIPS
processors grew a little-endian mode).
> This problem also shows up on hardware that implemented
> big/little endian using xor bits - Arm?
I'm not aware of this affecting the ARM (except in that FPA format doubles
and long doubles always have the word with the exponent at the lowest
address, but there's nothing in the IEEE FP specs that says this is
invalid). In particular, storing a word, or multi-word, at an unaligned
address does not change the order of bytes in memory, so
memcpy(unaligned_address, aligned_address, sizeof(some_word))
does not require diddling with the internal order (or have I misunderstood
the problem?)
R.