Big-Endian vs. Little-Endian

You've missed the point that some processors can be used in either big or little endian mode.

This information would be immediately available on some little endian systems as well: the ARM instruction set, for example, can encode an immediate offset in the instruction.

Yes, but many of these have a prefererance for one mode. The PPC architecture, for example, perfers big-endian - some implementations (like the MPC56x) don't support little-endian at all, while those that do have certain restrictions - I believe the string instructions only function in big-endian mode, for example. This is because all cpus have are fixed-endian at heart (normally big- or little-endian, though there have historically been computers with all sorts of arrangements), and the non-native mode is handled using thunking - the bytes of multi-byte data are re-arranged on the fly as data is moved into and out of the cpu.

The one I'm most familar with is the ARM where the endianness is set by an external line.

CPUs internally have no endianness. The endianness only comes into play when accessing memory.

When dealing with bitstreams such as raster lines, big-endian is way better. The ultimate machine for these apps have large words and are big-endian.

Bulk operations such as applying masks are not affected, but some operations such as shifting, shearing, and bit-bending are way easier on a natural order machine when having to cast around types.

I say natural order - maybe that should be anthropic order. We read numbers LtoR, MSD to LSD.

Now that you're talking about the question I raised, which choice do people make when they have a free choice?

Do you have troubles reading a UART stream from a scope then ? A minimum of flexibility is expectable from people working embedded...

Rene

The issue is so low down in the priority list that I can't imagine a situation where the endianness of the processor would make the difference, unless there was something in the application itself that made one choice or the other preferable for compatibility with other components of the system.

-Robert Scott Ypsilanti, Michigan (Reply through this forum, not by direct e-mail to me, as automatic reply address is fake.)

Can you say "non sequitur"?

Do processors with high end at the lower address tend to have a more regular instruction set than the reverse persuasion? I'm thinking of the Motorola mindset (6800, 6803, 6809 of blessed memory, 68000) v the nightmares of 8085/Z80/80x86. In the days when I used to write a lot of assembler, I know which ones I preferred!

Paul Burke

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. In practice, this has very little impact on performance. For example, in a TCP/IP stack, checksum generation is far more important than the impact of endianness.

Stephen

-- Stephen Pelc, snipped-for-privacy@INVALID.mpeltd.demon.co.uk MicroProcessor Engineering Ltd - More Real, Less Time

These numbers are from Arabic which is a right to left language. :-)

Stephen

-- Stephen Pelc, snipped-for-privacy@INVALID.mpeltd.demon.co.uk MicroProcessor Engineering Ltd - More Real, Less Time

And then there is the USB, which is little-endian. IIRC, at least one of the descriptors has unaligned members as well.

The one that matches the byte-order of I/O devices, for example.

The VAX was _very_ regular (too regular for its own good), and was little-endian.

The AVR is little-endian.

Regards,

-=Dave

More than a compiler convention. Consider adiw, sbiw, [f]mul[s[u]], and spm. The X, Y, and Z registers are also defined with the higher-numbered register as the MSB.

However, the [r]call instruction pushes the lsb of the pc onto the stack first, resulting in a big-endian layout in memory. The 8051 is similarly of two minds here: the call instruction contains a little-endian destination address, but pushes the return address in big-endian order (or vice-versa -- it's been a while...)

Indeed.

It's like clasping your hands together in a double fist. Do you interlock your fingers so your left thumb is over the right, or the right is over the left? When you switch, it feels like you're holding someone else's hand.

There are two ways to do it. Neither is "better" than the other. One way feels comfortable, the other doesn't. But some do it one way, and some the other. And you're reluctant to switch just because someone else says it's the "right" way.

Regards,

-=Dave

Latin for "it does not follow."

Except it does. If you look at the serial stream from a UART on a scope, the bits appear left to right, LSb to MSb. And depending on where you hook into the circuit, ones may be low and zeros high. Does take some getting used to.

OTOH, if the serial stream is an ASCII text string, it DOES tend to be transmitted leftmost character first...

Regards,

-=Dave

And the latin-alphabet-using people who orignally borrowed arabic numerical notation for some reason neglected to flip them around to match the direction of the rest of the language.

Be careful about arguments based on "naturalness". When Arabic numerals made their way into Western left-to-right writing, the original LSD to MSD ordering was reversed. In Arabic, which reads right-to-left, the ones digit is on the right. Apparently the Indian system from which the Arabic numerals came also had the LSD first, or little-endian.