embedded systems skills set

Everett M. Greene wrote:
> Big-Endian is definite plus.  If you don't like ABA, you can
> always write a macro.  Manuals and datasheets are orders
> better than some other companies'.

Both have their advantages (though to be honest, I have to
think a bit before I can think of any advantage to little
endian that doesn't contain the word "compatibility").
But big-endian would seem to be much more natural
and easy to teach to students where the natural language
and arithmetic uses a left to right order.

Some "perversity" comes from trying to force a human
representation onto the data.  Ie, writing little endian
data down as least significant byte first, but each byte
is written with most significant bit first.  But that's just
because a human is writing things down symbolically.

--
Darin Johnson

On 20 Sep 2006 11:43:22 -0700, "Darin Johnson" <darin@usa.net> wrote:

>Everett M. Greene wrote:
>> Big-Endian is definite plus.  If you don't like ABA, you can
>> always write a macro.  Manuals and datasheets are orders
>> better than some other companies'.
>
>Both have their advantages (though to be honest, I have to
>think a bit before I can think of any advantage to little
>endian that doesn't contain the word "compatibility").

If you ask a hardware designer, which format should be used, any
adder, subtracter and multiplier designer would vote for the little
endian format. Divider and square root designers would vote for the
big endian format :-).

>But big-endian would seem to be much more natural
>and easy to teach to students where the natural language
>and arithmetic uses a left to right order.

In Latin/Greek scripts, text is written left to right with most
significant digits to the left. In Arabic, text is written right to
left, but still the most significant digit is to the _left_.

Paul
 

Paul Keinanen wrote:

> On 20 Sep 2006 11:43:22 -0700, "Darin Johnson" <darin@usa.net> wrote:
> 
> 
>>Everett M. Greene wrote:
>>
>>>Big-Endian is definite plus.  If you don't like ABA, you can
>>>always write a macro.  Manuals and datasheets are orders
>>>better than some other companies'.
>>
>>Both have their advantages (though to be honest, I have to
>>think a bit before I can think of any advantage to little
>>endian that doesn't contain the word "compatibility").
> 
> 
> If you ask a hardware designer, which format should be used, any
> adder, subtracter and multiplier designer would vote for the little
> endian format. Divider and square root designers would vote for the
> big endian format :-).

Then you'd best *not* ask the hardware FFT
guy what order he wants his bits in :-).

Paul Keinanen wrote:
> If you ask a hardware designer, which format should be used, any
> adder, subtracter and multiplier designer would vote for the little
> endian format. Divider and square root designers would vote for the
> big endian format :-).

I never understood this.  If you've got a 32-bit register, why
should it matter where the byte boundaries are when doing the
add?  The add will want to start with the least significant bit
usually (assuming ripple carry instead of lookahead), but the
adder (and ALU in general) has no preference about how bytes
should be stored in RAM.  Once you've got the data internal to
the CPU, then the endianness is irrelevant.  (barring oddball
cases like i386 with its mix of register sizes)

If you've got 8-bit registers only, then it's up to software to
provide an endian convention, not hardware.  If you're doing
a byte-wise add, and have an auto-increment byte read, then
little-endian would be useful; but this is a software operation,
not something that a hardware designer would worry about.

--
Darin Johnson

On 20 Sep 2006 13:47:03 -0700, "Darin Johnson" <darin@usa.net> wrote:

>Paul Keinanen wrote:
>> If you ask a hardware designer, which format should be used, any
>> adder, subtracter and multiplier designer would vote for the little
>> endian format. Divider and square root designers would vote for the
>> big endian format :-).
>
>I never understood this.  If you've got a 32-bit register, why
>should it matter where the byte boundaries are when doing the
>add?  The add will want to start with the least significant bit
>usually (assuming ripple carry instead of lookahead), but the
>adder (and ALU in general) has no preference about how bytes
>should be stored in RAM.  Once you've got the data internal to
>the CPU, then the endianness is irrelevant.  (barring oddball
>cases like i386 with its mix of register sizes)

Take for example a processor with instructions supporting 16 or 32 bit
data but with an 8 bit external data bus and you want to add a
constant in immediate addressing mode to say, a register. The constant
is in the program memory immediately after the opcode. With little
endian convention, the lowest bits of the constant are immediately
after the opcode and can be used to start the addition and carry
generation. The low part of addition is done when the next byte
arrives and so on, until the next opcode is retrieved. 

With a big endian representation if you would start the addition as
early as possible, the PC would have to jump forward 2 or 4 bytes,
retrieve the bytes by _decrementing_ the PC and when all is done, jump
back to the next opcode. 

The other alternative would be to load the bytes in sequence into a
temporary register and only after all bytes have been loaded into the
temporary register, the addition can begin. This not a big deal if the
ALU is 32 or 64 bits wide with full carry look-ahead, but with an ALU
narrower than the largest data type, this would cause extra delay.
 
>If you've got 8-bit registers only, then it's up to software to
>provide an endian convention, not hardware.  If you're doing
>a byte-wise add, and have an auto-increment byte read, then
>little-endian would be useful; but this is a software operation,
>not something that a hardware designer would worry about.

Since the endianess issue is much about tradition, one should
remember, that in ancient decimal computers (each decimal digit stored
in BCD), the BCD ALU was only 4 bits wide and the core memory
organisation 4 or 6 bits wide, but the instruction set operated with 8
or 10 digit decimal numbers. In these systems the BCD order was also a
hardware issue. 

Paul

Paul Keinanen wrote:
> The other alternative would be to load the bytes in sequence into a
> temporary register and only after all bytes have been loaded into the
> temporary register, the addition can begin.

Don't all modern CPUs do this anyway?  It would seem like less
hardware to provide a temporary register than to provide the
control circuitry to handle a multi-step add in the ALU.  Unless
the ALU width doesn't match the register width.  If you're already
using a microprogrammed control, your ALU is 8 bits and you've
also  got 16 or 32 bit registers, then it might make sense.

Big-endian does seems like the most common design in
architectures I've seen; except that Intel sells quite a lot
of CPUs which makes Intel-endian more ubiquitous.

--
Darin Johnson

"Darin Johnson" <darin@usa.net> writes:
> Paul Keinanen wrote:
> > If you ask a hardware designer, which format should be used, any
> > adder, subtracter and multiplier designer would vote for the little
> > endian format. Divider and square root designers would vote for the
> > big endian format :-).
> 
> I never understood this.  If you've got a 32-bit register, why
> should it matter where the byte boundaries are when doing the
> add?  The add will want to start with the least significant bit
> usually (assuming ripple carry instead of lookahead), but the
> adder (and ALU in general) has no preference about how bytes
> should be stored in RAM.  Once you've got the data internal to
> the CPU, then the endianness is irrelevant.  (barring oddball
> cases like i386 with its mix of register sizes)
> 
> If you've got 8-bit registers only, then it's up to software to
> provide an endian convention, not hardware.  If you're doing
> a byte-wise add, and have an auto-increment byte read, then
> little-endian would be useful; but this is a software operation,
> not something that a hardware designer would worry about.

The hardware does force one order or the other due to
multi-byte operations' order.  If nothing else, pushing
and popping subroutine return addresses will establish
an order.  Multi-byte loads and stores is another place
where the hardware prescribes the order.

Those of us dealing with multiple target processors
from different host processors find the Endiness to be
a royal pain in the rear.