ppc LE questions (seeking help hand info pointers)

ppc LE questions (seeking help hand info pointers)

[Mark Salisbury]

I am familiar with the fact that little endian ppc linux is an unpopular
concept, but I would like to discuss it and ask a few questions about it
anyway. I do _NOT_ want to start a flame war, so if you feel the need to
flame me for this, pleas flame me directly offline and do not pollute
the list.


assume I have a valid reason for wanting to run ppc's in LE mode

assume I already have a (non-linux) ppc OS running LE mode (actually
compiles and runs in either mode, which you run depends on which flavor
of our hardware you use)  the differences in the code are limited to a
few header files, some startup code and some context switch code.
(to get an idea of the hardware see www.mc.com)

assume I am also aware of the limitations of the chip in LE mode, and
the intended target is 7400+ processors

question 1.  are there already existing patch sets (rejected from
mainline inclusion) available for use as a starting point?

question 2.  if 1, what is the primary reason for rejection.

question 3.  is there a general issue of endian safety in linux (I would
think not) or just in the ppc-specific code?

question 4. assuming I was willing to deliver a clean, complete LE
enabling patch (including devices that are relevant to me), as a compile
time config option and maintain that patch, what would be the primary
obstacle to inclusion in the main line.

thanks for your time,

		Mark

--
/*------------------------------------------------**
**   Mark Salisbury | Mercury Computer Systems    **
**   mbs@mc.com     | System OS - Kernel Team     **
**------------------------------------------------*/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ppc LE questions (seeking help hand info pointers)

[Tom Rini]

On Thu, Sep 20, 2001 at 11:42:39AM -0400, Mark Salisbury wrote:

> question 1.  are there already existing patch sets (rejected from
> mainline inclusion) available for use as a starting point?

There was a bit of work, just for the kernel.  Nothing on the toolchain
side.

> question 2.  if 1, what is the primary reason for rejection.

Being a LE & BE arch becomes a giant PITA for no gain.

> question 3.  is there a general issue of endian safety in linux (I would
> think not) or just in the ppc-specific code?

In theory the generic code is endian safe, by and large.  The arch/ppc and
include/asm-ppc stuff assumes BE.

> question 4. assuming I was willing to deliver a clean, complete LE
> enabling patch (including devices that are relevant to me), as a compile
> time config option and maintain that patch, what would be the primary
> obstacle to inclusion in the main line.

The objection to being an arch that attempts to support both LE and BE.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ppc LE questions (seeking help hand info pointers)

[Geert Uytterhoeven]

On Thu, 20 Sep 2001, Tom Rini wrote:
> On Thu, Sep 20, 2001 at 11:42:39AM -0400, Mark Salisbury wrote:
> > question 4. assuming I was willing to deliver a clean, complete LE
> > enabling patch (including devices that are relevant to me), as a compile
> > time config option and maintain that patch, what would be the primary
> > obstacle to inclusion in the main line.
>
> The objection to being an arch that attempts to support both LE and BE.

Note that we already have a precedent: mips and mipsel, both in arch/mips/.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ppc LE questions (seeking help hand info pointers)

[Tom Rini]

On Thu, Sep 20, 2001 at 06:07:48PM +0200, Geert Uytterhoeven wrote:
> On Thu, 20 Sep 2001, Tom Rini wrote:
> > On Thu, Sep 20, 2001 at 11:42:39AM -0400, Mark Salisbury wrote:
> > > question 4. assuming I was willing to deliver a clean, complete LE
> > > enabling patch (including devices that are relevant to me), as a compile
> > > time config option and maintain that patch, what would be the primary
> > > obstacle to inclusion in the main line.
> >
> > The objection to being an arch that attempts to support both LE and BE.
>
> Note that we already have a precedent: mips and mipsel, both in arch/mips/.

And SH too, iirc.  I know it can be done.  But do we want to do it is the
question.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ppc LE questions (seeking help hand info pointers)

[Brad Boyer]

Tom Rini wrote:
> On Thu, Sep 20, 2001 at 06:07:48PM +0200, Geert Uytterhoeven wrote:
> > On Thu, 20 Sep 2001, Tom Rini wrote:
> > > On Thu, Sep 20, 2001 at 11:42:39AM -0400, Mark Salisbury wrote:
> > > > question 4. assuming I was willing to deliver a clean, complete LE
> > > > enabling patch (including devices that are relevant to me), as a compile
> > > > time config option and maintain that patch, what would be the primary
> > > > obstacle to inclusion in the main line.
> > >
> > > The objection to being an arch that attempts to support both LE and BE.
> >
> > Note that we already have a precedent: mips and mipsel, both in arch/mips/.
>
> And SH too, iirc.  I know it can be done.  But do we want to do it is the
> question.

At least in the case of SH, there's a good reason. There's an external pin
that controls the native endianness of the processor, and most setups just
have it forcibly pulled high or low. I suspect the MIPS is the same reason,
since it's used in similar situations. We don't have that excuse with ppc.
Someone would have to come up with an excuse along the lines of "existing
hardware won't work unless we do this" like it would have been for SH.
(I had to work with the SH4e as used by Sega in the Dreamcast...)

	Brad Boyer
	flar@allandria.com


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ppc LE questions (seeking help hand info pointers)

[Mark Salisbury]

Tom Rini wrote:

> On Thu, Sep 20, 2001 at 11:42:39AM -0400, Mark Salisbury wrote:
>>question 1.  are there already existing patch sets (rejected from
>>mainline inclusion) available for use as a starting point?
>
> There was a bit of work, just for the kernel.  Nothing on the toolchain
> side.

could you point me to the author/code?
toolchain is not a problem, I have gcc sparc/ppc_le crosscompiler etc...


--
/*------------------------------------------------**
**   Mark Salisbury | Mercury Computer Systems    **
**   mbs@mc.com     | System OS - Kernel Team     **
**------------------------------------------------**
**  Thanks to all who sponsored me for the        **
**  Multiple Sclerosis Great Mass Getaway!!       **
**  Robert, Michele and I raised $10,000 and the  **
**  raised over $1,000,000 ride as a whole.  The  **
**  ride was great, and we didn't get rained on!  **
**  Thanks again to all of you who made this      **
**  possible!!                                    **
**------------------------------------------------*/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ppc LE questions (seeking help hand info pointers)

[Mark Salisbury]

