Forums

Big-Endian vs. Little-Endian

Started by Everett M. Greene August 20, 2004
At the risk of starting a flame war, which choice have people
really made with regard to Little-Endian vs. Big-Endian for
those processors where it's a design choice (ARM, PowerPC,...)?
I'm asking in the context of using such processors in embedded
applications where compatibility with anything in the outside
world is not a factor.
On 2004-08-21, Everett M. Greene <mojaveg@iwvisp.com> wrote:

> At the risk of starting a flame war, which choice have people > really made with regard to Little-Endian vs. Big-Endian for > those processors where it's a design choice (ARM, PowerPC,...)?
Given a choice, I prefer big-endian in isolation. -- Grant Edwards grante Yow! Don't SANFORIZE me!! at visi.com
On Fri, 20 Aug 2004 18:21:13 PST, mojaveg@iwvisp.com (Everett M.
Greene) wrote:

>I'm asking in the context of using such processors in embedded >applications where compatibility with anything in the outside >world is not a factor.
In this situation, why bother with it, since it is hard to imagine situations in which this really matters. In the unlikely situation that the order might be important in a special situation, I would suggest using the endianess in which your team has worked previously. This may help to avoid one or two errors during a large project. Although the current specifications do not require any binary interfacing to the outside world, there is always a risk that in a future version such connections are needed. In these situations, remember to write the actual code that work with any endianess (e.g. explicitly using shifts, ORs and masks) to assemble and/or disassemble a string of bytes. Paul
"Everett M. Greene" <mojaveg@iwvisp.com> wrote in message
news:20040820.7A463F0.104AB@mojaveg.iwvisp.com...
> At the risk of starting a flame war, which choice have people > really made with regard to Little-Endian vs. Big-Endian for > those processors where it's a design choice (ARM, PowerPC,...)? > I'm asking in the context of using such processors in embedded > applications where compatibility with anything in the outside > world is not a factor.
There is a slight advantage in little-endian: you can address the least significant part of a longer item with the same address as the original item. In Intel 80x86 family, the lowest byte of a longword is in the same address as the longword, which most often is intuitively clear. This does not work in big-endian architectures. Tauno Voipio tauno voipio (at) iki fi
> There is a slight advantage in little-endian: you can address > the least significant part of a longer item with the same > address as the original item.
But the hex dumps are harder to read! ;)
"John Harlow" <sirsausage@hotmail.com> wrote in message
news:a_ydnSXrtctO1rrcRVn-pA@comcast.com...
> > There is a slight advantage in little-endian: you can address > > the least significant part of a longer item with the same > > address as the original item. > > But the hex dumps are harder to read! ;) > >
Hex dumps are things of the 80s. However, I prefer little endian because of reasons previous stated except in communication applications where data normally comes over the wire in big endian format AND the CPU has a word length greater than 8 bits. Using big endian in communication applications avoids having to swap all the data. Peter Nachtwey
Peter Nachtwey wrote:
> Hex dumps are things of the 80s.
How sweet ... a newbie. ;-) -- 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
On Sat, 21 Aug 2004 09:22:17 +0000, Tauno Voipio wrote:
> > In Intel 80x86 family, the lowest byte of a longword is > in the same address as the longword, which most often > is intuitively clear. This does not work in big-endian > architectures. >
An old discussion on this subject: http://yarchive.net/comp/endian.html
Peter Nachtwey said...
> "John Harlow" wrote > > > > > > There is a slight advantage in little-endian: you can address > > > the least significant part of a longer item with the same > > > address as the original item. > > > > But the hex dumps are harder to read! ;)
Exactly! I recently switched from a long line of little-endian processors to the big-endian Coldfire. I spent too many years reading byte-oriented hex dumps and trying to reorder the bytes in my head.
> > > Hex dumps are things of the 80s.
You just keep telling yourself that .... Casey
Tauno Voipio wrote:
> "Everett M. Greene" <mojaveg@iwvisp.com> wrote in message > >> At the risk of starting a flame war, which choice have people >> really made with regard to Little-Endian vs. Big-Endian for >> those processors where it's a design choice (ARM, PowerPC,...)? >> I'm asking in the context of using such processors in embedded >> applications where compatibility with anything in the outside >> world is not a factor. > > There is a slight advantage in little-endian: you can address > the least significant part of a longer item with the same > address as the original item. > > In Intel 80x86 family, the lowest byte of a longword is > in the same address as the longword, which most often > is intuitively clear. This does not work in big-endian > architectures.
OTOH big-endian has the advantage of immediate access to the sign bit, and the penalty of requiring an initial address calculation for most arithmetic operations. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?