From: Matt Porter <hidden> Date: 2002-10-14 18:15:47
On Mon, Oct 14, 2002 at 12:13:52PM -0500, Mark Hatle wrote:
Bret Indrelee wrote:
quoted
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/
From: Kumar Gala <hidden> Date: 2002-10-14 19:59:53
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:
quoted
Bret Indrelee wrote:
quoted
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.
quoted
(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.
quoted
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/
From: Mark Hatle <hidden> Date: 2002-10-14 20:29:23
quoted
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
From: Magnus Damm <hidden> Date: 2002-10-14 22:14:50
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/
On Monday, October 14, 2002, at 01:15 PM, Matt Porter wrote:
quoted
On Mon, Oct 14, 2002 at 12:13:52PM -0500, Mark Hatle wrote:
quoted
Bret Indrelee wrote:
[ Looking to have compatible System and User binary image ]
quoted
quoted
quoted
We are currently looking at the 405GPX, 8250, 8245, and PowerQUIC
III.
[ snip ]
quoted
quoted
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/
From: Andrew May <hidden> Date: 2002-10-14 22:26:11
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/