Big-Endian vs. Little-Endian

Grant Edwards wrote: ...

That's a British rhyme. American is different:

"Four score and seven years ago, our fathers brought forth ..."

What do you mean, "until recently"? English still does it that way from 13 to 19. In German (and most related languages, AFAIK) that's how it is done all the way up to 99, and is quite unlikely to change, ever. And just to make it more confusing, it's done that way only for tens and ones, i.e. 524 is "fuenfhundertvierundzwanzig", i.e. "five hundred four and twenty". And let's not even get started about French, where what they say when they mean 97 translates, literally, as "four twenty ten seven". Now you try and install some sense in terms of endianness into *that* ;-)

Back to the topic: yes, endianness is, and always was, an almost entirely arbitrary choice. Which makes the term so well-chosen. [The literary reference from Gulliver's Travels is about endless war being waged between two groups of people, over which end of an egg you should start at opening it: the big or the little end. With both the eggs and the bits, there are essentially no rational arguments towards either side, but you still have to make a choice, and the world might be a better place if everybody could agree on making that choice the same way, once and for all.]

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.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

That's why I said "until recently." 200 years is pretty recent in the development of languages.

--
Grant Edwards                   grante             Yow!  Hello... IRON
                                  at               CURTAIN? Send over a
                               visi.com            SAUSAGE PIZZA! World War
                                                   III? No thanks!

This is interesting. Our language (not english) still has it this way. Any hints on when and on what occasion that was changed.

Rene

Sometime between 0 and 200 years ago? :)

[More recent for some languages than others.]

Point 3) is definitely true for drums, tapes and cards!

--
Grant Edwards                   grante             Yow!  Where's SANDY DUNCAN?
                                  at               
                               visi.com

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"]

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

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.

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.

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

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

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

Are you assuming that the data on the drums/tapes/cards are stores in 0 to N order instead of N to 0 order?

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.

Oops. read it backwards.

... snip ...

Exactly. This means that the subroutines (whether software or hardware) can be paramatized, and the only argument that changes with operand length is the length. Thus the same soft or hardware can serve for multiple arithmetic lengths (at least for add/subtract). 2's complement also helps because the initial point need not be reaccessed.

void addvarlgh(BYTE *op1, BYTE* op2, size_t lgh) { BYTE carry; size_t i;

for (i = carry = 0; i < lgh; op1++, op2++, i++) { /* add *op1 := *op1 + *op2 + carry adjust carry on overflow */ } }

which can be modified to return the sign of the result.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
     USE worldnet address!

My assertion about LtoR was wrong - it does not matter which way you're going, but I still assert that MSD first is natural to an advanced thinker. When you have a number such as 123,456,678, do you want to think "123 million", or "678 plus a large number"? That's my modern anthropic argument, regardless or LtoR.

That is assuming that you start processing the digits as you come across them, rather than all at once, which is maybe another fallacy. Do you visually gulp numbers, or start thinking about them MSD to LSD?

--
------------------------------------------------------------
Creepy, Soulless Gigolo for President ? NOT !
---------------------------------------------
THK is one weird, weird something.

I once designed (on paper) a machine with a 1 bit memory interface. I abandoned it when the complexities exceeded the savings. (NOTE: there was no parity protection :-)

However the basic design was very usable for some instruments, which basically had only to increment a location and later to read that value out. This was in the days of core memory, when saving a wire was significant. That instrument idea came from Frank Petree.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
     USE worldnet address!

No. You need the others, too.

This only holds if my second condition applies: that the actual logics that do the addition do it on units smaller then the register size. If the adder circuit does a 32-bit addition in a single clock cycle, it doesn't matter at all in which order the 4 bytes arrived --- they'll all be read and then *bang* you get the result in one click.

And if the memory doesn't care what direction you read it in, then again big-endian can be handled exactly as fast as little-endian. You would just have to read the bytes in this order:

opcode opcode +4 opcode +3 opcode +2 opcode +1

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.