Brad Boyer wrote:

>>>>>question 4. assuming I was willing to deliver a clean, complete LE
>>>>>enabling patch (including devices that are relevant to me), as a compile
>>>>>time config option and maintain that patch, what would be the primary
>>>>>obstacle to inclusion in the main line.
>>>>>
>>>>The objection to being an arch that attempts to support both LE and BE.
>>>>
>>>Note that we already have a precedent: mips and mipsel, both in arch/mips/.
>>>
>>And SH too, iirc.  I know it can be done.  But do we want to do it is the
>>question.
>>
>
> At least in the case of SH, there's a good reason. There's an external pin
> that controls the native endianness of the processor, and most setups just
> have it forcibly pulled high or low. I suspect the MIPS is the same reason,
> since it's used in similar situations. We don't have that excuse with ppc.
> Someone would have to come up with an excuse along the lines of "existing
> hardware won't work unless we do this" like it would have been for SH.
> (I had to work with the SH4e as used by Sega in the Dreamcast...)


well, this is in the context of a multi-CPU type (x86/ppc, sparc/ppc,
ppc/ppc, mips/ppc) shared memory multicomputer.

when dealing w/ direct mapped, shared memory, uniformity of endian-ness
makes many multicomputer problems easier to solve.(not to mention easier
for the customer to program...)




--
/*------------------------------------------------**
**   Mark Salisbury | Mercury Computer Systems    **
**   mbs@mc.com     | System OS - Kernel Team     **
**------------------------------------------------**
**  Thanks to all who sponsored me for the        **
**  Multiple Sclerosis Great Mass Getaway!!       **
**  Robert, Michele and I raised $10,000 and the  **
**  raised over $1,000,000 ride as a whole.  The  **
**  ride was great, and we didn't get rained on!  **
**  Thanks again to all of you who made this      **
**  possible!!                                    **
**------------------------------------------------*/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ppc LE questions (seeking help hand info pointers)

[Tom Rini]

On Thu, Sep 20, 2001 at 02:28:03PM -0400, Mark Salisbury wrote:
> Tom Rini wrote:
>
> >On Thu, Sep 20, 2001 at 11:42:39AM -0400, Mark Salisbury wrote:
> >>question 1.  are there already existing patch sets (rejected from
> >>mainline inclusion) available for use as a starting point?
> >
> >There was a bit of work, just for the kernel.  Nothing on the toolchain
> >side.
>
> could you point me to the author/code?

Unfortunatly all I've got in my inbox is 4xx-specific.  Try the archives.

> toolchain is not a problem, I have gcc sparc/ppc_le crosscompiler etc...

That doesn't mean there aren't issues.  PPC-LE isn't that well tested..

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ppc LE questions (seeking help hand info pointers)

[Holger Bettag]

Mark Salisbury <mbs@mc.com> writes:

[... linux in ppc little endian mode ...]
> well, this is in the context of a multi-CPU type (x86/ppc, sparc/ppc,
> ppc/ppc, mips/ppc) shared memory multicomputer.
>
> when dealing w/ direct mapped, shared memory, uniformity of endian-ness
> makes many multicomputer problems easier to solve.(not to mention easier
> for the customer to program...)
>
You are aware that a PPC in little endian mode is merely tricking with the
low order address bits, but does not actually lay out its data in a little
endian fashion in physical memory?

  Holger


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ppc LE questions (seeking help hand info pointers)

[David Edelsohn]

>>>>> Holger Bettag writes:

Holger> You are aware that a PPC in little endian mode is merely tricking with the
Holger> low order address bits, but does not actually lay out its data in a little
Holger> endian fashion in physical memory?

	This is why Mark said "assume I am also aware of the limiations of
the chip in LE mode and the intended target is 7400+ processors".
Motorola has added a more complete LE mode.

David

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ppc LE questions (seeking help hand info pointers)

[Tony Mantler]

At 1:32 PM -0500 9/20/01, Mark Salisbury wrote:
[...]
>when dealing w/ direct mapped, shared memory, uniformity of endian-ness
>makes many multicomputer problems easier to solve.(not to mention easier
>for the customer to program...)
[...]

Endian-safe code isn't terribly difficult to write. The PPC even has some
very nice little-endian load and store operations which are easily
accessable in big-endian mode, and obviously don't carry any of the baggage
of running in le mode.

Not to flame or anything, but "my customers are lazy and don't want to
write portable code" isn't a very good reason to change the kernel.


Cheers - Tony 'Nicoya' Mantler :)


--
Tony "Nicoya" Mantler - Renaissance Nerd Extraordinaire - nicoya@apia.dhs.org
Winnipeg, Manitoba, Canada           --           http://nicoya.feline.pp.se/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ppc LE questions (seeking help hand info pointers)

[Mark Salisbury]

Holger Bettag wrote:

> Mark Salisbury <mbs@mc.com> writes:
>
> [... linux in ppc little endian mode ...]
>
>>well, this is in the context of a multi-CPU type (x86/ppc, sparc/ppc,
>>ppc/ppc, mips/ppc) shared memory multicomputer.
>>
>>when dealing w/ direct mapped, shared memory, uniformity of endian-ness
>>makes many multicomputer problems easier to solve.(not to mention easier
>>for the customer to program...)
>>
>>
> You are aware that a PPC in little endian mode is merely tricking with the
> low order address bits, but does not actually lay out its data in a little
> endian fashion in physical memory?
>

not according to section 3.1 of the motorola ppc "green book"

according to that it is a sort of munged le representation,

which thanks to a "one trick pony" PCI bridge looks like standard LE to
the PCI based  x86 host.

understand please that what I am proposing is a config option. as a
sub-architecture port.  it would not affect any code that it didn't
absolutely need to, and would only be compiled if sombody selected that
particular config.

I am _NOT_ suggesting running pmacs in LE mode.

as in:
ppc---
      |-- PREP
      |-- CHRP
      |-- MAC
      |-- MERCURY ---
                    |-- Big Endian
                    |-- Little Endian






--
/*------------------------------------------------**
**   Mark Salisbury | Mercury Computer Systems    **
**   mbs@mc.com     | System OS - Kernel Team     **
**------------------------------------------------**
**         Infinite Justice is niether.           **
**------------------------------------------------*/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ppc LE questions (seeking help hand info pointers)

[Dan Malek]

Mark Salisbury wrote:

