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

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

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

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

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
 

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

Vladimir Vassilevsky <antispam_bogus@hotmail.com> writes:
> Yuriy K. wrote:
> > Isaac Bosompem wrote:
> > 
> >> I must ask what do you guys think about schools using the 68HC11 as a
> >> teaching tool?
> > 
> > As long as they don't use brain-damaging PIC they are OK.
> 
> Agreed :) PIC programming makes people mentally crippled.
> 
> > HC11 is not that bad.
> 
> Ancient processor, motorola bus, high endian, dumb assembly syntax 
> (instructions like 'aba': is it a = a + b or b = b + a?), not so good 
> datasheets and manuals.

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

["Big-Endian byte order is known as 'normal', 'intuitive', or
 'obvious'.  Little-Endian is sometimes called 'perverse',
 'annoying', 'dysfunctional', or 'stupid'.  These designations
 do not, of course, imply any bias or preference."

 Christopher R. Hertel, "Implementing CIFS" 2004]

> >> Which processor do you think is best for someone just being introduced
> >> to the world of microprocessors/microcontrollers?
> > 
> > 68000, or similar CISC with index, indirect, etc. addressing
> > modes to illustrate the basics. Neumann architecture is preferable.
> > 
> >> I think the students at the
> >> University of Toronto use a full blown Freescale 68000 based system.
> >  
> > To teach basics, it is a good choice. May be even very good choice.
> > 
> An old good PC with DOS is the excellent platform for learning the 
> embedded systems.

Intel products are absolutely terrible as teaching platforms.
Why confuse the basics with all the horrid things that Intel
did?

> Cheap, simple, tons of literature, basic peripherals are
> already on the board.

And on the HC11, they're on the chip.

Isaac Bosompem wrote:

> I must ask what do you guys think about schools using the 68HC11 as a
> teaching tool?

Adequate.

> Which processor do you think is best for someone just being introduced
> to the world of microprocessors/microcontrollers?

I would prefer 6809 based systems but that would always mean more chips on
the board (and hence more expensive) to get the equivalent to the 68HC11
I/O availability. 

> For example, in my microprocessor class we are being taught how to
> program the HC11 in assembly. We are also taught to interface with an
> LCD (16x2) and an ADC and the like. I am in a lesser known University
> in Toronto (Ryerson, don't laugh). I think the students at the
> University of Toronto use a full blown Freescale 68000 based system.

The Levanthal books for each processor are better, clearer references for
the intruction set than the manuals.

> The one we have is using a fairly trivial debug monitor over RS232
> (Buffalo monitor). Even for breakpoints the host software overwrites
> the target address with a "SWI" instruction. It is pretty fun to play
> with it and cause the MCU to go into the so called "la la land".

With either system Forth would help you crawl up from the assembly level and
still allow you to include assembler code if necessary to speed things up.
This would also allow you to migrate some of the code from 68HC11 to 68000
without too much trauma.
 
-- 
********************************************************************
Paul E. Bennett ....................<email://peb@amleth.demon.co.uk>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

Yuriy K. wrote:

> Isaac Bosompem wrote:
> 
>> I must ask what do you guys think about schools using the 68HC11 as a
>> teaching tool?
> 
> 
> As long as they don't use brain-damaging PIC they are OK.

Agreed :) PIC programming makes people mentally crippled.


> HC11 is not that bad.

Ancient processor, motorola bus, high endian, dumb assembly syntax 
(instructions like 'aba': is it a = a + b or b = b + a?), not so good 
datasheets and manuals.


>> Which processor do you think is best for someone just being introduced
>> to the world of microprocessors/microcontrollers?
> 
> 
> 68000, or similar CISC with index, indirect, etc. addressing modes to 
> illustrate the basics. Neumann architecture is preferable.
> 
>> I think the students at the
>> University of Toronto use a full blown Freescale 68000 based system.
>  
> To teach basics, it is a good choice. May be even very good choice.
> 
An old good PC with DOS is the excellent platform for learning the 
embedded systems. Cheap, simple, tons of literature, basic peripherals 
are already on the board.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

http://www.abvolt.com