Re: packing/unpacking 4-octet longs

[Richard Earnshaw <rearnsha@arm.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.