> assume I have a valid reason for wanting to run ppc's in LE mode

This is where it starts to fall apart.  I didn't know there were
any valid reasons to support LE mode, except to run some software
from a certain company that never materialized.  I was fortunate to
be part of the PowerPC design discussions from the beginning.  The LE
mode was never popular.

A technical reason is the PowerPC never supported a true little
endian mode.  It basically does byte swapping between the cache
and core processing units, and I believe always (or at least usually)
supported a big endian bus.  You can't properly attach the processor
to true little endian busses or devices when this is done, so you don't
gain any hardware design advantage.  As you know, properly byte
swapping depends upon the size of the object, so if you happen
to access something in smaller units than it's natural size you
aren't going to get the results you expect.  For someone that is
comfortable programming in an LE environment (is there anyone? :-),
this will eventually bite you.

Another technical reason is as the processor family moves forward,
less and less little endian support is provided.  In the case of
the 7450, there are instructions that trap to the kernel to be
emulated in LE mode, that are executed in the core in BE mode.

> question 2.  if 1, what is the primary reason for rejection.

It was LE (sorry, couldn't resist :-)?

> question 3.  is there a general issue of endian safety in linux (I would
> think not) or just in the ppc-specific code?

Linux is very aware of endian issues.  For all but I guess two of
you now, everyone assumes PowerPC is big endian and we make adjustments
when working on little endian I/O.  Without hardware for testing,
the rest of us are just likely to break any LE software, and you
are just going to end up chasing fixes behind lots of the rest of us.

> ..........what would be the primary
> obstacle to inclusion in the main line.

Like I always say, the kernel is the easy part.  None of us have
the hardware, tools, libraries, or applications to utilize a LE kernel.
It more than doubles the work we need to do trying to keep the
software up to date, if we had all of that for testing.  It may
be easier to just keep your patch up to date, than to try and keep
up with the rest of us making changes to software we can't test.


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ppc LE questions (seeking help hand info pointers)

[Timothy A. Seufert]

At 4:19 PM -0400 9/20/01, Mark Salisbury wrote:
>Holger Bettag wrote:
>
>>  You are aware that a PPC in little endian mode is merely tricking with the
>>  low order address bits, but does not actually lay out its data in a little
>>  endian fashion in physical memory?
>
>not according to section 3.1 of the motorola ppc "green book"
>
>according to that it is a sort of munged le representation,

Nope.  Read section 3.1 very carefully.  Data in memory is still
organized in BE order.  Another reference: 9.3.2 in the MPC7400
manual.

The "munging" plays with low order address bits in an attempt to make
porting LE software easier.  When software tries to access a
multibyte data item with a granularity other than that native to the
data (e.g. a library routine for printing FP numbers which accesses
floats & doubles a byte at a time), it assumes either LE or BE
offsets within the larger data item.  Munging makes it possible to
run software that assumes LE internal offsets even though the
processor and memory layout are BE.

>which thanks to a "one trick pony" PCI bridge looks like standard LE to
>the PCI based  x86 host.

As a hardware guy, I recommend that (if you have not done so already)
you get with your hardware guys and make Really, Really Sure that the
PCI bridge actually can translate PPC pseudo-LE address munging to
real LE.  It will have to demunge/munge addresses that travel through
the bridge *and* swap bytes.

IMO, munging is likely to make your life (and that of all who use
your platform with munging turned on) harder rather than easier.

Actually, even just swapping in the bridge is likely to do that too,
unless you have enough control over when the bridge swaps to restrict
it to very specific things.  (e.g. if you can tell it "swap
everything in this address region with a granularity of 32 bits",
that's useful, but "swap everything" is likely to be a pain.)

>understand please that what I am proposing is a config option. as a
>sub-architecture port.  it would not affect any code that it didn't
>absolutely need to, and would only be compiled if sombody selected that
>particular config.

I don't think anybody had assumed otherwise, but the thing is that
given the way it works, PPC LE would require large changes in the
kernel tree regardless.  Linux has the infrastructure needed to
support LE and BE architectures, but has none for anything like PPC
LE mode.  I submit that the changes necessary are unlikely to be
accepted into standard trees, because it will uglify huge swaths of
code in order to support a CPU mode that can best be described as a
bizarre hack.

(Specifically: in order to support PPC-LE, all the hardware drivers
needed for your platform will need to be rewritten to be aware of
munging.  The alternative is to make the kernel run in regular BE
mode while some or all of userspace runs in the hack mode, but *that*
requires an astounding ugliness: a translation layer sitting between
the kernel and userland.)

I'm pretty certain PPC-LE would require modifications to the toolchain too.



Finally, Book E has been mentioned.  I read through the relevant
stuff and it looks to me like Book E PowerPC does offer a useful
feature: a TLB entry bit (bit 'E' for endian) which marks a page as
little endian.  The semantics are that a regular load/store whose
effective address lies inside a page with bit E set operates like a
byteswapping form of the same load/store instruction, and vice versa.
Advantage compared to simply using the byteswapping forms of the
instructions: you get the full range of load/store instructions
rather than just the subset that have explicit byteswapping variants,
and no use of assembly or funky compiler tricks is required when
writing code to access such a memory region.

Unfortunately, Book E does not guarantee that the 'E' TLB entry bit
is really supported in hardware: the CPU may have to take exceptions
to emulate it.  Even when hardware support is there, they still allow
for implementations that must take an exception to perform a static
mode switch whenever a page differing in endianness from the last
memory access is touched.

But so far as I can tell, the 750, 7400, 7450, etc. are not Book E
PowerPC, so the only thing they have is the MSR[LE] mode bit (address
munging).

Too bad this part of Book E wasn't in the architecture from the start...
--
Tim Seufert

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ppc LE questions (seeking help hand info pointers)

[Dan Malek]

"Timothy A. Seufert" wrote:

> Finally, Book E has been mentioned.

Too bad.....

> ... a TLB entry bit (bit 'E' for endian) which marks a page as
> little endian.

This has been discussed in the past and suffers from the same
problem as trying to byte swap in a bridge.  Although you can use
any load/store in this space, unless you are performing the access
on the natural size of the object it won't have the proper effect.
Since you must require that knowledge, it is just as easy to choose
the proper byte swapping variant of the instruction.

> Unfortunately, Book E does not guarantee that the 'E' TLB entry bit
> is really supported in hardware:

For all practical purposes, the engineering world is already used
to working with the advantages of a big endian processor and dealing
with the issues of accomodating little endian when necessary.  Adding
a feature like this only complicates the use of legacy software and
creates significant discussion for a feature trying to find a
problem to solve.  This feature isn't a performance enhancement,
only a detriment because it requires additional software to manage
something not natural to use.  I suspect it was just easier to write
this into the specification (i.e. it's there but not required) than
spending time discussing it's technical merit.


> But so far as I can tell, the 750, 7400, 7450, etc. are not Book E

Thankfully.

> Too bad this part of Book E wasn't in the architecture from the start...

You are one of few to feel that way.  Those of us that have worked
with PowerPC from the start, and were part of the original design
discussions, view Book E as a totally new processor that may execute
similar instructions to traditional PowerPC.  I have spoken with several
embedded product companies, a couple very large, that have huge
investments in PowerPC software that are now trying to determine
what to do.  They are quite upset that they now have to invest in
a new processor design, and it makes them likely to choose something
else.  Motorola has proven you can build some very powerful embedded
processors with the traditional PowerPC core and memory mapped I/O
peripherals, a very nice and efficient programming environment.  The
Book E appears to be a marketing vehicle put together by people that
didn't understand or appreciate the previous PowerPC architecture
specifications.  We can hope the where Book E allows variation and
extension, designers will borrow from traditional PowerPC and not
go in some other "creative" direction :-).

I'm not really saying anything new here, this has been discussed
among all of us that work on PowerPC ever since the Book E announcement
long ago.

I guess I better go looking for those m68k projects now :-).


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ppc LE questions (seeking help hand info pointers)

[Albert D. Cahalan]

Dan Malek writes:

> Another technical reason is as the processor family moves forward,
> less and less little endian support is provided. In the case of
> the 7450, there are instructions that trap to the kernel to be
> emulated in LE mode, that are executed in the core in BE mode.

Quit spreading FUD. The 7450 has _better_ LE support than the 7400
and 7410 did. With the 7450, misaligned LE memory operations now
perform just as well as misaligned BE memory operations.

I checked the errata too. Total BE/LE differences I found:


1. TLBMISS always has a BE address. Motorola's example code for
   software TLB reloads has a "xori" instruction to deal with this.

2. No string/multi load/store instructions in LE mode.
   According to Motorola's 32-bit arch book, these instructions
   are expected to be slow anyway. (They sure aren't RISC!)
   Indeed, the 7450 doesn't handle them well even in BE mode.

3. The MPC106 chip ("Grackle" host bridge) won't work.

4. The MPC107 chip (another host bridge) won't tolerate unaligned data.

5. LE mode enables address munging. :-)

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ppc LE questions (seeking help hand info pointers)

[Troy Benjegerdes]

> question 4. assuming I was willing to deliver a clean, complete LE
> enabling patch (including devices that are relevant to me), as a compile
> time config option and maintain that patch, what would be the primary
> obstacle to inclusion in the main line.

I think the primary obstacle is that we already have enough problems
breaking obscure machines (embedded, or some old PReP box) whenever
something gets changed.

I suspect it's going to be a signifigant workload to keep a 'ppcle'
up-to-date, and most importantly, working.. you may be better off
maintaining a patch for LE support for the near future.

I for one, would like to see how small one could get a clean, working LE
patch for linux.

If the code isn't intrusive, and forces us to clean up abstraction layers
in headers and such, it could probably be a good thing.

This whole discusion is mostly academic and (in this case) somewhat
incendiary until someone shows up with working code.

My suggestion is go make it work, and if you find ways to clean up the
general PPC code in the process, this will definitely help.

--
Troy Benjegerdes | master of mispeeling | 'da hozer' |  hozer@drgw.net
-----"If this message isn't misspelled, I didn't write it" -- Me -----
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's
why I draw cartoons. It's my life." -- Charles Shulz

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ppc LE questions (seeking help hand info pointers)

[Dan Malek]

"Albert D. Cahalan" wrote:

> Quit spreading FUD. The 7450 has _better_ LE support than the 7400
> and 7410 did.

If you say so.....I grabbed my 740 manual, which seems to indicate
only alignment errors caused alignment faults.  The 7540 actually
lists instructions that entirely fault in LE mode.  Didn't seem
like an improvement to me.  Sorry I didn't look at the 7400.....
I guess I'll let the LE experts decide what to do since I don't
know anything about it.

Thanks.


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ppc LE questions (seeking help hand info pointers)

[Geert Uytterhoeven]

On Thu, 20 Sep 2001, Timothy A. Seufert wrote:
> At 4:19 PM -0400 9/20/01, Mark Salisbury wrote:
> >Holger Bettag wrote:
> (Specifically: in order to support PPC-LE, all the hardware drivers
> needed for your platform will need to be rewritten to be aware of
> munging.  The alternative is to make the kernel run in regular BE

But PCI drivers already use readl() and friends, so the differences can be
hidden there? => no driver changes.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ppc LE questions (seeking help hand info pointers)

[Geert Uytterhoeven]

On Thu, 20 Sep 2001, Dan Malek wrote:
> "Timothy A. Seufert" wrote:
> > Finally, Book E has been mentioned.
>
> Too bad.....
>
> > ... a TLB entry bit (bit 'E' for endian) which marks a page as
> > little endian.
>
> This has been discussed in the past and suffers from the same
> problem as trying to byte swap in a bridge.  Although you can use
> any load/store in this space, unless you are performing the access
> on the natural size of the object it won't have the proper effect.
> Since you must require that knowledge, it is just as easy to choose
> the proper byte swapping variant of the instruction.

Anyone who knows how this differs from the similar bit on UltraSPARC?

> I guess I better go looking for those m68k projects now :-).

Good! We can use some help to keep the old platforms alive... AFAIK the
working platform support decreased to Amiga, Q40, Sun3[x], and Mac in 2.4.x...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ppc LE questions (seeking help hand info pointers)

[Dan Malek]

Geert Uytterhoeven wrote:

> Anyone who knows how this differs from the similar bit on UltraSPARC?

Hmmm...I guess it's time to go fishing again in another architecture.
I haven't visited SPARC for a while.  Do they actually use it in Linux?

> Good! We can use some help to keep the old platforms alive...

...and I have old platforms :-).  I'm afraid to apply power to some of them.....


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ppc LE questions (seeking help hand info pointers)

