Big-Endian vs. Little-Endian

Hans-Bernhard Broeker wrote:
> [...]

> That sait, there was one real argument in favour of one side.  It
> favoured little-endian, and has long since been obliterated by CPU
> engineering.  It applied in situations where three conditions held:
>
> 1) memory is narrower than arithmetic registers
> 2) key ALU building blocks (adders, shifters, the likes) are
>    narrower than CPU registers, so operations take several cycles
>    through them, passing around carry bits.
> 3) memory can be read "forward" faster than "backward"
>
> In this situation, doing little-endian allows to intermix ALU cycles
> and memory fetches, and can thus be noticeably faster than big-endian.
> The difference will be governed by the speed penalty for stepping
> through address space in the "wrong" direction.

    There is another small advantage of little-endian: if you have a pointer
to an integer variable that has size N it is at the same time could be
interpreted
as pointer to a variable of the smaller size (given that variable value
is small anough to fit).

                Michael Furman

"Michael N. Moran" <mike@mnmoran.org> writes:
> Stephen Pelc wrote:
> > mojaveg@mojaveg.iwvisp.com (Everett M. Greene) wrote:
> > 
> >>Now that you're talking about the question I raised, which
> >>choice do people make when they have a free choice?
> > 
> > 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.
> 
> And then there is the USB, which is little-endian.
> IIRC, at least one of the descriptors has unaligned
> members as well.

USB was originally described by Intel, so what would you
expect?

Did you ever get the feeling that the first Little-Endian
machine was a mistake and rather than correct the error,
it was decided to market it as a FUG?  [FUG = "it's a
feature, not a bug"]

Michael Furman <MichaelFurman@yahoo.com> wrote:

>     There is another small advantage of little-endian: if you have a
> pointer to an integer variable that has size N it is at the same
> time could be interpreted as pointer to a variable of the smaller
> size (given that variable value is small anough to fit).

That rests on the assumption that the pointer to the big thing must
obviously have the last few bits zeroed.  If you've seen Prof. Knuth's
MMIX, you know that's not strictly a necessity --- MMIX just ignores
all bits of an address that would lead to non-aligned addresses for
objects larger than one "machine word".  In that scheme, the lowermost
bits of the pointer to a N-byte integer could just as well all be ones,
and using that as a pointer-to-byte would still give you the lowermost
one.

But this really is all moot, because effective memory width is at
least as big as the CPU's registers, if not wider, these days. 

-- 
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Everett M. Greene wrote:
> "Michael N. Moran" <mike@mnmoran.org> writes:
>>And then there is the USB, which is little-endian.
>>IIRC, at least one of the descriptors has unaligned
>>members as well.
> 
> USB was originally described by Intel, so what would you
> expect?

Oh ... I got what I expected ;-)

[Off-topic]
In all fairness, however, I think that much of the
USB design is quite good. In particular, the various
service types (bulk,interrupt,control,isochronous)
are IMHO, well considered. I find it "funny" that most
vendors (or is it their engineering staff) use bulk
transport for almost everything, even when there are
more appropriate mechanisms. I suspect it is because
of familiarity with the operation of UART serial ports
that the USB is to replace.

> Did you ever get the feeling that the first Little-Endian
> machine was a mistake and rather than correct the error,
> it was decided to market it as a FUG?  [FUG = "it's a
> feature, not a bug"]

For better or worse, business decisions rule. It's a
money thing ... I wouldn't understand ;-)

-- 
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 24 Aug 2004 18:11:50 GMT, Hans-Bernhard Broeker
<broeker@physik.rwth-aachen.de> wrote:


>But this really is all moot, because effective memory width is at
>least as big as the CPU's registers, if not wider, these days. 

This is definitely not the case for such typical mobile devices as
cell phones, where a 32-bit ARM CPU has a 16-bit external bus. The
narrow bus saves power and perhaps size/weight, critical factors in
advanced handheld devices.


-- 
Jim McGinnis

On 24 Aug 2004 16:02:48 GMT, Hans-Bernhard Broeker
<broeker@physik.rwth-aachen.de> wrote:


>That sait, there was one real argument in favour of one side.  It
>favoured little-endian, and has long since been obliterated by CPU
>engineering.  It applied in situations where three conditions held:
>
>1) memory is narrower than arithmetic registers

This condition alone favours little endian. 

Assuming the processor support immediate and/or relative (indexed)
addressing modes. 

If the data bus is 8 bits and the data registers are 16 or 32 bits,
the first immediate data byte (just after the opcode) can perform an
addition, subtraction or multiply operation with the lowest part of
the target register and generate carry (or partial product). Thus,
when the next byte is available from the program stream, the byte can
be immediately processed. 

The same applies to relative (indexed) addressing modes, when the low
bits of the effective address have already been calculated before the
highest bits of the offset have been loaded from the program stream.

A similar argument applies to the old decimal (actual BCD) computers,
which processed a 4 bit BCD digit at a time.

Paul
   

Grant Edwards <grante@visi.com> says...

>> 3) memory can be read "forward" faster than "backward"
>
>Point 3) is definitely true for drums, tapes and cards!

Are you assuming that the data on the drums/tapes/cards
are stores in 0 to N order instead of N to 0 order?

Hans-Bernhard Broeker <broeker@physik.rwth-aachen.de> says...

>But this really is all moot, because effective memory width is at
>least as big as the CPU's registers, if not wider, these days. 

This is comp.arch.embedded.  Many of us still use 4-bit CPUs.

On Tue, 24 Aug 2004 14:26:44 -0700, Guy Macon
<http://www.guymacon.com> wrote:

>Hans-Bernhard Broeker <broeker@physik.rwth-aachen.de> says...
>
>>But this really is all moot, because effective memory width is at
>>least as big as the CPU's registers, if not wider, these days. 
>
>This is comp.arch.embedded.  Many of us still use 4-bit CPUs.
>

You're using memory narrower than 4 bits?  Some sort of serial RAM
interface?

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.

Dave Hansen <iddw@hotmail.com> says...
>
>Guy Macon <http://www.guymacon.com> wrote:
>
>>Hans-Bernhard Broeker <broeker@physik.rwth-aachen.de> says...
>>
>>>But this really is all moot, because effective memory width is at
>>>least as big as the CPU's registers, if not wider, these days. 
>>
>>This is comp.arch.embedded.  Many of us still use 4-bit CPUs.
>
>You're using memory narrower than 4 bits?  Some sort of serial RAM
>interface?

Oops. read it backwards.