Everett M. Greene wrote:
> If it's switchable, which is the "natural" endiness?

The endianness that's compatible with existing software.  The
little-endian mode in many PowerPCs is a bit strange, since
it just manipulates address bits, which is a bit confusing.  Ie, it's
more of a data conversion convenience than an inherent state of
operation.  So big-endian is thus the natural ordering.  Later
processors support "true little-endian", but unless there's a good
reason to use it, big-endian ends up the default for compatiblity.

I suspect that CPUs that could work either way from the very first
model wouldn't have a "natural" endianness. 

--
Darin Johnson

Everett M. Greene wrote:
> "Darin Johnson" <darin@usa.net> writes:
> > Arlet wrote:
>
> > > I've worked with ARM processors which did have such a little/big endian
> > > switch.
> >
> > Some PowerPCs have this also.  ...
> >
> > The only reason I can think of for changing the natural endianness
> > of a processor is when you need compatibility with shared processors,
> > or you have a huge base of software that can't easily be made
> > portable.  Otherwise it's better to stick with the natural endianness
> > of the processor in question.
>
> If it's switchable, which is the "natural" endiness?

Since it's an architectural property (user model), it depends on the
switch.

David Brown wrote:
> Little-endian and big-endian come from Lilliput.

Nope. They come from India. I've just read in an Indian guy resume
about Big-Indian and Little-Indian

"Darin Johnson" <darin@usa.net> writes:
> Arlet wrote:

> > I've worked with ARM processors which did have such a little/big endian
> > switch.
> 
> Some PowerPCs have this also.  Some of them were sort of broken
> though, but others have fixed it to be usable.  The endianness can
> also change from process to process, and the interrupt handler can
> be different from the processes.  But it's just not very practical.
> It's just unnatural to go with little-endian on a PowerPC, unless
> you're writing all the software from scratch from ground up.
> Otherwise old software has to be rewritten and the manuals
> all assume big-endian.
> 
> The PowerPC has assembler load/store instructions that will
> swap the bytes with no performance loss, which further reduces
> the desire to go to little-endian.
> 
> The only reason I can think of for changing the natural endianness
> of a processor is when you need compatibility with shared processors,
> or you have a huge base of software that can't easily be made
> portable.  Otherwise it's better to stick with the natural endianness
> of the processor in question.

If it's switchable, which is the "natural" endiness?

toby wrote:
> Everett M. Greene wrote:
> > "karthikbg" <karthik.balaguru@lntinfotech.com> writes:
> > > I think, the option of toggling a Bit via software to make the
> > > processor to act as Little Endian or Big Endian as per the software
> > > developers convenience is a good idea. Does any processor have that
> > > feature Or Any difficulties in that ?
> >
> > PowerPC (I think) and ARM.  ...
>
> And at least some MIPS.

rather strangely i intend the 8 to 16 bit bus interface to load low
significant (high) byte first so ALU can calc low sum first.

cheers
http://indi.microfpga.com

Everett M. Greene wrote:
> "karthikbg" <karthik.balaguru@lntinfotech.com> writes:
> > I think, the option of toggling a Bit via software to make the
> > processor to act as Little Endian or Big Endian as per the software
> > developers convenience is a good idea. Does any processor have that
> > feature Or Any difficulties in that ?
> 
> PowerPC (I think) and ARM.  ...

And at least some MIPS.

Arlet wrote:
> I've worked with ARM processors which did have such a little/big endian
> switch.

Some PowerPCs have this also.  Some of them were sort of broken
though, but others have fixed it to be usable.  The endianness can
also change from process to process, and the interrupt handler can
be different from the processes.  But it's just not very practical.
It's just unnatural to go with little-endian on a PowerPC, unless
you're writing all the software from scratch from ground up.
Otherwise old software has to be rewritten and the manuals
all assume big-endian.

The PowerPC has assembler load/store instructions that will
swap the bytes with no performance loss, which further reduces
the desire to go to little-endian.

The only reason I can think of for changing the natural endianness
of a processor is when you need compatibility with shared processors,
or you have a huge base of software that can't easily be made
portable.  Otherwise it's better to stick with the natural endianness
of the processor in question.

--
Darin Johnson

rickman wrote:
> Grant Edwards wrote:
> > On 2006-11-17, DJ Delorie <dj@delorie.com> wrote:
> > >
> > > "karthikbg" <karthik.balaguru@lntinfotech.com> writes:
> > >> Why did Little-Endian come ?
> > >
> > > My guess is compatibility with previous processors.  I.e.  emulating
> > > an 8 bit cpu on a 16 bit LE cpu might be easier than on a 16 bit BE
> > > cpu.
> >
> > Little-endian can be a bit simpler for the hardware design
> > and/or compiler since the address you put on the bus when you
> > read a variable doesn't change depending on the destination
> > type.
> >
> > If variable X is a 32-bit integer at address 0x1234, reading it
> > as a long, char or short always generates address 0x1234. For a
> > big-endian machine, the address changes depending on how you
> > want to read the variable.  Reading it as a char generates
> > address 0x1237.  Reading it as a short generates 0x1236.
> >
> > Not a huge deal, but back in the day gates were more expensive.
>
> I can't say I undestand.  If you have a 32 bit integer, in what context
> would it be permissible to read it as a char?

