Big-Endian vs. Little-Endian

But let's not forget that we're talking about *computers*, here, not human beings. Calling a typical embedded CPU an "advanced thinker" would be quite a stretch of the imagination, wouldn't you agree?

One thing that speaks against big-endian in written numbers for human beings is that you can't really read them out in the order they're written, anyway. You have to first count the digits before you can start, which means you have to go back and forth at least once. If numbers were written in little-endian, you could start reading them as the digits come by, and just keep on using larger multipliers until you reach the end of the strings of digits.

Actually, when you go and really *process* digits of a multi-digit number, e.g. you add or multiply long numbers on paper, you'll find yourself doing it from the LSD to the MSD, not the other way round, because just like the early CPUs, it's easier to work in the same direction the carry is handed over.

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

It's changing in Norwegian - the "four and twenty" ordering is gradually being replaced by "twenty four" ordering, which has been taught in schools for a few decades now.

Reply to
David Brown

Look at how the relative branch offset is calculated in most processors. The offset is added to the PC, which at that time points to the _next_ instruction to get the absolute branch target address. This is a clear indication that the PC autoincrementing is done during (or even before) opcode decoding. Thus, the same ALU can be used for PC incrementing as well as for actual data calculations.

In a little endian processor, the PC already contains opcode+1 and is gated to the address bus when the opcode has been decoded. Each data/address byte can be accessed simply using the PC.

On a big endian processor, you have to wait, until the opcode is fully decoded to know, if 0 (or 1 if 2 byte immediate data is also supported) or 3 should be added to the PC to get the memory address (assuming the PC has already been autoincremented to opcode+1 during opcode decoding). Thus, there is an extra address calculation delay between the opcode decoding and data/address access. Then the PC should be decremented a few time and then jumped to opcode+5. This would require a quite complex logic.

In practice, a separate memory access register MEMACC would be needed. First you would have to wait for the opcode to be decoded, then PC+3 should be transferred to MEMACC (or PC+0 or PC+1 if also 1 and 2 byte immediate data is supported). Only after this can MEMACC be used to access the bytes immediate after the opcode. Then MEMACC must decremented. All this adds complexity and delay.

This is a bad thing in situations, in which the processor propagation delays are comparable to the memory cycle times, in which case the full memory bandwidth can not be utilised, due to the stalls for opcode decoding and processing.

Of course, this is not of an issue these days, but may have influenced the selection between BE/LE in the old days.

Paul

Reply to
Paul Keinanen

That's an arbitrary decision. It would be just as easy to subtract the offset from the PC and to have a decrementing PC. Granted, it's not usually done that way, but that's just because humans are used to couinting up.

Reply to
Guy Macon

The preceding makes no sense at all. It doesn't have any basis in reality, past, present, or futre.

Reply to
Everett M. Greene

For more than 10 years, "normal" communications in embedded devices implied "little-endian" to me (ah, those old yet still in use telecontrol protocols...). It was only since I began to use TCP/IP with embedded devices when I was taught that the "normal" communications byte order meant "big-endian" for the other half part of humankind.

That prompts another question: was Intel or Motorola which decided that life on earth would be based on left-oriented amino-acids, instead of right-oriented ones?

-- Ignacio G.T.

Reply to
Ignacio G.T.

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.