[Geert Uytterhoeven]

On Fri, 21 Sep 2001, Dan Malek wrote:
> Geert Uytterhoeven wrote:
> > Anyone who knows how this differs from the similar bit on UltraSPARC?
>
> Hmmm...I guess it's time to go fishing again in another architecture.
> I haven't visited SPARC for a while.  Do they actually use it in Linux?

AFAIK they do, for PCI accesses.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ppc LE questions (seeking help hand info pointers)

[Dan Malek]

Geert Uytterhoeven wrote:

> AFAIK they do, for PCI accesses.

They do the same thing we do.  The ULTRASparc has address modifiers on the
load/store instructions to do byte swapping in the io macros, just like us.
The "other" Sparcs do it the hard way with actual byte swap code in the
macros.  There are comments in various files that clearly state Sparc is
big-endian without exception :-).


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ppc LE questions (seeking help hand info pointers)

[Ralph Blach]

One the 405 processors, with the endian bit set, the data is will be
true little endian.

Chip

Holger Bettag wrote:
>
> Mark Salisbury <mbs@mc.com> writes:
>
> [... linux in ppc little endian mode ...]
> > well, this is in the context of a multi-CPU type (x86/ppc, sparc/ppc,
> > ppc/ppc, mips/ppc) shared memory multicomputer.
> >
> > when dealing w/ direct mapped, shared memory, uniformity of endian-ness
> > makes many multicomputer problems easier to solve.(not to mention easier
> > for the customer to program...)
> >
> You are aware that a PPC in little endian mode is merely tricking with the
> low order address bits, but does not actually lay out its data in a little
> endian fashion in physical memory?
>
>   Holger
>

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ppc LE questions (seeking help hand info pointers)