In C? A cast.

> Why would this be a
> function of the hardware rather than the software?

It might be done either way, depending on architecture.

> Maybe I have been
> working with MCUs too long, but I am missing this.
>
> My understanding is that little and big endian-ness came about the same
> way that msb and lsb bit numbering came about.  Two different companies
> had different ideas of which was better. ...

Wilco Dijkstra wrote:

> "Arlet" <usenet+5@ladybug.xs4all.nl> wrote in message
> news:1164185621.616658.42420@k70g2000cwa.googlegroups.com...
>
> > I've worked with ARM processors which did have such a little/big endian
> > switch. There can be an advantage to such a switch, but it's not always
> > up to the s/w developer to make the choice. If the core has already
> > been embedded in a chip/board, there may already be h/w registers that
> > are statically configured for little- or big-endian, and in that case
> > it's usually easier to just adopt that policy.
> >
> > Personally, I would rather have a quick way to perform the conversion
> > in software, than a configurable hardware interface. The ARM, for
> > example, can do 32 bit endian swap in 3 cycles, which is usually fast
> > enough, especially if the data comes from a slower IO or memory
> > interface.
>
> Newer ARMs have instructions that do it in a single cycle. This way
> you can choose between running programs in different endians or
> let the software deal with it. You can also temporarily change the
> endian over a sequence of instructions if you need to do many
> accesses, so the cost is even lower.

Cool. I've only worked with ARM7 and ARM9 where the conversion had to
be done by hand. I've also never changed the hardware endian bit, since
all peripherals were hard wired to be little endian. A single cycle
instruction would have been useful, also because the 3-cycle manual
version uses a temp register.

Wilco Dijkstra wrote:

> "Arlet" <usenet+5@ladybug.xs4all.nl> wrote in message
> news:1164145883.069112.150030@k70g2000cwa.googlegroups.com...
> > Coos Haak wrote:
> >
> >> Op Tue, 21 Nov 2006 09:33:39 PST schreef Everett M. Greene:
> >>
> >> > Coos Haak <chforth@hccnet.nl> writes:
> >> >> Op Mon, 20 Nov 2006 10:56:37 PST schreef Everett M. Greene:
> >> >>
> >> >> <snip>
> >> >>>> My understanding was that big-endian is easier to implement in
> >> >>>> hardware,
> >> >>>> at least for a modern processor with a wide bus and load-store
> >> >>>> architecture.
> >> >>>
> >> >>> That's a good point.  It must require a lot of strange
> >> >>> internal wiring to reverse the byte order between the
> >> >>> bus and registers if the data is Little-Endian.
> >> >>
> >> >> Why, a simple inversion of the lowest address lines will do.
> >> >
> >> > If you're making a 32-bit access, the two LS bits aren't used
> >> > on a byte-addressable bus.  Inverting the two LS address bits
> >> > would work if the 32 bits were loaded one byte at a time.
> >>
> >> So, it's not as simple as I thought. I agree!
> >> I've read a bit about the Dec Alpha. Default loading and storing are
> >> little-endian there and access is in long word (4 bytes) or quad word (8
> >> bytes). Perhaps when big-endian mode is used, instruction timing could go
> >> up.
> >
> > Unlikely. Converting endianness in silicon is cheap. For a selectable
> > configuration between little-endian and big-endian it only requires an
> > additional  MUX in the datapath, with a small delay, independent of the
> > selected mode.
>
> It's cheaper than that: CPUs obviously need to support accesses of
> different widths, and the hardware you need for that can be reused.
>
> > For a fixed conversion, it's only a matter of connecting the wires in a
> > different way, which is practically free.
>
> It isn't that simple (as someone wrote above). Changing endian needs
> to be done for a multitude of access widths, and conversion is different
> for each. There is always one width with doesn't need conversion, which
> is called the endian invariant width. Older ARMs used word invariant
> endian, newer ARMs use byte invariant endian which allows the endian
> to be swapped dynamically. For example you can run a little endian
> process on a big endian OS.

True. I was just thinking about fixed widths. But even so, the extra
delay in the data path is small. Worst case, a 32 bit bus needs a 4:1
MUX for each byte, so it can swap arbitrary byte lanes.