Byte order (retitled)

[Thomas H{meenaho]

In article <7046 at cca.UUCP> g-rh at cca.UUCP (Richard Harter) writes:

>	Consider the following problem.  You have an array of 4 byte
>integers.  If you sort the array numerically you get one result.  If
>you regard the bytes as characters and sort them lexicographically on
>a little endian machine you get a different result.  The reason is that
>the most signifigant byte occupies the eight least signifigant bits.
>Consistency of signifigance requires that the direction of signifigance
>be the same for both bytes and bits.
>

	[Deleted text]

>In short, little-endian was a mistake, is a mistake, and will continue
>to be a mistake.
>
>		Richard Harter, SMDS Inc.


I think big-endians was and is a mistake. The only advantage with them is
that it's easy to read a hex dump!

I don't think people usually compare text strings word-wise so that is a
pretty weak argument.

What I find more significant is when you type-cast different types of
integers into other sized integers.
If for instance you have a long and want to convert it to a short, you just
have to read it as a short on a little-endian whereas on a big-endian you
have to adjust the address before you can read it.

I also think Motorola would have made the 68k a little-endian if they were
to design it from scratch knowing what they know today. The 68020 is a
pretty hefty processor but the dynamic bus sizing stinks. It can dynamically
(on a cycle by cycle basis) adjust to data busses varying from 8 to 32 bits.
But as the processor always assume it will get a 32 bit word when it tries
to read one you'll have to put the data on the top bits if you have a 
narrower bus as it is the most significant part that comes first! 
If you give the processor 8 bits you'll have to put it on D24-D31. 
And for 16 bits on D16-D31.
-- 
Thomas Hameenaho, Dept. of Computer Science, Uppsala University, Sweden
Phone: +46 18 138650
UUCP: thomas at kuling.UUCP (...!{seismo,mcvax}!enea!kuling!thomas)