[Ralph Blach]

Dan,

The 4xx has true little endian support.

Chip

Dan Malek wrote:
>
> "Albert D. Cahalan" wrote:
>
> > Quit spreading FUD. The 7450 has _better_ LE support than the 7400
> > and 7410 did.
>
> If you say so.....I grabbed my 740 manual, which seems to indicate
> only alignment errors caused alignment faults.  The 7540 actually
> lists instructions that entirely fault in LE mode.  Didn't seem
> like an improvement to me.  Sorry I didn't look at the 7400.....
> I guess I'll let the LE experts decide what to do since I don't
> know anything about it.
>
> Thanks.
>
>         -- Dan
>

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ppc LE questions (seeking help hand info pointers)

[Ralph Blach]

I just wanted to clear up some inaccuracies in this previous note.

Dan Malek wrote:
>
> "Timothy A. Seufert" wrote:
>
> > Finally, Book E has been mentioned.
>
> Too bad.....
>
> > ... a TLB entry bit (bit 'E' for endian) which marks a page as
> > little endian.
>
> This has been discussed in the past and suffers from the same
> problem as trying to byte swap in a bridge.  Although you can use
> any load/store in this space, unless you are performing the access
> on the natural size of the object it won't have the proper effect.
> Since you must require that knowledge, it is just as easy to choose
> the proper byte swapping variant of the instruction.
>
This is NOT true on the 405 core processors.  They support TRUE little
endian.

> > Unfortunately, Book E does not guarantee that the 'E' TLB entry bit
> > is really supported in hardware:
>
> For all practical purposes, the engineering world is already used
> to working with the advantages of a big endian processor and dealing
> with the issues of accomodating little endian when necessary.  Adding
> a feature like this only complicates the use of legacy software and
> creates significant discussion for a feature trying to find a
> problem to solve.  This feature isn't a performance enhancement,
> only a detriment because it requires additional software to manage
> something not natural to use.  I suspect it was just easier to write
> this into the specification (i.e. it's there but not required) than
> spending time discussing it's technical merit.
>
The book E specification requires the little endian bit.  It must be
there for the processor to be a Book E.
> > But so far as I can tell, the 750, 7400, 7450, etc. are not Book E
>
> Thankfully.
>
> > Too bad this part of Book E wasn't in the architecture from the start...
>
> You are one of few to feel that way.  Those of us that have worked
> with PowerPC from the start, and were part of the original design
> discussions, view Book E as a totally new processor that may execute
> similar instructions to traditional PowerPC.  I have spoken with several
> embedded product companies, a couple very large, that have huge
> investments in PowerPC software that are now trying to determine
> what to do.  They are quite upset that they now have to invest in
> a new processor design, and it makes them likely to choose something
> else.  Motorola has proven you can build some very powerful embedded
> processors with the traditional PowerPC core and memory mapped I/O
> peripherals, a very nice and efficient programming environment.  The
> Book E appears to be a marketing vehicle put together by people that
> didn't understand or appreciate the previous PowerPC architecture
> specifications.  We can hope the where Book E allows variation and
> extension, designers will borrow from traditional PowerPC and not
> go in some other "creative" direction :-).

I know the discussions on Book E are incorrect.  I have had the
privilege here in
IBM to work on the 440gp processor.  Although my knowledge of powerpc is
far from complete, I can tell everybody that from my experience that the
Book E architecture is superior.

There are two things that make it superior.
1)Not turning off translation when an interrupt is taken
2)The IVOR registers which allow the system interrupts to be place
correctly.

If one stops to think about it, running Linux out of Ram on a PCI card
becomes very easy.  This is because the processor does NOT have to fetch
all interrupts from
physical location 0.  And now the interrupt routines run with protection
ON, so protection of task by bad operations in the interrupt handler is
now possible.
This will lead to a more secure OS.

I believe that Book E processor which have been announced by both
Motorola and IBM
will be VERY successful.
>
> I'm not really saying anything new here, this has been discussed
> among all of us that work on PowerPC ever since the Book E announcement
> long ago.
>
> I guess I better go looking for those m68k projects now :-).
Too bad you feel this way.  Book E is definitely better and I am sure,
that once you
got one, you would have 100 great ideas on how linux could use its
features.

I am personally excited by the future of book E.  The Engineers here
working on delivering it are simply the best with whom I have every
worked.  ( I have been at IBM for over 20 years).


>
>         -- Dan
>

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ppc LE questions (seeking help hand info pointers)

[David Edelsohn]

>>>>> Ralph Blach writes:

