Big-Endian vs. Little-Endian - Page 3

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Big-Endian vs. Little-Endian
On Mon, 23 Aug 2004 15:18:03 GMT, Bryan Hackney

Quoted text here. Click to load it
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
We've slightly trimmed the long signature. Click to see the full one.
Re: Big-Endian vs. Little-Endian

Quoted text here. Click to load it


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.

--
Grant Edwards                   grante             Yow!  I'm not an
                                  at               Iranian!! I voted for
We've slightly trimmed the long signature. Click to see the full one.
Re: Big-Endian vs. Little-Endian
On Mon, 23 Aug 2004 15:18:03 GMT, Bryan Hackney

Quoted text here. Click to load it

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.
--
Jim McGinnis

Re: Big-Endian vs. Little-Endian
Quoted text here. Click to load it

And in western languages (English as well) numbers were read
little-endian (from "right to left" -- LSD first) until
recently.

"Four and twenty blackbirds..."

--
Grant Edwards                   grante             Yow!  I am having a
                                  at               pleasant time!!
We've slightly trimmed the long signature. Click to see the full one.
Re: Big-Endian vs. Little-Endian
...
Quoted text here. Click to load it

That's a British rhyme. American is different:

"Four score and seven years ago, our fathers brought forth ..."

Re: Big-Endian vs. Little-Endian
Quoted text here. Click to load it

That's why I said "until recently."  200 years is pretty recent
in the development of languages.

Quoted text here. Click to load it

--
Grant Edwards                   grante             Yow!  Hello... IRON
                                  at               CURTAIN? Send over a
We've slightly trimmed the long signature. Click to see the full one.
Re: Big-Endian vs. Little-Endian
This is drifting wildly OT, of course, but what the heck.


Quoted text here. Click to load it

What do you mean, "until recently"?  English still does it that way
from 13 to 19.  In German (and most related languages, AFAIK) that's
how it is done all the way up to 99, and is quite unlikely to change,
ever.  And just to make it more confusing, it's done that way only for
tens and ones, i.e. 524 is "fuenfhundertvierundzwanzig", i.e. "five
hundred four and twenty".  And let's not even get started about
French, where what they say when they mean 97 translates, literally,
as "four twenty ten seven".  Now you try and install some sense in
terms of endianness into *that* ;-)

Back to the topic: yes, endianness is, and always was, an almost
entirely arbitrary choice.  Which makes the term so well-chosen. [The
literary reference from Gulliver's Travels is about endless war being
waged between two groups of people, over which end of an egg you
should start at opening it: the big or the little end.  With both the
eggs and the bits, there are essentially no rational arguments towards
either side, but you still have to make a choice, and the world might
be a better place if everybody could agree on making that choice the
same way, once and for all.]

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.

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

Re: Big-Endian vs. Little-Endian

Quoted text here. Click to load it

Sometime between 0 and 200 years ago? :)

[More recent for some languages than others.]

Quoted text here. Click to load it

Point 3) is definitely true for drums, tapes and cards!

--
Grant Edwards                   grante             Yow!  Where's SANDY DUNCAN?
                                  at              
We've slightly trimmed the long signature. Click to see the full one.
Re: Big-Endian vs. Little-Endian

Quoted text here. Click to load it

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


Re: Big-Endian vs. Little-Endian
Quoted text here. Click to load it


    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



Re: Big-Endian vs. Little-Endian

Quoted text here. Click to load it

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 ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Re: Big-Endian vs. Little-Endian
On 24 Aug 2004 18:11:50 GMT, Hans-Bernhard Broeker


Quoted text here. Click to load it

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

Re: Big-Endian vs. Little-Endian

Quoted text here. Click to load it

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


Re: Big-Endian vs. Little-Endian
On Tue, 24 Aug 2004 14:26:44 -0700, Guy Macon
<http://www.guymacon.com wrote:

Quoted text here. Click to load it

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

