Binary Compatibility of various flavors of PPC

Binary Compatibility of various flavors of PPC

[Bret Indrelee]

We are trying to wade our way through the various processor choices and
options available for PPC on Linux.

One of our requirements is to be able to run the same binary image across
a range of systems. The image can not change just because the processor
does.

We are currently looking at the 405GPX, 8250, 8245, and PowerQUIC III.

One thing we haven't been able to figure out is if the same PPC Linux
system binary (including OS) can be configured to boot on any of these
processors. It looks like the MMU changes when you go to Book E
architechure (no BAT), but I'm not sure what some of the other differences
might be.


Can someone please tell me if it is possible to have an OS image that
can boot any of the various PPC processors and adapt based on which
processor model it is?

Thanks,

-Bret

--
Bret Indrelee                 QLogic Corporation
Bret.Indrelee@qlogic.com      6321 Bury Driver, St 13, Eden Prairie, MN 55346


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

Re: Binary Compatibility of various flavors of PPC

[Wolfgang Denk]

In message <Pine.LNX.4.33.0210141138290.24959-100000@localhost.localdomain> you wrote:
>
> We are trying to wade our way through the various processor choices and
> options available for PPC on Linux.
>
> One of our requirements is to be able to run the same binary image across
> a range of systems. The image can not change just because the processor
> does.
>
> We are currently looking at the 405GPX, 8250, 8245, and PowerQUIC III.

What do you mean with "image"?

Kernel Image? Application image (for example ramdisk  with  libraries
and application binaries)? Both combined?

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
I have often regretted my speech, never my silence.

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

Re: Binary Compatibility of various flavors of PPC

[Bret Indrelee]

On Mon, 14 Oct 2002, Wolfgang Denk wrote:
> In message <Pine.LNX.4.33.0210141138290.24959-100000@localhost.localdomain> you wrote:
> > We are trying to wade our way through the various processor choices and
> > options available for PPC on Linux.
> >
> > One of our requirements is to be able to run the same binary image across
> > a range of systems. The image can not change just because the processor
> > does.
> >
> > We are currently looking at the 405GPX, 8250, 8245, and PowerQUIC III.
>
> What do you mean with "image"?
>
> Kernel Image? Application image (for example ramdisk  with  libraries
> and application binaries)? Both combined?

Both combined. A bzImage and RAM disk loaded off the boot media (Flash).

-Bret

--
Bret Indrelee                 QLogic Corporation
Bret.Indrelee@qlogic.com      6321 Bury Driver, St 13, Eden Prairie, MN 55346


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

Re: Binary Compatibility of various flavors of PPC

[Wolfgang Denk]

In message <Pine.LNX.4.33.0210141315200.24959-100000@localhost.localdomain> you wrote:
>
> > > One of our requirements is to be able to run the same binary image across
> > > a range of systems. The image can not change just because the processor
> > > does.
> > >
> > > We are currently looking at the 405GPX, 8250, 8245, and PowerQUIC III.
> >
> > What do you mean with "image"?
> >
> > Kernel Image? Application image (for example ramdisk  with  libraries
> > and application binaries)? Both combined?
>
> Both combined. A bzImage and RAM disk loaded off the boot media (Flash).

That makes for an easy answer: no go.

4xx and 82xx are different enough the required efford  to  just  make
one  kernel  image  run on all these CPU makes no sense; neither from
the technical nor from the economical point of  view.  And  user-land
stuff (libraries, applications) is yet another story.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"More software projects have gone awry for lack of calendar time than
for all other causes combined."
- Fred Brooks, Jr., _The Mythical Man Month_

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

Re: Binary Compatibility of various flavors of PPC

[Mark Hatle]

Bret Indrelee wrote:
> We are trying to wade our way through the various processor choices and
> options available for PPC on Linux.
>
> One of our requirements is to be able to run the same binary image across
> a range of systems. The image can not change just because the processor
> does.
>
> We are currently looking at the 405GPX, 8250, 8245, and PowerQUIC III.

(I am ONLY speaking of userspace! .. each system will require a custom kernel)