Ralph> I know the discussions on Book E are incorrect.  I have had the
Ralph> privilege here in
Ralph> IBM to work on the 440gp processor.  Although my knowledge of powerpc is
Ralph> far from complete, I can tell everybody that from my experience that the
Ralph> Book E architecture is superior.

Ralph> I believe that Book E processor which have been announced by both
Ralph> Motorola and IBM
Ralph> will be VERY successful.

Ralph> I am personally excited by the future of book E.  The Engineers here
Ralph> working on delivering it are simply the best with whom I have every
Ralph> worked.  ( I have been at IBM for over 20 years).

	I wish that you had not made these statements because you now
force others from IBM to disagree with you in public or let people assume
your opinion uniformly represents IBM.  This isn't a question of the
quality of the implementation by engineers, it is a question of the design
itself.  Making categorical statements that "you know" something is very
dangerous.

	PowerPC Book E effectively is a different architecture.  The User
Instruction Set Architecture (UISA) changes address perceived problems
which never really existed.  It is a fine architecture for its purpose,
but it complicates the ability to share user code and tools with the rest
of the PowerPC world and undermines the unifying opportunity for the
PowerPC architecture scaling across a wide range of uses.

	Your comments of praise focus completely on Supervisor mode
changes.  If the designers of the Book E architecture had left the Book I
UISA alone for compatibility with the original PowerPC archiecture, I
believe that everyone would be a lot happier and more uniformly
supportive.  There is a lot more agreement that the Supervisor mode
changes are useful for the embedded market -- the target of "Book E".  I
wish that the PowerPC Book E architecture designers had limited themselves
to modifications which were not visible to user programs.

	Change comes with a cost; compatibility is important too.

David

	P.S. The above comments are my own opinion and are not intended to
imply that they represent any company or organization.  The same applies
to Ralph's comments which should have included an equivalent disclaimer.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ppc LE questions (seeking help hand info pointers)

[Albert D. Cahalan]

It is clear to me that most people don't truly understand the
implications of address munging when running the PowerPC in
little-endian mode. I'll try to explain.

The important point: motherboards make all the difference

On a Mac, you have a big-endian CPU crudely connected to the
little-endian PCI bus. You have to swap bytes. If you put the
CPU into little-endian mode, you end up with big-endian data
going to the wrong addresses. Everything looks little-endian
to the CPU, but PCI now needs address anti-munging in addition
to the byte swapping that the ppc port already does. Badness!
(though a little-endian user-space would be fine with this)

Now do an unconditional 64-bit byte swap on the motherboard.
Consider an array of four __u16 values affected by this.
They get converted from big-endian to little-endian, and they
get moved to different addresses. Excellent! All the weirdness
just cancels out, giving perfect little-endian. This works for
8-bit, 16-bit, 32-bit, and 64-bit data. Life is good.
For correct PCI operation, just disable the byte swapping
currently done by the IO access macros. Drivers will work.

Given a little-endian motherboard (reversed byte lanes), running
the CPU in the normal big-endian mode would require the same
sort of anti-munging that you'd need for little-endian on a Mac.

To make this extra clear, I'll explain why the Mac doesn't do
motherboard-based swapping for PCI. Apple had to run the ppc
in big-endian mode to keep 680x0 developers happy, to help with
680x0 emulation, and maybe to work well with NuBUS. The PCI host
bridge won't always be aware of data sizes due to write combining
and compiler optimization, so it can't fix things nicely. Apple
could have done an unconditional 64-bit swap, fixing the byte
order while screwing up the addresses... eh, why bother?

Thus one should run the CPU in little-endian mode if and only
if one has a motherboard that does an unconditional 64-bit swap.

Mark does have such a motherboard, and does have the toolchain.
So, no need to hassle him about the need for LE or his ability
to compile stuff correctly.

Changes needed for 75x0 chips on little-endian motherboards:

1. new MSR values
2. load the whole MSR, not just the lower half
3. a way to disable the PCI byte swapping that the ppc port does
4. a "xori" instruction if using the 7450's software TLB reload
5. removal of crummy load/store string/multiple instructions
6. write page table entries with a 64-bit write, or word swap

Changes needed for the 405 chip, AFAIK:

1. a way to disable the PCI byte swapping that the ppc port does
2. one bit different in the TLB entries

Changes needed for 75x0 chips on the Mac, if feeling insane:

1. new MSR values
2. load the whole MSR, not just the lower half
3. PCI address anti-munging (keep existing byte swap too)
4. a "xori" instruction if using the 7450's software TLB reload
5. removal of crummy load/store string/multiple instructions
6. write page table entries with a 64-bit write, or word swap


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ppc LE questions (seeking help hand info pointers)

[David Edelsohn]

>>>>> Ralph Blach writes:

Ralph> Although my knowledge of powerpc is
Ralph> far from complete, I can tell everybody that from my experience that the
Ralph> Book E architecture is superior.

Ralph> I believe that Book E processor which have been announced by both
Ralph> Motorola and IBM will be VERY successful.

	Let me clarify a point in my previous reply: the PowerPC Book E
changes to the PowerPC Book I UISA affect 64-bit PowerPC only.  The 32-bit
subset of PowerPC Book E is compatible with the rest of the PowerPC
architecture family.  IBM's PowerPC 440GP implements the 32-bit PowerPC
Book E architecture.

	As I said in my original message, the supervisor and non-UISA
changes are very useful and have a lot of support from the embedded
PowerPC developer community.  The IBM PowerPC 440GP and other 32-bit
PowerPC Book E chips implement the areas of agreement and compatibility
which create broad support for the PPC 440GP chip and the PowerPC
architecture.  I am happy when the various chip implementations in the
PowerPC architecture family complement and reinforce each other.

David

	P.S. The above comments are my own opinion and are not intended to
imply that they represent any company or organization.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ppc LE questions (seeking help hand info pointers)

[Dan Malek]

Ralph Blach wrote:

> I just wanted to clear up some inaccuracies in this previous note.

Ok, before this discussion gets further out of control, and I
get blamed for many things, I want you to know that Book E has
been discussed among many people on these mailing lists ever
since the specification was public.  I just happened be working
at 4 AM when these previous messages were posted, and (as I
indicated) I was posting a summary of lots of discussions that
have occurred in the past.  Unfortunetly, this gets represented
as _my_ view, when the purpose is to discuss what we are going to
do to accomodate these new architectures.

