If you ask a hardware designer, which format should be used, any adder, subtracter and multiplier designer would vote for the little endian format. Divider and square root designers would vote for the big endian format :-).
In Latin/Greek scripts, text is written left to right with most significant digits to the left. In Arabic, text is written right to left, but still the most significant digit is to the _left_.
Paul
Then you'd best *not* ask the hardware FFT guy what order he wants his bits in :-).
I never understood this. If you've got a 32-bit register, why should it matter where the byte boundaries are when doing the add? The add will want to start with the least significant bit usually (assuming ripple carry instead of lookahead), but the adder (and ALU in general) has no preference about how bytes should be stored in RAM. Once you've got the data internal to the CPU, then the endianness is irrelevant. (barring oddball cases like i386 with its mix of register sizes)
If you've got 8-bit registers only, then it's up to software to provide an endian convention, not hardware. If you're doing a byte-wise add, and have an auto-increment byte read, then little-endian would be useful; but this is a software operation, not something that a hardware designer would worry about.
-- Darin Johnson
Take for example a processor with instructions supporting 16 or 32 bit data but with an 8 bit external data bus and you want to add a constant in immediate addressing mode to say, a register. The constant is in the program memory immediately after the opcode. With little endian convention, the lowest bits of the constant are immediately after the opcode and can be used to start the addition and carry generation. The low part of addition is done when the next byte arrives and so on, until the next opcode is retrieved.
With a big endian representation if you would start the addition as early as possible, the PC would have to jump forward 2 or 4 bytes, retrieve the bytes by _decrementing_ the PC and when all is done, jump back to the next opcode.
The other alternative would be to load the bytes in sequence into a temporary register and only after all bytes have been loaded into the temporary register, the addition can begin. This not a big deal if the ALU is 32 or 64 bits wide with full carry look-ahead, but with an ALU narrower than the largest data type, this would cause extra delay.
Since the endianess issue is much about tradition, one should remember, that in ancient decimal computers (each decimal digit stored in BCD), the BCD ALU was only 4 bits wide and the core memory organisation 4 or 6 bits wide, but the instruction set operated with 8 or 10 digit decimal numbers. In these systems the BCD order was also a hardware issue.
Paul
Don't all modern CPUs do this anyway? It would seem like less hardware to provide a temporary register than to provide the control circuitry to handle a multi-step add in the ALU. Unless the ALU width doesn't match the register width. If you're already using a microprogrammed control, your ALU is 8 bits and you've also got 16 or 32 bit registers, then it might make sense.
Big-endian does seems like the most common design in architectures I've seen; except that Intel sells quite a lot of CPUs which makes Intel-endian more ubiquitous.
-- Darin Johnson
The hardware does force one order or the other due to multi-byte operations' order. If nothing else, pushing and popping subroutine return addresses will establish an order. Multi-byte loads and stores is another place where the hardware prescribes the order.
Those of us dealing with multiple target processors from different host processors find the Endiness to be a royal pain in the rear.
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.