Regards,

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

Re: Big-Endian vs. Little-Endian
Quoted text here. Click to load it

Oops. read it backwards.  


Re: Big-Endian vs. Little-Endian
Quoted text here. Click to load it

I once designed (on paper) a machine with a 1 bit memory
interface.  I abandoned it when the complexities exceeded the
savings.  (NOTE: there was no parity protection :-)

However the basic design was very usable for some instruments,
which basically had only to increment a location and later to read
that value out.  This was in the days of core memory, when saving
a wire was significant.  That instrument idea came from Frank
Petree.

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: Big-Endian vs. Little-Endian
Quoted text here. Click to load it
... snip ...
Quoted text here. Click to load it

Exactly.  This means that the subroutines (whether software or
hardware) can be paramatized, and the only argument that changes
with operand length is the length.  Thus the same soft or hardware
can serve for multiple arithmetic lengths (at least for
add/subtract).  2's complement also helps because the initial
point need not be reaccessed.

   void addvarlgh(BYTE *op1, BYTE* op2, size_t lgh)
   {
      BYTE   carry;
      size_t i;

      for (i = carry = 0; i < lgh; op1++, op2++, i++) {
         /* add *op1 := *op1 + *op2 + carry
            adjust carry on overflow */
      }
   }

which can be modified to return the sign of the result.

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: Big-Endian vs. Little-Endian
On 24 Aug 2004 16:02:48 GMT, Hans-Bernhard Broeker


Quoted text here. Click to load it

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
  

Re: Big-Endian vs. Little-Endian
Quoted text here. Click to load it




No.  You need the others, too.

Quoted text here. Click to load it


This only holds if my second condition applies: that the actual logics
that do the addition do it on units smaller then the register size.
If the adder circuit does a 32-bit addition in a single clock cycle,
it doesn't matter at all in which order the 4 bytes arrived ---
they'll all be read and then *bang* you get the result in one click.

And if the memory doesn't care what direction you read it in, then
again big-endian can be handled exactly as fast as little-endian.  You
would just have to read the bytes in this order:

    opcode
    opcode +4
    opcode +3
    opcode +2
    opcode +1

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

Re: Big-Endian vs. Little-Endian
On 25 Aug 2004 06:51:06 GMT, Hans-Bernhard Broeker

Quoted text here. Click to load it

Look at how the relative branch offset is calculated in most
processors. The offset is added to the PC, which at that time points
to the _next_ instruction to get the absolute branch target address.
This is a clear indication that the PC autoincrementing is done during
(or even before) opcode decoding. Thus, the same ALU can be used for
PC incrementing as well as for actual data calculations.

In a little endian processor, the PC already contains opcode+1 and is
gated to the address bus when the opcode has been decoded. Each
data/address byte can be accessed simply using the PC.

On a big endian processor, you have to wait, until the opcode is fully
decoded to know, if 0 (or 1 if 2 byte immediate data is also
supported) or 3 should be added to the PC to get the memory address
(assuming the PC has already been autoincremented to opcode+1 during
opcode decoding). Thus, there is an extra address calculation delay
between the opcode decoding and data/address access. Then the PC
should be decremented a few time and then jumped to opcode+5. This
would require a quite complex logic.

In practice, a separate memory access register MEMACC would be needed.
First you would have to wait for the opcode to be decoded, then PC+3
should be transferred to MEMACC (or PC+0 or PC+1 if also 1 and 2 byte
immediate data is supported). Only after this can MEMACC be used to
access the bytes immediate after the opcode. Then MEMACC must
decremented. All this adds complexity and delay.

This is a bad thing in situations, in which the processor propagation
delays are comparable to the memory cycle times, in which case the
full memory bandwidth can not be utilised, due to the stalls for
opcode decoding and processing.

Of course, this is not of an issue these days, but may have influenced
the selection between BE/LE in the old days.

Paul
  

Site Timeline