The 405GP is the first Book E type processor that has had a
significant impact in Linux.  Yes, there was some early 403
that Tivo used successfully, but those were some localized
modifications specific to the product and didn't lend themselves
to be merged and carried forward without breaking other things.

In the case of the 405, for the past six months about all I have
been doing is taking patches from many others, making the
necessary changes so they can be applied to the current trees,
and then testing to ensure we didn't break something else.  This
is a very time consuming process, some of it done on my own
free time (as I have other development obligations), and I can
hardly take credit for any new development.  All I have done is
tried to make the 4xx port better fit with the others.  This must
have been somewhat successful, because the software updates from
people around the world keep increasing, and we are able to
immediately use the latest software enhancements to Linux.

The first discussions about Book E among the PowerPC developers
was whether we treat it as a new architecture or try to integrate
it with the traditional PowerPC source code base.  Although from
a user application perspective it will likely execute 32-bit code
like past PowerPC cores, from the kernel perspective it is very
different.  No one was interested in starting up a new architecture,
especially for a new processor that wasn't even available to
those of us working on Linux.  The only way Book E was going to
be initially successful was to make it somehow fit into the
traditional PowerPC baseline.  That, too, seems like a pretty
good decision, as the interest in Linux and 405 is high and
continues to grow.

Now that we have established a base of software and a growing
group of users, after we get to look at another processor from
the Book E family perhaps it is time to start a new architecture
tree.  This isn't something to be taken lightly, as it requires
a dedication to the development like we have for the existing
PowerPC development.  I'm certain some of us will play in both
camps (at least I hope so :-), but we can't afford to spread our
existing PowerPC resources even thinner, as no one will benefit.

There are advantages to using Book E over other processors, but
keep in mind there are few architectural features that haven't
been used in the past or currently exist on other processors.
Processors support a wide range of features to address a wide
range of (sometimes disparate) requirements that just simply
don't allow reasonably using all of the features all of the time.
We need to venture into the other architecture spaces and
learn from them.  The recently highly contentious byte swap
page mapping is clearly one of these.  Other processors appear
to support it, but developers haven't chosen to use it in a
Linux environment.

I have had lots of fun and much success developing software for
the PowerPC processor family.  The Book E is now part of that
development and I intend to do the same for it.  From the
perspective of the Linux kernel, Book E is very different from
the traditional PowerPC, we have to admit that, adjust for it,
and continue to make it successful.  The current PowerPC is about
10 years old, and some of the best things just don't happen
overnight.

The Linux software development has to continue in the same democratic
way it has in the past that has made it so successful.  Simply
demanding something and getting pissed when _I_ don't immmediately
implement it is not the road to success and happiness.  Like
many others, I have invested years of personal time at the expense
of other life opportunities on PowerPC Linux development.  There
are things I would like to change, but consensus is necessary
among everyone to ensure features are properly implemented and
maintained.

So, let's keep some constructive technical discussions going and
please keep sending your source code updates.

Thanks.


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ppc LE questions (seeking help hand info pointers)

[Benjamin Herrenschmidt]

>There are two things that make it superior.
>1)Not turning off translation when an interrupt is taken
>2)The IVOR registers which allow the system interrupts to be place
>correctly.
>
>If one stops to think about it, running Linux out of Ram on a PCI card
>becomes very easy.  This is because the processor does NOT have to fetch
>all interrupts from
>physical location 0.  And now the interrupt routines run with protection
>ON, so protection of task by bad operations in the interrupt handler is
>now possible.
>This will lead to a more secure OS.

While I don't want to take a side in the LE vs. not LE debate, I don't
agree with you on this specific point about interrupts running with MMU
enabled.

First of all, on Linux, and I beleive any sane OS, the exceptions vectors
do their job of saving the context, and then jump to the high level (read
"C") exception handling with the MMU turned back on. So except for the
exception handler low level code itself, there's no security gain here.
And if the exception handler itself is bogus or has holes, then there's
nothing we can do against programmer incompetence.

On the other side, running with MMU ON makes that small task of setting
up the kernel environement on exception entry and unwiding it on
exception exit a lot more tricky. It prevents using MMU off as an
efficient way of using SRR0/SRR1 without caring about taking TLB misses
during critical code patBeWell, I won't argue with you on this ;)

While I don't say the Book E is better or worse than other PPCs (I didn't
look at the specs well enough to say, it might actually be the "killer"
architecture you are talking about ;), I don't agree on the benefit of
the feature outlined above.

Regards,
Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ppc LE questions (seeking help hand info pointers)

[Benjamin Herrenschmidt]

Sorry, part of my previous post got "eaten" by my mailer, here it is.

>On the other side, running with MMU ON makes that small task of setting
>up the kernel environement on exception entry and unwiding it on
>exception exit a lot more tricky. It prevents using MMU off as an
>efficient way of using SRR0/SRR1 without caring about taking TLB misses
>during critical code pat....

So, I was saying that it prevents using MMU off as an efficient wau to
avoid taking TLB misses during those critical code path. Having the
translations always enabled force you to pin down at least one TLB entry
which makes the TLB handlers more complicated (and so adds overhead). It
also make the exception entry/exit path more tricky as those have to
touch datas not covered by pinned TLB entries (like process stacks), more
or less forcing us to use specific exception stacks (pinned down) to
avoid horrible bloat.

This will make some bits of the 32 bits kernel almost as tricky as when
running below Hypervisor on LPAR :)

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ppc LE questions (seeking help hand info pointers)

[Timothy A. Seufert]

At 2:48 PM -0400 9/21/01, Albert D. Cahalan wrote:

>Now do an unconditional 64-bit byte swap on the motherboard.
>Consider an array of four __u16 values affected by this.
>They get converted from big-endian to little-endian, and they
>get moved to different addresses. Excellent! All the weirdness
>just cancels out, giving perfect little-endian. This works for
>8-bit, 16-bit, 32-bit, and 64-bit data. Life is good.
>For correct PCI operation, just disable the byte swapping
>currently done by the IO access macros. Drivers will work.

OK.  I was going to object that it would break on misaligned data but
after working out an example it appears that works too.

>To make this extra clear, I'll explain why the Mac doesn't do
>motherboard-based swapping for PCI. Apple had to run the ppc
>in big-endian mode to keep 680x0 developers happy, to help with
>680x0 emulation, and maybe to work well with NuBUS.

