Forums

Big-Endian vs. Little-Endian

Started by Everett M. Greene August 20, 2004
Hans-Bernhard Broeker wrote:
> [...]
> That sait, there was one real argument in favour of one side. It > favoured little-endian, and has long since been obliterated by CPU > engineering. It applied in situations where three conditions held: > > 1) memory is narrower than arithmetic registers > 2) key ALU building blocks (adders, shifters, the likes) are > narrower than CPU registers, so operations take several cycles > through them, passing around carry bits. > 3) memory can be read "forward" faster than "backward" > > In this situation, doing little-endian allows to intermix ALU cycles > and memory fetches, and can thus be noticeably faster than big-endian. > The difference will be governed by the speed penalty for stepping > through address space in the "wrong" direction.
There is another small advantage of little-endian: if you have a pointer to an integer variable that has size N it is at the same time could be interpreted as pointer to a variable of the smaller size (given that variable value is small anough to fit). Michael Furman
"Michael N. Moran" <mike@mnmoran.org> writes:
> Stephen Pelc wrote: > > mojaveg@mojaveg.iwvisp.com (Everett M. Greene) wrote: > > > >>Now that you're talking about the question I raised, which > >>choice do people make when they have a free choice? > > > > The only application we've found where endianness might matter > > is for a comms stack where the protocol defines data to be in > > a particular (usually big-endian) format. > > And then there is the USB, which is little-endian. > IIRC, at least one of the descriptors has unaligned > members as well.
USB was originally described by Intel, so what would you expect? Did you ever get the feeling that the first Little-Endian machine was a mistake and rather than correct the error, it was decided to market it as a FUG? [FUG = "it's a feature, not a bug"]
Michael Furman <MichaelFurman@yahoo.com> wrote:

> There is another small advantage of little-endian: if you have a > pointer to an integer variable that has size N it is at the same > time could be interpreted as pointer to a variable of the smaller > size (given that variable value is small anough to fit).
That rests on the assumption that the pointer to the big thing must obviously have the last few bits zeroed. If you've seen Prof. Knuth's MMIX, you know that's not strictly a necessity --- MMIX just ignores all bits of an address that would lead to non-aligned addresses for objects larger than one "machine word". In that scheme, the lowermost bits of the pointer to a N-byte integer could just as well all be ones, and using that as a pointer-to-byte would still give you the lowermost one. But this really is all moot, because effective memory width is at least as big as the CPU's registers, if not wider, these days. -- Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de) Even if all the snow were burnt, ashes would remain.
Everett M. Greene wrote:
> "Michael N. Moran" <mike@mnmoran.org> writes: >>And then there is the USB, which is little-endian. >>IIRC, at least one of the descriptors has unaligned >>members as well. > > USB was originally described by Intel, so what would you > expect?
Oh ... I got what I expected ;-) [Off-topic] In all fairness, however, I think that much of the USB design is quite good. In particular, the various service types (bulk,interrupt,control,isochronous) are IMHO, well considered. I find it "funny" that most vendors (or is it their engineering staff) use bulk transport for almost everything, even when there are more appropriate mechanisms. I suspect it is because of familiarity with the operation of UART serial ports that the USB is to replace.
> Did you ever get the feeling that the first Little-Endian > machine was a mistake and rather than correct the error, > it was decided to market it as a FUG? [FUG = "it's a > feature, not a bug"]
For better or worse, business decisions rule. It's a money thing ... I wouldn't understand ;-) -- Michael N. Moran (h) 770 516 7918 5009 Old Field Ct. (c) 678 521 5460 Kennesaw, GA, USA 30144 http://mnmoran.org "... abstractions save us time working, but they don't save us time learning." Joel Spolsky, The Law of Leaky Abstractions The Beatles were wrong: 1 & 1 & 1 is 1
On 24 Aug 2004 18:11:50 GMT, Hans-Bernhard Broeker
<broeker@physik.rwth-aachen.de> wrote:


>But this really is all moot, because effective memory width is at >least as big as the CPU's registers, if not wider, these days.
This is definitely not the case for such typical mobile devices as cell phones, where a 32-bit ARM CPU has a 16-bit external bus. The narrow bus saves power and perhaps size/weight, critical factors in advanced handheld devices. -- Jim McGinnis
On 24 Aug 2004 16:02:48 GMT, Hans-Bernhard Broeker
<broeker@physik.rwth-aachen.de> wrote:


>That sait, there was one real argument in favour of one side. It >favoured little-endian, and has long since been obliterated by CPU >engineering. It applied in situations where three conditions held: > >1) memory is narrower than arithmetic registers
This condition alone favours little endian. Assuming the processor support immediate and/or relative (indexed) addressing modes. If the data bus is 8 bits and the data registers are 16 or 32 bits, the first immediate data byte (just after the opcode) can perform an addition, subtraction or multiply operation with the lowest part of the target register and generate carry (or partial product). Thus, when the next byte is available from the program stream, the byte can be immediately processed. The same applies to relative (indexed) addressing modes, when the low bits of the effective address have already been calculated before the highest bits of the offset have been loaded from the program stream. A similar argument applies to the old decimal (actual BCD) computers, which processed a 4 bit BCD digit at a time. Paul
Grant Edwards <grante@visi.com> says...

>> 3) memory can be read "forward" faster than "backward" > >Point 3) is definitely true for drums, tapes and cards!
Are you assuming that the data on the drums/tapes/cards are stores in 0 to N order instead of N to 0 order?
Hans-Bernhard Broeker <broeker@physik.rwth-aachen.de> says...

>But this really is all moot, because effective memory width is at >least as big as the CPU's registers, if not wider, these days.
This is comp.arch.embedded. Many of us still use 4-bit CPUs.
On Tue, 24 Aug 2004 14:26:44 -0700, Guy Macon
<http://www.guymacon.com> wrote:

>Hans-Bernhard Broeker <broeker@physik.rwth-aachen.de> says... > >>But this really is all moot, because effective memory width is at >>least as big as the CPU's registers, if not wider, these days. > >This is comp.arch.embedded. Many of us still use 4-bit CPUs. >
You're using memory narrower than 4 bits? Some sort of serial RAM interface? Regards, -=Dave -- Change is inevitable, progress is not.
Dave Hansen <iddw@hotmail.com> says...
> >Guy Macon <http://www.guymacon.com> wrote: > >>Hans-Bernhard Broeker <broeker@physik.rwth-aachen.de> says... >> >>>But this really is all moot, because effective memory width is at >>>least as big as the CPU's registers, if not wider, these days. >> >>This is comp.arch.embedded. Many of us still use 4-bit CPUs. > >You're using memory narrower than 4 bits? Some sort of serial RAM >interface?
Oops. read it backwards.