The 7xx (as well as 74xx if you avoid altivec) and 82xx are all compatable in
userspace.  Those CPU families floating point units, the same cache line size
and other commonalities.

The 405 does not have an FPU.. If you enable the in kernel floating point
emulator it will then be capable of running the same binaries as above.. but do
to performance, personal preferance and other reasons I do not recommend running
a non FPU machine with FPU emulation unless you need to.

(Since we're on the topic) the PowerPC 403, and 8xx lines are binary compatable
with each other.  Similar to the 405 they lack an FPU, but they also use only
half the cacheline size of the above CPUs.  This (potentially) makes the libc
incompatable, and many optimizations may not work as intended.

There is still a question on wether or not the Book E stuff will be user space
compatable with the current 7xx style binaries.  I wouldn't hold my breath.. :P

If I was building a range of systems that required varying PowerPC CPUs with a
common userspace I would stick to the 82xx/7xx/74xx families today.

--Mark


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

Re: Binary Compatibility of various flavors of PPC

[Matt Porter]

On Mon, Oct 14, 2002 at 12:13:52PM -0500, Mark Hatle wrote:
>
> Bret Indrelee wrote:
> > We are trying to wade our way through the various processor choices and
> > options available for PPC on Linux.
> >
> > One of our requirements is to be able to run the same binary image across
> > a range of systems. The image can not change just because the processor
> > does.
> >
> > We are currently looking at the 405GPX, 8250, 8245, and PowerQUIC III.
>
> (I am ONLY speaking of userspace! .. each system will require a custom kernel)
>
> The 7xx (as well as 74xx if you avoid altivec) and 82xx are all compatable in
> userspace.  Those CPU families floating point units, the same cache line size
> and other commonalities.
>
> The 405 does not have an FPU.. If you enable the in kernel floating point
> emulator it will then be capable of running the same binaries as above.. but do
> to performance, personal preferance and other reasons I do not recommend running
> a non FPU machine with FPU emulation unless you need to.

Working 40x libraries have some errata fixups in them IIRC, so running
a complete classic PPC binary chain would have the possibility of
exhibiting problems.

> (Since we're on the topic) the PowerPC 403, and 8xx lines are binary compatable
> with each other.  Similar to the 405 they lack an FPU, but they also use only
> half the cacheline size of the above CPUs.  This (potentially) makes the libc
> incompatable, and many optimizations may not work as intended.
>
> There is still a question on wether or not the Book E stuff will be user space
> compatable with the current 7xx style binaries.  I wouldn't hold my breath.. :P

Oh good, another chance to point out that Book E isn't a unifying standard.
The current IBM Book E implementation (PPC440) is binary compatible
with PPC405.  Since 40x was a bastard hybrid of classic and Book E
PPC, the 440 looks like a superset as far as userspace instructions.
The Mot Book E implementation (e500) could be binary compatible
with classic PPCs (perhaps Kumar will speak up on the direction here)
except that it doesn't handle FP in a green book manner...well it's
a more versatile SIMD implementation anyway.   One public mention of
some pertinent e500 characteristics is here:
http://gcc.gnu.org/ml/gcc/2002-07/msg01060.html

In theory, one could use kernel FP emulation on e500 when not using
SIMD instructions and run classic PPC binaries.  In practice, this may
not be wise.

> If I was building a range of systems that required varying PowerPC CPUs with a
> common userspace I would stick to the 82xx/7xx/74xx families today.

I'd have to agree with that.  Classic PPC core implementations currently
offer the broadest selection of userspace binary compatible processors.

Regards,
--
Matt Porter
porter@cox.net
This is Linux Country. On a quiet night, you can hear Windows reboot.

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

Re: Binary Compatibility of various flavors of PPC

[Kumar Gala]

On Monday, October 14, 2002, at 01:15  PM, Matt Porter wrote:

>
> On Mon, Oct 14, 2002 at 12:13:52PM -0500, Mark Hatle wrote:
>>
>> Bret Indrelee wrote:
>>> We are trying to wade our way through the various processor choices
>>> and
>>> options available for PPC on Linux.
>>>
>>> One of our requirements is to be able to run the same binary image
>>> across
>>> a range of systems. The image can not change just because the
>>> processor
>>> does.
>>>
>>> We are currently looking at the 405GPX, 8250, 8245, and PowerQUIC
>>> III.
>>
>> (I am ONLY speaking of userspace! .. each system will require a
>> custom kernel)
>>
>> The 7xx (as well as 74xx if you avoid altivec) and 82xx are all
>> compatable in
>> userspace.  Those CPU families floating point units, the same cache
>> line size
>> and other commonalities.
>>
>> The 405 does not have an FPU.. If you enable the in kernel floating
>> point
>> emulator it will then be capable of running the same binaries as
>> above.. but do
>> to performance, personal preferance and other reasons I do not
>> recommend running
>> a non FPU machine with FPU emulation unless you need to.
>
> Working 40x libraries have some errata fixups in them IIRC, so running
> a complete classic PPC binary chain would have the possibility of
> exhibiting problems.
>
>> (Since we're on the topic) the PowerPC 403, and 8xx lines are binary
>> compatable
>> with each other.  Similar to the 405 they lack an FPU, but they also
>> use only
>> half the cacheline size of the above CPUs.  This (potentially) makes
>> the libc
>> incompatable, and many optimizations may not work as intended.
>>
>> There is still a question on wether or not the Book E stuff will be
>> user space
>> compatable with the current 7xx style binaries.  I wouldn't hold my
>> breath.. :P
>
> Oh good, another chance to point out that Book E isn't a unifying
> standard.
> The current IBM Book E implementation (PPC440) is binary compatible
> with PPC405.  Since 40x was a bastard hybrid of classic and Book E
> PPC, the 440 looks like a superset as far as userspace instructions.
> The Mot Book E implementation (e500) could be binary compatible
> with classic PPCs (perhaps Kumar will speak up on the direction here)
> except that it doesn't handle FP in a green book manner...well it's
> a more versatile SIMD implementation anyway.   One public mention of
> some pertinent e500 characteristics is here:
> http://gcc.gnu.org/ml/gcc/2002-07/msg01060.html
>
> In theory, one could use kernel FP emulation on e500 when not using
> SIMD instructions and run classic PPC binaries.  In practice, this may
> not be wise.

If one wants to run 82xx/7xx/74xx binaries on an e500 just like on
4xx/8xx, then kernel FP emulation is the way to go.

The e500 does provide the ability to handle simplified single precision
floating point instructions in the GPRs.  These instructions use
distinct opcodes from the classic FP instructions.

>> If I was building a range of systems that required varying PowerPC
>> CPUs with a
>> common userspace I would stick to the 82xx/7xx/74xx families today.
>
> I'd have to agree with that.  Classic PPC core implementations
> currently
> offer the broadest selection of userspace binary compatible processors.

I agree, but it depends on how important floating point is to ones
userspace.  If they do not care about FP then all of the PPC processors
4xx/8xx/82xx/7xx/74xx/e500 all provide a compatible integer instruction
set.

- kumar


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

Re: Binary Compatibility of various flavors of PPC

[Mark Hatle]

>> I'd have to agree with that.  Classic PPC core implementations currently
>> offer the broadest selection of userspace binary compatible processors.
>
>
> I agree, but it depends on how important floating point is to ones
> userspace.  If they do not care about FP then all of the PPC processors
> 4xx/8xx/82xx/7xx/74xx/e500 all provide a compatible integer instruction
> set.

But as Matt said (and later reminded me) the 405 has errata that is 405
specific, and the 8xx and 403 half smaller cacheline size.  So anything
statically linked may not operator correctly....  but yes, if you switch the
whole of userspace to soft-floating point then "in general" they should all be
compatable.

IMHO it is a bad practice to mix and match userspace between 403/8xx, 405, and
7xx/74xx/82xx series of processors.  It is just asking for problems..  but it
definatly can be done given proper resources and understanding of the underlying
problems.

--Mark

> - kumar


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

Re: Binary Compatibility of various flavors of PPC

[Wolfgang Denk]

In message <3DAB2923.3060607@mvista.com> Mark Hatle wrote:
>
> IMHO it is a bad practice to mix and match userspace between 403/8xx, 405, and
> 7xx/74xx/82xx series of processors.  It is just asking for problems..  but it
> definatly can be done given proper resources and understanding of the underlying
> problems.

A lot of things _can_ be done. But do all these things make sense
(technically and commercially)?

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
You can do this in a number of ways.     IBM chose to do all of them.
Why do you find that funny?        -- D. Taylor, Computer Science 350

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

Re: Binary Compatibility of various flavors of PPC

[Mark Hatle]

Wolfgang Denk wrote:
> In message <3DAB2923.3060607@mvista.com> Mark Hatle wrote:
>
>>IMHO it is a bad practice to mix and match userspace between 403/8xx, 405, and
>>7xx/74xx/82xx series of processors.  It is just asking for problems..  but it
>>definatly can be done given proper resources and understanding of the underlying
>>problems.
>
>
> A lot of things _can_ be done. But do all these things make sense
> (technically and commercially)?

Hehe if ya want to pay me a million dollars (or more) I'll be happy to make it
work.. ;)  But I still won't recommend it to anyone.  The answer to this is
understand what you are getting yourself into and understand that you are
probably costing yourself much more over the short and long term to use a
"common" set of binaries then to use binaries tailored for the specific CPU that
you are using.

--Mark


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

Re: Binary Compatibility of various flavors of PPC

[Magnus Damm]

> But as Matt said (and later reminded me) the 405 has errata that is 405
> specific, and the 8xx and 403 half smaller cacheline size.  So anything
> statically linked may not operator correctly....  but yes, if you switch the
> whole of userspace to soft-floating point then "in general" they should all be
> compatable.

I don't know if gcc generates any code that tweaks with the cache, but
if you
only consider applications/libraries that use assembly routines to
control the
cache then it should be possible to convert the assembly code to assume
16-byte
cachelines for all processors. That should work for processors with
larger
cachelines, with a performance penalty. I use a patch for glibc-2.1.3
that does
exactly that. But I've only used it on 8xx-series, so correct me if I'm
wrong.

Btw - does someone know what the status is for recent glibc versions -
do they work for 8xx out of the box?

Thanks /

magnus

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

Re: Binary Compatibility of various flavors of PPC

[Bret Indrelee]

On Mon, 13 Oct 2002, Kumar Gala wrote:
> On Monday, October 14, 2002, at 01:15  PM, Matt Porter wrote:
> > On Mon, Oct 14, 2002 at 12:13:52PM -0500, Mark Hatle wrote:
> >> Bret Indrelee wrote:
[ Looking to have compatible System and User binary image ]
> >>> We are currently looking at the 405GPX, 8250, 8245, and PowerQUIC
> >>> III.
[ snip ]
> >> If I was building a range of systems that required varying PowerPC
> >> CPUs with a
> >> common userspace I would stick to the 82xx/7xx/74xx families today.
> >
> > I'd have to agree with that.  Classic PPC core implementations
> > currently
> > offer the broadest selection of userspace binary compatible processors.
>
> I agree, but it depends on how important floating point is to ones
> userspace.  If they do not care about FP then all of the PPC processors
> 4xx/8xx/82xx/7xx/74xx/e500 all provide a compatible integer instruction
> set.

Float isn't important to us, we could have all float be emulated for as
little of it we do.

We need the bzImage.gz and RAM disk image have to be the same binary.

The reason is simple, we don't want the customer to have the mess of
'which of these N firmware images do I need' when trying to upgrade. We
want the whole line of products to use the same binary image.

We want a process that uses lower power and board space processor than
the Intel but still allows us to use the same binary across the line of
products. Our best guess of the performance levels needed are going to
be from about a 300MHz CPU to 800MHz or 1GHz. Having even higher
performance options in the future would be a definate plus.

-Bret

--
Bret Indrelee                 QLogic Corporation
Bret.Indrelee@qlogic.com      6321 Bury Driver, St 13, Eden Prairie, MN 55346


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

Re: Binary Compatibility of various flavors of PPC

[Andrew May]

On Mon, Oct 14, 2002 at 04:37:49PM -0500, Bret Indrelee wrote:
>
> Float isn't important to us, we could have all float be emulated for as
> little of it we do.
>
> We need the bzImage.gz and RAM disk image have to be the same binary.
>
> The reason is simple, we don't want the customer to have the mess of
> 'which of these N firmware images do I need' when trying to upgrade. We
> want the whole line of products to use the same binary image.

Looks like you are looking at the problem wrong. Send the custumors a big
binary file with all the images and have the update program be smart about
selecting the correct images for the hardware out of the big binary.

It is more work to build the images but less work than getting one image
to work on different CPU's. You could even support x86 parts with a smart
updater.

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

Re: Binary Compatibility of various flavors of PPC

[Jerry Van Baren]

You have unreasonable expectations.  The PowerPC architecture does not
aspire to maintain total code compatibility at all levels.  It specifically
disclaims any aspirations of achieving full code compatibility.

Reference: "PowerPC Microprocessor Family: The Programming Environments"
Section 1.1.2 "The Levels of the PowerPC Architecture":

"All PowerPC devices adhere to the UISA [User Instruction Set Architecture
gvb], ensuring binary compatibility among all PowerPC application
programs.  However, there may be different versions of the VEA [Virtual
Environment Architecture gvb] and the OEA [Operating Environment
Architecture gvb] than those described here.  For example, some devices,
such as embedded controllers, may not require some of the features as
defined by this VEA and OEA, may implement a simpler or modified version of
those features."

Bottom line: if you wish to have one executable for 4xx, 8xx, 603e-core,
7xx, 74xx, etc. binaries, you will be working REALLY REALLY hard to achieve
something IBM and Motorola never intended to supply.

You best gamble (and it would be a gamble) would be to make a single image
that contained several OS executables and have your power up code detect
the processor type, load the applicable OS image into RAM and run out of
RAM.  Your application code should work unmodified, assuming you hid all
the architecture idiosyncrasies as IBM/Mot intended (such as emulating FP
on the FP-less CPUs).  Note that the application portability trick is
theoretically possible but, as several others have pointed out already, is
non-trivial.

gvb


At 04:37 PM 10/14/2002 -0400, Bret.Indrelee@qlogic.com wrote:

>On Mon, 13 Oct 2002, Kumar Gala wrote:
> > On Monday, October 14, 2002, at 01:15  PM, Matt Porter wrote:
> > > On Mon, Oct 14, 2002 at 12:13:52PM -0500, Mark Hatle wrote:
> > >> Bret Indrelee wrote:
>[ Looking to have compatible System and User binary image ]
> > >>> We are currently looking at the 405GPX, 8250, 8245, and PowerQUIC
> > >>> III.
>[ snip ]
> > >> If I was building a range of systems that required varying PowerPC
> > >> CPUs with a
> > >> common userspace I would stick to the 82xx/7xx/74xx families today.
> > >
> > > I'd have to agree with that.  Classic PPC core implementations
> > > currently
> > > offer the broadest selection of userspace binary compatible processors.
> >
> > I agree, but it depends on how important floating point is to ones
> > userspace.  If they do not care about FP then all of the PPC processors
> > 4xx/8xx/82xx/7xx/74xx/e500 all provide a compatible integer instruction
> > set.
>
>Float isn't important to us, we could have all float be emulated for as
>little of it we do.
>
>We need the bzImage.gz and RAM disk image have to be the same binary.
>
>The reason is simple, we don't want the customer to have the mess of
>'which of these N firmware images do I need' when trying to upgrade. We
>want the whole line of products to use the same binary image.
>
>We want a process that uses lower power and board space processor than
>the Intel but still allows us to use the same binary across the line of
>products. Our best guess of the performance levels needed are going to
>be from about a 300MHz CPU to 800MHz or 1GHz. Having even higher
>performance options in the future would be a definate plus.
>
>-Bret
>
>--
>Bret Indrelee                 QLogic Corporation
>Bret.Indrelee@qlogic.com      6321 Bury Driver, St 13, Eden Prairie, MN 55346
>
>


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