Endianness does not apply to byte

Actually the original flaw is in the number system we use in everyday life. The numbers we use are actually written bass-ackwards, and have been ever since they were imported from Arabia to Central Europe.

Look at how you pronounce a multi-digit number you see printed on paper. Before you can pronounce the first couple of digits, you have to count how many digits there are. I.e. you have to jump back and forth in the line:

This number is 3939586729

is scanned T h i s n u m b e r i s [... wait, how many digits??? 10, OK, so it's...] three billion (939) million (586) thousand 729. It's really quite ridiculous. Wouldn't it be a whole lot easier if the number were written

and pronounced:

ninetwoseven sixeightfivethousand ninethreeninemillion threebillion

? No jumping all over the place to count digits, no kids wondering why they have to add starting at the "back" end, in elementary school.

Little-endian would have made sense in pretty much every aspect of arithmetic, long before "computer" turned from being the name for a person doing arithmetic for a living, to that of a machine. But that's water under the bridge, and has been for about 1000 years now.

I actually thought about the argument you made before I made my post (that one has to count the number of digits before one can figure out what the first digit means).

I think human beings are always looking for an abstraction (i.e. to reduce the amount of information without changing its significance). In that sense, big-endian seems more human-friendly. One can often ignore the last several digits. The population of a country might be 297,322,101 ... one can really stop reading after the second digit.

Also, in speaking, with some numbers, saying them in a little-endian way would seem to "delay" the most significant stuff.

I can tolerate a language like German because it only does this for the modulo ten result, i.e. neun-und-neunzig ... but it would drive me crazy if this little-endian discipline were carried out through the whole number.

But my ramblings only apply to humans ... the GMP (for example) is fast for a reason ...

I guess it depends on what you are used to, and want to compare it with. I would think that if you are aiming to generate the fastest and tightest code, it is easier to reach the level needed with the PPC than, say, the x86 instruction set (and with big processors like these, if you don't need fast and tight code, and are writing something more than very low-level stuff that C can't handle directly, then you are using the wrong language). But if you are used to an ISA like the 68k and especially the ColdFire (which drops the most complex addressing modes, and adds a few more useful instructions), then the PPC set is cryptic nonsense, clearly designed for compilers rather than assembly programmers.

If you're making a 32-bit access, the two LS bits aren't used on a byte-addressable bus. Inverting the two LS address bits would work if the 32 bits were loaded one byte at a time.

Op Tue, 21 Nov 2006 09:33:39 PST schreef Everett M. Greene:

So, it's not as simple as I thought. I agree! I've read a bit about the Dec Alpha. Default loading and storing are little-endian there and access is in long word (4 bytes) or quad word (8 bytes). Perhaps when big-endian mode is used, instruction timing could go up.

If you are accessing 32 bits at a time, you don't have a problem with Endian-ness! It only shows when you access data as bytes. If you access a word, you get a word. If you ask for a byte, you get the byte you address which is a different byte in the different Endian styles. The address lsbs just need to be inverted when you access bytes and you change Endian-ness.

Of course this does not fix all sins. If you have a block of mixed data types that was written in one Endian-ness you can't just invert the address lsbs when you access the data in the other Endian mode. But you can access each unit of data as the full entity (double word, word, half word, byte) and you will get every last piece correctly.

Unlikely. Converting endianness in silicon is cheap. For a selectable configuration between little-endian and big-endian it only requires an additional MUX in the datapath, with a small delay, independent of the selected mode.

For a fixed conversion, it's only a matter of connecting the wires in a different way, which is practically free.

Do you mean to say that The Conversion/Switching Between Big & Little Endian is simple & cheap if implemented in hardware .... Then, Why do the modern day processors come up with Little Endian / Big Endian alone ? I think, the option of toggling a Bit via software to make the processor to act as Little Endian or Big Endian as per the software developers convenience is a good idea. Does any processor have that feature Or Any difficulties in that ?

Thx, Karthik Balaguru

hardware,

I've worked with ARM processors which did have such a little/big endian switch. There can be an advantage to such a switch, but it's not always up to the s/w developer to make the choice. If the core has already been embedded in a chip/board, there may already be h/w registers that are statically configured for little- or big-endian, and in that case it's usually easier to just adopt that policy.

Personally, I would rather have a quick way to perform the conversion in software, than a configurable hardware interface. The ARM, for example, can do 32 bit endian swap in 3 cycles, which is usually fast enough, especially if the data comes from a slower IO or memory interface.

hardware,

What kind of switch ? Is it some kind of switch that is found in Harddisk to make it act as either Master or Slave or some other variant of switch.

Almost everything is reprogrammable and we are in Digital world today. I think, there must be provision to reprogram the gates and make it Little or Big Endian based on the toggling of a particular 'Endian PIN' (should be made) in the processor.

Thx, Karthik Balaguru

hardware,

(8

go

The "switch" is just a bit in the ARM system coprocessor. You can write "0" or "1" to that bit, and select the endianness.

Switching the CPU endianness is not always the answer. Sometimes you need both, if you talk using different protocols.

PowerPC (I think) and ARM. Once someone has made the choice as to which way it's going to operate, the usefulness of the switch diminishes rapidly. There may be obscure cases where being able to dynamically switch endiness is useful but they're extremely rare.

And as an instruction set simulator developer, I don't even want to think about dynamic endiness! It's bad enough to handle the case of the simulator host and the target processor having different endiness.

It's cheaper than that: CPUs obviously need to support accesses of different widths, and the hardware you need for that can be reused.

It isn't that simple (as someone wrote above). Changing endian needs to be done for a multitude of access widths, and conversion is different for each. There is always one width with doesn't need conversion, which is called the endian invariant width. Older ARMs used word invariant endian, newer ARMs use byte invariant endian which allows the endian to be swapped dynamically. For example you can run a little endian process on a big endian OS.

Wilco

Newer ARMs have instructions that do it in a single cycle. This way you can choose between running programs in different endians or let the software deal with it. You can also temporarily change the endian over a sequence of instructions if you need to do many accesses, so the cost is even lower.

Wilco

True. I was just thinking about fixed widths. But even so, the extra delay in the data path is small. Worst case, a 32 bit bus needs a 4:1 MUX for each byte, so it can swap arbitrary byte lanes.

Cool. I've only worked with ARM7 and ARM9 where the conversion had to be done by hand. I've also never changed the hardware endian bit, since all peripherals were hard wired to be little endian. A single cycle instruction would have been useful, also because the 3-cycle manual version uses a temp register.

In C? A cast.

It might be done either way, depending on architecture.

Some PowerPCs have this also. Some of them were sort of broken though, but others have fixed it to be usable. The endianness can also change from process to process, and the interrupt handler can be different from the processes. But it's just not very practical. It's just unnatural to go with little-endian on a PowerPC, unless you're writing all the software from scratch from ground up. Otherwise old software has to be rewritten and the manuals all assume big-endian.

The PowerPC has assembler load/store instructions that will swap the bytes with no performance loss, which further reduces the desire to go to little-endian.

The only reason I can think of for changing the natural endianness of a processor is when you need compatibility with shared processors, or you have a huge base of software that can't easily be made portable. Otherwise it's better to stick with the natural endianness of the processor in question.

-- Darin Johnson

And at least some MIPS.