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 <m...@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, m...@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" <m...@iwvisp.com> wrote in message
news:2...@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" <s...@hotmail.com> wrote in message
news:a...@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" <m...@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?