On Sat, 21 Aug 2004 06:37:10 -0700, "Peter Nachtwey" <pnachtwey@comcast.net>
wrote:

>"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.
>

For more than 10 years, "normal" communications in embedded devices implied
"little-endian" to me (ah, those old yet still in use telecontrol protocols...).
It was only since I began to use TCP/IP with embedded devices when I was taught
that the "normal" communications byte order meant "big-endian" for the other
half part of humankind.

That prompts another question: was Intel or Motorola which decided that life on
earth would be based on left-oriented amino-acids, instead of right-oriented
ones?


--
Ignacio G.T.

Paul Keinanen <keinanen@sci.fi> writes:
> Hans-Bernhard Broeker <broeker@physik.rwth-aachen.de> wrote:
> 
> >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
> 
> 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.

The preceding makes no sense at all.  It doesn't have
any basis in reality, past, present, or futre.

Paul Keinanen <keinanen@sci.fi> says...

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

That's an arbitrary decision.  It would be just as easy to subtract 
the offset from the PC and to have a decrementing PC.  Granted, it's 
not usually done that way, but that's just because humans are used 
to couinting up.

On 25 Aug 2004 06:51:06 GMT, Hans-Bernhard Broeker
<broeker@physik.rwth-aachen.de> wrote:

>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

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
   

"Hans-Bernhard Broeker" <broeker@physik.rwth-aachen.de> wrote in message
news:2p1758Ffmo5gU1@uni-berlin.de...
> This is drifting wildly OT, of course, but what the heck.
>
> Grant Edwards <grante@visi.com> wrote:
>
> > And in western languages (English as well) numbers were read
> > little-endian (from "right to left" -- LSD first) until
> > recently.
>
> 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,

It's changing in Norwegian - the "four and twenty" ordering is gradually
being replaced by "twenty four" ordering, which has been taught in schools
for a few decades now.

> 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* ;-)
>

Bryan Hackney <bh.remove@bhconsult.com> wrote:

> My assertion about LtoR was wrong - it does not matter which way
> you're going, but I still assert that MSD first is natural to an
> advanced thinker.

But let's not forget that we're talking about *computers*, here, not
human beings.  Calling a typical embedded CPU an "advanced thinker"
would be quite a stretch of the imagination, wouldn't you agree?

One thing that speaks against big-endian in written numbers for human
beings is that you can't really read them out in the order they're
written, anyway.  You have to first count the digits before you can
start, which means you have to go back and forth at least once.  If
numbers were written in little-endian, you could start reading them as
the digits come by, and just keep on using larger multipliers until
you reach the end of the strings of digits.

> That is assuming that you start processing the digits as you come
> across them, rather than all at once, which is maybe another fallacy.

Actually, when you go and really *process* digits of a multi-digit
number, e.g. you add or multiply long numbers on paper, you'll find
yourself doing it from the LSD to the MSD, not the other way round,
because just like the early CPUs, it's easier to work in the same
direction the carry is handed over.

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

Paul Keinanen <keinanen@sci.fi> wrote:
> 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. 

No.  You need the others, too.

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

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

Dave Hansen wrote:
> 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?

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 (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

Jim McGinnis wrote:
> On Mon, 23 Aug 2004 15:18:03 GMT, Bryan Hackney
> <bh.remove@bhconsult.com> wrote:
> 
> 
>>I say natural order - maybe that should be anthropic order. We read
>>numbers LtoR, MSD to LSD.
> 
> 
> 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.

My assertion about LtoR was wrong - it does not matter which way you're
going, but I still assert that MSD first is natural to an advanced
thinker. When you have a number such as 123,456,678, do you want to
think "123 million", or "678 plus a large number"? That's my
modern anthropic argument, regardless or LtoR.

That is assuming that you start processing the digits as you come
across them, rather than all at once, which is maybe another fallacy.
Do you visually gulp numbers, or start thinking about them MSD to LSD?

-- 
------------------------------------------------------------
Creepy, Soulless Gigolo for President ? NOT !
---------------------------------------------
THK is one weird, weird something.

Michael Furman wrote:
> 
... snip ...
> 
> 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).

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 (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!