Also because the early PowerPCs simply didn't provide a usable LE mode.

BTW, I believe NuBus is LE.

>Mark does have such a motherboard, and does have the toolchain.
>So, no need to hassle him about the need for LE or his ability
>to compile stuff correctly.

OK, so there is at least one example of a board designed for PPC LE.  :)

>Changes needed for 75x0 chips on little-endian motherboards:
>
>1. new MSR values
>2. load the whole MSR, not just the lower half
>3. a way to disable the PCI byte swapping that the ppc port does
>4. a "xori" instruction if using the 7450's software TLB reload
>5. removal of crummy load/store string/multiple instructions
>6. write page table entries with a 64-bit write, or word swap

Assuming you've identified all the needed changes for PPC LE with a
LE board (*), I humbly submit that Mark & co. should get to work
making a patch if they really want this feature.  The only item which
might touch very much code is #5 (anybody know how frequently such
instructions are used?), and a strong argument can be made that those
instructions should not be used by anybody given their clearly
deprecated status.  The rest of it is small enough to be maintained
outside the regular trees, so they will not lose big time if it gets
refused for integration.

(*) I'm not convinced there won't be other gotchas.  There are
probably corner cases where unexpected things will happen.  And
drivers might need a cleanup or two.  And there may be processor
models that simply won't work well or at all due to bugs, but people
building LE PPC motherboards can worry about that.

--
Tim Seufert

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ppc LE questions (seeking help hand info pointers)

[Holger Bettag]

"Albert D. Cahalan" <acahalan@cs.uml.edu> writes:

[...]
> Now do an unconditional 64-bit byte swap on the motherboard.
> Consider an array of four __u16 values affected by this.
> They get converted from big-endian to little-endian, and they
> get moved to different addresses. Excellent! All the weirdness
> just cancels out, giving perfect little-endian. This works for
> 8-bit, 16-bit, 32-bit, and 64-bit data. Life is good.
>
Does it work for 128 bit data? The 74x0's most promiment feature,
AltiVec, would expose a strange mixed endianness to programmers
otherwise.

  Holger


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ppc LE questions (seeking help hand info pointers)

[Albert D. Cahalan]

Holger Bettag writes:
>"Albert D. Cahalan" <acahalan@cs.uml.edu> writes:

>> Now do an unconditional 64-bit byte swap on the motherboard.
>> Consider an array of four __u16 values affected by this.
>> They get converted from big-endian to little-endian, and they
>> get moved to different addresses. Excellent! All the weirdness
>> just cancels out, giving perfect little-endian. This works for
>> 8-bit, 16-bit, 32-bit, and 64-bit data. Life is good.
>
> Does it work for 128 bit data? The 74x0's most promiment feature,
> AltiVec, would expose a strange mixed endianness to programmers
> otherwise.

Yes. Motorola noticed this problem, and added a built-in swap
to fix the problem. See page 3-6, section 3.1.4, figure 3-5 in
ALTIVECPEM.pdf, the "AltiVec Technology Programming Environments
Manual". Unaligned vectors don't work in big-endian or little-endian
mode, and the code needed to load them is equally long.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ppc LE questions (seeking help hand info pointers)

[Timothy A. Seufert]

At 4:23 PM +0200 9/22/01, Holger Bettag wrote:
>"Albert D. Cahalan" <acahalan@cs.uml.edu> writes:
>
>[...]
>>  Now do an unconditional 64-bit byte swap on the motherboard.
>>  Consider an array of four __u16 values affected by this.
>>  They get converted from big-endian to little-endian, and they
>>  get moved to different addresses. Excellent! All the weirdness
>>  just cancels out, giving perfect little-endian. This works for
>>  8-bit, 16-bit, 32-bit, and 64-bit data. Life is good.
>>
>Does it work for 128 bit data? The 74x0's most promiment feature,
>AltiVec, would expose a strange mixed endianness to programmers
>otherwise.

For compatability's sake, when AltiVec quad word loads/stores are
performed in LE mode, you get a double munge (one munge for each of
the two doublewords in the quadword) and a swap of the two munged
doublewords.  Details are in the AltiVec PEM.  So AltiVec has true LE
ordering of doublewords and munged up contents inside doublewords,
and an unconditional 64-bit swap on the motherboard will fix the
munging inside each doubleword.
--
Tim Seufert

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ppc LE questions (seeking help hand info pointers)

[Mark Salisbury]

Timothy A. Seufert wrote:

> Assuming you've identified all the needed changes for PPC LE with a
> LE board (*), I humbly submit that Mark & co. should get to work
> making a patch if they really want this feature.  The only item which
> might touch very much code is #5 (anybody know how frequently such
> instructions are used?), and a strong argument can be made that those
> instructions should not be used by anybody given their clearly
> deprecated status.  The rest of it is small enough to be maintained
> outside the regular trees, so they will not lose big time if it gets
> refused for integration.


we'll see how it goes and let you know...


--
/*------------------------------------------------**
**   Mark Salisbury | Mercury Computer Systems    **
**   mbs@mc.com     | System OS - Kernel Team     **
**------------------------------------------------*/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ppc LE questions (seeking help hand info pointers)

[Paul Mackerras]

Mark Salisbury writes:

> question 1.  are there already existing patch sets (rejected from
> mainline inclusion) available for use as a starting point?

Hmmm, I think there was someone who was looking at this, but I don't
recall who it was.

> question 3.  is there a general issue of endian safety in linux (I would
> think not) or just in the ppc-specific code?

Given that Linux runs on both big and little-endian machines, yes the
endian issues have largely been addressed, with the exception of some
drivers.

> question 4. assuming I was willing to deliver a clean, complete LE
> enabling patch (including devices that are relevant to me), as a compile
> time config option and maintain that patch, what would be the primary
> obstacle to inclusion in the main line.

It would depend on how much needed to be changed just for the benefit
of the LE machines, and how much it would complicate future
maintenance of the rest of the code.  If there are suddenly lots of
places where we have to do things differently now because of the
existence of the LE port, then that would make it easy for people to
break things in the future without realizing, and that would be a
reason for rejection.

I am not opposed to LE support but I would be opposed to large-scale
changes to the code for the sake of one platform which isn't widely
used - unless of course you can argue that the changes result in us
doing things the "right" way for all platforms.

It ultimately comes down to "show us the code".

Paul.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/