Darin Johnson wrote:
> David Brown wrote:
>> Yes, that's about right for the PPC.  You *really* want to avoid
>> assembly programming on that thing.
> 
> PPC is pretty easy to use and learn, if you ignore the rotate and
> mask instructions (even then you can just keep a guide handy).
> I certainly found it a lot less mysterious than many other
> assemblers and easier to use.  Lots of registers, a very orthagonal
> instruction set, load/store with simple addressing modes, no LEA,
> etc.
> 

I guess it depends on what you are used to, and want to compare it with. 
  I would think that if you are aiming to generate the fastest and 
tightest code, it is easier to reach the level needed with the PPC than, 
say, the x86 instruction set (and with big processors like these, if you 
don't need fast and tight code, and are writing something more than very 
low-level stuff that C can't handle directly, then you are using the 
wrong language).  But if you are used to an ISA like the 68k and 
especially the ColdFire (which drops the most complex addressing modes, 
and adds a few more useful instructions), then the PPC set is cryptic 
nonsense, clearly designed for compilers rather than assembly programmers.

> --
> Darin Johnson
> 

Coos Haak <c...@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.

Op Tue, 21 Nov 2006 09:33:39 PST schreef Everett M. Greene:

> Coos Haak <c...@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.
-- 
Coos

Everett M. Greene wrote:
> Coos Haak <c...@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.

If you are accessing 32 bits at a time, you don't have a problem with
Endian-ness!  It only shows when you access data as bytes.  If you
access a word, you get a word.  If you ask for a byte, you get the byte
you address which is a different byte in the different Endian styles.
The address lsbs just need to be inverted when you access bytes and you
change Endian-ness.

Of course this does not fix all sins.  If you have a block of mixed
data types that was written in one Endian-ness you can't just invert
the address lsbs when you access the data in the other Endian mode.
But you can access each unit of data as the full entity (double word,
word, half word, byte) and you will get every last piece correctly.

Coos Haak wrote:

> Op Tue, 21 Nov 2006 09:33:39 PST schreef Everett M. Greene:
>
> > Coos Haak <c...@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.

For a fixed conversion, it's only a matter of connecting the wires in a
different way, which is practically free.

Arlet wrote:
> Coos Haak wrote:
>
> > Op Tue, 21 Nov 2006 09:33:39 PST schreef Everett M. Greene:
> >
> > > Coos Haak <c...@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.
>
> For a fixed conversion, it's only a matter of connecting the wires in a
> different way, which is practically free.

Do you mean to say that The Conversion/Switching Between Big & Little
Endian is simple & cheap if implemented in hardware ....
Then, Why do the modern day processors come up with Little Endian / Big
Endian alone ?
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 ?

Thx,
Karthik Balaguru

karthikbg wrote:

> Arlet wrote:
> > Coos Haak wrote:
> >
> > > Op Tue, 21 Nov 2006 09:33:39 PST schreef Everett M. Greene:
> > >
> > > > Coos Haak <c...@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.
> >
> > For a fixed conversion, it's only a matter of connecting the wires in a
> > different way, which is practically free.
>
> Do you mean to say that The Conversion/Switching Between Big & Little
> Endian is simple & cheap if implemented in hardware ....
> Then, Why do the modern day processors come up with Little Endian / Big
> Endian alone ?
> 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 ?
>
> Thx,
> Karthik Balaguru

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.

Arlet wrote:
> karthikbg wrote:
>
> > Arlet wrote:
> > > Coos Haak wrote:
> > >
> > > > Op Tue, 21 Nov 2006 09:33:39 PST schreef Everett M. Greene:
> > > >
> > > > > Coos Haak <c...@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.
> > >
> > > For a fixed conversion, it's only a matter of connecting the wires in a
> > > different way, which is practically free.
> >
> > Do you mean to say that The Conversion/Switching Between Big & Little
> > Endian is simple & cheap if implemented in hardware ....
> > Then, Why do the modern day processors come up with Little Endian / Big
> > Endian alone ?
> > 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 ?
> >
> > Thx,
> > Karthik Balaguru
>
> 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.

What kind of switch ? Is it some kind of switch that is found in
Harddisk to make it act as
either Master or Slave or some other variant of switch.

Almost everything is reprogrammable and we are in Digital world today.
I think, there must be provision to reprogram the gates and make it
Little or Big Endian based
on the toggling of a particular 'Endian PIN' (should be made) in the
processor. 

Thx,
Karthik Balaguru

karthikbg wrote:

> Arlet wrote:
> > karthikbg wrote:
> >
> > > Arlet wrote:
> > > > Coos Haak wrote:
> > > >
> > > > > Op Tue, 21 Nov 2006 09:33:39 PST schreef Everett M. Greene:
> > > > >
> > > > > > Coos Haak <c...@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.
> > > >
> > > > For a fixed conversion, it's only a matter of connecting the wires in a
> > > > different way, which is practically free.
> > >
> > > Do you mean to say that The Conversion/Switching Between Big & Little
> > > Endian is simple & cheap if implemented in hardware ....
> > > Then, Why do the modern day processors come up with Little Endian / Big
> > > Endian alone ?
> > > 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 ?
> > >
> > > Thx,
> > > Karthik Balaguru
> >
> > 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.
>
> What kind of switch ? Is it some kind of switch that is found in
> Harddisk to make it act as
> either Master or Slave or some other variant of switch.
>
> Almost everything is reprogrammable and we are in Digital world today.
> I think, there must be provision to reprogram the gates and make it
> Little or Big Endian based
> on the toggling of a particular 'Endian PIN' (should be made) in the
> processor.

The "switch" is just a bit in the ARM system coprocessor. You can write
"0" or "1" to that bit, and select the endianness.

Switching the CPU endianness is not always the answer. Sometimes you
need both, if you talk using different protocols.

"karthikbg" <k...@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.  Once someone has made the
choice as to which way it's going to operate, the
usefulness of the switch diminishes rapidly.  There
may be obscure cases where being able to dynamically
switch endiness is useful but they're extremely rare.

And as an instruction set simulator developer, I
don't even want to think about dynamic endiness!
It's bad enough to handle the case of the simulator
host and the target processor having different
endiness.