Bug#575158: dpkg: Add new 'e500' architecture to triplettable and ostable
* Guillem Jover | 2010-04-30 06:10:05 [+0200]: Hi! Hi Guillem, On Thu, 2010-04-29 at 21:09:20 -0500, Moffett, Kyle D wrote: I believe we have consensus on the port architecture name of powerpcspe. Is there any chance we can get the attached patch merged soon? I'd like to move forward with getting an unofficial debian-ports.org repository created and they won't do that until a patch has been merged to upstream dpkg GIT. It didn't seem clear to me the double issue had consensus, if it does, and both of you agree (Sebastian a Signed-off-by from you in this case would be nice), then yes, I'll gladly add the new architecture. Yes, double precision is what we want, so here you go: Signed-off-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc From: Kyle Moffett kyle.d.moff...@boeing.com Date: Thu, 29 Apr 2010 21:47:25 -0400 Subject: [PATCH] powerpcspe: New unofficial Debian port The Debian port to this architecture specifically chooses to optimize for the higher-end chips (e500v2), as most of the others are targeted at automotive applications or no longer in production. Do both of you agree on this too? Yes, e500v2 is the way to go. MPC8540 (e500v1) is still in production. The designs on the hand are not that attractive these days. The reference manual was released 9/8/2004 and the flash or system memory back then was not that huge like we have it today. They have also no storage controler in-core. Also you don't want a HD in your automotive product. And if you don't need the PCI bus, you are going to remove it. So it is unlike they will run *full* Debian (now). Most likely they will cross compile the few application they need. Today one will pick a newer CPU. The specific GNU triplet for this arch is powerpc-linux-gnuspe. Like the ARM EABI port (arm-linux-gnueabi) the naming seems unfortunate here; an architecture triplet such as powerpcspe-linux-gnu would have been far more appropriate. As a result, we end up adding an extra ostable entry instead of one in cputable. This is just nitpicking, but in this case I think the GNU triplet is appropriate for those two ports, as the matter of conflict is mostly ABI dependent. thanks, guillem Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575158: dpkg: Add new 'e500' architecture to triplettable and ostable
Raphael, I believe we have consensus on the port architecture name of powerpcspe. Is there any chance we can get the attached patch merged soon? I'd like to move forward with getting an unofficial debian-ports.org repository created and they won't do that until a patch has been merged to upstream dpkg GIT. The patch is also included inline below for easy review (although given the email client I have to use that version is probably whitespace-damaged). Cheers, Kyle Moffett -- Kyle Moffett eXMeritus Software Integrated Intelligence The Boeing Company (703) 764-0925 kyle.d.moff...@boeing.com WHITESPACE-DAMAGED PATCH BELOW, SEE ATTACHMENT FOR CORRECT COPY From: Kyle Moffett kyle.d.moff...@boeing.com Date: Thu, 29 Apr 2010 21:47:25 -0400 Subject: [PATCH] powerpcspe: New unofficial Debian port The 'powerpcspe' architecture is a binary-incompatible variant of PowerPC/POWER designed and supported by FreeScale and IBM. It is also known under the trade names e500/MPC8500 and e200/MPC5xx. Additional information can be found at: http://en.wikipedia.org/wiki/PowerPC_e500 http://en.wikipedia.org/wiki/PowerPC_e200 In particular, the 'powerpcspe' architecture lacks the classic FPU with dedicated FPRs found on most other PowerPC systems. It is replaced with a set of SPE instructions which perform floating-point operations on the integer registers. In an unfortunate choice of architecture design, the instructions used for the SPE operations overlap with those for the AltiVec unit on most other modern PowerPC cores. The e500v2-series chips have 64-bit GPRs, where the high 32-bits are accessible only via the special SPE instructions, allowing them to make efficient use of the double datatype. The relative rare e500v1-series chips have only 32-bit GPRs, and require software traps and emulation to support native double. The e200z3 and e200z6 chips have no support for floating point at all, but with software traps and emulation are binary-compatible with the e500-series chips. The Debian port to this architecture specifically chooses to optimize for the higher-end chips (e500v2), as most of the others are targeted at automotive applications or no longer in production. The specific GNU triplet for this arch is powerpc-linux-gnuspe. Like the ARM EABI port (arm-linux-gnueabi) the naming seems unfortunate here; an architecture triplet such as powerpcspe-linux-gnu would have been far more appropriate. As a result, we end up adding an extra ostable entry instead of one in cputable. At this time the 'powerpcspe' architecture port is still very much an unofficial port. While we hope that will change in the future, it is entirely possible that the embedded niche of the processor will make such an official Debian port problematic. Signed-off-by: Kyle Moffett kyle.d.moff...@boeing.com --- ostable |1 + triplettable |1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/ostable b/ostable index 2ef2cdd..17b7581 100644 --- a/ostable +++ b/ostable @@ -17,6 +17,7 @@ uclibceabi-linuxlinux-uclibceabilinux[^-]*-uclibceabi uclibc-linuxlinux-uclibclinux[^-]*-uclibc gnueabi-linux linux-gnueabi linux[^-]*-gnueabi +gnuspe-linuxlinux-gnuspelinux[^-]*-gnuspe gnulp-linux linux-gnulp linux[^-]*-gnulp gnu-linux linux-gnu linux[^-]*(-gnu.*)? gnu-kfreebsdkfreebsd-gnukfreebsd[^-]*(-gnu.*)? diff --git a/triplettable b/triplettable index 1a2c666..5b297c8 100644 --- a/triplettable +++ b/triplettable @@ -5,6 +5,7 @@ # Debian triplet Debian arch uclibceabi-linux-armuclibc-linux-armel uclibc-linux-cpu uclibc-linux-cpu +gnuspe-linux-powerpcpowerpcspe gnueabi-linux-arm armel gnulp-linux-i386lpia gnu-linux-cpu cpu -- 1.7.0 0001-powerpcspe-New-unofficial-Debian-port.patch Description: 0001-powerpcspe-New-unofficial-Debian-port.patch
Bug#575158: dpkg: Add new 'e500' architecture to triplettable and ostable
Hi! On Thu, 2010-04-29 at 21:09:20 -0500, Moffett, Kyle D wrote: I believe we have consensus on the port architecture name of powerpcspe. Is there any chance we can get the attached patch merged soon? I'd like to move forward with getting an unofficial debian-ports.org repository created and they won't do that until a patch has been merged to upstream dpkg GIT. It didn't seem clear to me the double issue had consensus, if it does, and both of you agree (Sebastian a Signed-off-by from you in this case would be nice), then yes, I'll gladly add the new architecture. From: Kyle Moffett kyle.d.moff...@boeing.com Date: Thu, 29 Apr 2010 21:47:25 -0400 Subject: [PATCH] powerpcspe: New unofficial Debian port The Debian port to this architecture specifically chooses to optimize for the higher-end chips (e500v2), as most of the others are targeted at automotive applications or no longer in production. Do both of you agree on this too? The specific GNU triplet for this arch is powerpc-linux-gnuspe. Like the ARM EABI port (arm-linux-gnueabi) the naming seems unfortunate here; an architecture triplet such as powerpcspe-linux-gnu would have been far more appropriate. As a result, we end up adding an extra ostable entry instead of one in cputable. This is just nitpicking, but in this case I think the GNU triplet is appropriate for those two ports, as the matter of conflict is mostly ABI dependent. thanks, guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575158: dpkg: Add new 'e500' architecture to triplettable and ostable
* Moffett, Kyle D | 2010-04-22 19:17:17 [-0500]: Not really... If you build GCC with --enable-e500_double it produces code that is not quite binary compatible with code generated without that option, because it indicates that the GPRs have an extra shadow 32 high bits that can be only accessed by certain FPU operations. I believe it affects function stack layout and calling conventions (one GPR versus two). The stack on powerpc has an alignment of 16 bytes due to AltiVec. The double type arguments are passed in two 32bit grp registers. The kernel can emulate those Opcodes if there are not availble. I know some one run my port on a G5 for testing. So yes we can mix it and no I don't want it because it will be slow. As far as compile hardware goes... If I can get one buildd set up locally then I have 6 NFS-booting e500v2 boards to throw at the problem; each with a dual-core P2020 chip @ 1GHz, 2GB 533MHz registered ECC RAM, and an Intel 160GB gen-2 SSD. Okay. So I will redirect all OpenOffice builds to your machines :) Kyle Moffett Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575158: dpkg: Add new 'e500' architecture to triplettable and ostable
On 2010/04/18 08:39, Sebastian Andrzej Siewior sebast...@breakpoint.cc
wrote:
* Guillem Jover | 2010-04-16 09:01:16 [+0200]:
Do you see this as a possible workable solution, or is it completely
unnacceptable? Did I miss something besides what I listed here?
I don't think it is acceptable due to the points I've added.
I agree... this looks like an unacceptable performance penalty both for
e500v2 and for generic powerpc systems.
Anyway if case the previous is nuts/suboptimal/unworkable/etc, here's
the comments on the architecture name:
On Thu, 2010-04-08 at 18:39:09 -0500, Moffett, Kyle D wrote:
* The only chipset families that support SPE instructions are:
* PowerPC e200
e200z3 and e200z6 according to [3].
* PowerPC e500v1
* PowerPC e500v2
* The incompatibility between various SPE-capable CPUs mean that an arch
spec of spe or powerpcspe is probably insufficiently descriptive.
Yes, probably. Right now we don't see any.
* The e200 processor series is an automotive processor and has
insufficient storage to run even something like Emdebian Crush, let alone
to
be able to build anything on its own. It should therefore be excluded
from
our discussion. This means we just care about e500v{1,2} cores.
Well, someone could get e200 licensed and build something generic
enough to run Debian on it at some point, no?
Yes this is possible but I don't think so. However point: I looked at
the PowerISA and the opcodes are described in the SPE section. The Cell
SPE is not mentioned there. So one could license the SPE part and
attach it to a 440 based core which has an APU interface. Or build his
own core with this capability like Lemote did with MIPS.
I suppose that's a possibility... although I'd call any company that does
such a thing certifiably insane. PowerPC had such a nice compatible
instruction set until e500 came along...
Right. The spec says, that e200z4 and e200z6 are binary compatible with
e500. However, they also mention that double precision can only be
achieved in software. So this looks like double precision opcodes result
in an invalid opcode and we have to emulate them in kernel. This counts
as binary compatible I guess.
Exactly, compatibility here is a tricky word, for Debian architectures
it tends to imply mostly compatible ABI (regarding instruction set,
binary object format, calling conventions, kernel interface, etc).
Well what the GNU triplet implies, actually.
Regarding the CPU, as long as later CPUs are mostly backward
compatible, and the kernel can abstract other differences from
the system it should be fine, and using the same architecture is
preferable in general.
Okay.
* We should just call it just e500v2:
* Sufficiently descriptive of the hardware architecture
I don't really see why the other ones should be left out, using a
specific implementation to describe all the possibly supported
implementations the architecture can handle seems wrong to me. In this
case the describing attribute is the usage of SPE, which is what makes
it incompatible from the standard powerpc port, and it's what's
already on the GNU triplet, which would change accordingly in case an
incompatible change to it would happen.
True.
Not really... If you build GCC with --enable-e500_double it produces code
that is not quite binary compatible with code generated without that option,
because it indicates that the GPRs have an extra shadow 32 high bits that
can be only accessed by certain FPU operations. I believe it affects
function stack layout and calling conventions (one GPR versus two).
So if this is considered the way to go, I think using spe in the name
would be better, which makes it generic, and kind of more future-proof
than e500, and for the long name argument, using ppc should be fine, in
the same way we have already ppc64. But then if you'd prefer powerpc
that be fine with me too.
So we back with powerpcspe which is fine with me. I was only afraid of
mixing it up with the CELL's SPE. Now that Sony discontinued OtherOs for
PS3 it should no longer be a problem :)
Well, IBM still makes Power6 blade servers with Cell cores on them for
high-end simulation and other tasks (I think they're also marketed as add-on
compute nodes for companies running MMORPG servers on their mainframes). On
the other hand, the Debian packages for those say gcc-spu (versus spe).
Anyway, to be clear, I'm not trying to be imposing, you are the porters
afterall, and the ones who will have to do the heavy lifting, just trying
to get the facts right, as deciding on an architecture name, more so when
it does not seem obvious, should be considered carefully, as having to
change the name later on it's only going to be painful, more so if
deployed systems have to be switched.
Yes. That's why I am here :)
So we agree on powerpcspe and the port will contain the complete SPE
extension including double precision support. If one needs a
Bug#575158: dpkg: Add new 'e500' architecture to triplettable and ostable
* Guillem Jover | 2010-04-16 09:01:16 [+0200]: Hi! Hi Guillem, On Thu, 2010-02-18 at 11:38:34 +0100, Sebastian Andrzej Siewior wrote: - variant two: a operation like a + b where we call in a library to compute the floating point operation. Here we would put the computation itself into a library like glibc/gcc which would use classic or embedded floating point depending on hwcap. Again the problem how do pass the arguments. Plus we don't utilize all registes and have function calls for every simple operation. Not only that we have a new ABI here we also make it slow for every one. For this variant, it seems to me, the only sane way would be to use soft float ABI, by default make gcc use -mfloat-abi=soft, then build specialized hwcap versions of libgcc, libm, libc, and similar for classic and embedded fp with -mfloat-abi=softfp. So you'd get a different ABI than the current powerpc port, but at the same time this new port could be used everywhere. This has been done on armel. I took a look on the GCC manual and I cam find this options only in the ARM section and my compiler gives me an unknown command error. Lets assume for one moment that it also is supported on powerpc. The downsides would be AFAICS: * Slight overhead (how much?) due to function calls for fp operations, and move of values from fpr to gpr on classic fp. Lets get some numbers on this: I grabbed nbench-byte 2.2.3 from [0] and compiled it differently on a e500v2 based box: - normal = this is e500v1 compatible code. So an add of two double variables ends up in calling __adddf3() which performs the operation without using any e500v2 opcodes. - e500v2 func = like normal but __adddf3() for instance is using e500v2 opcodes. I just made a function with that name which overrides the pure soft one. sin(), pow() and friends from libm are untouched so all double floating point operations there are inlined. - e500v2 = here we inline all double operations. The complete results are at [1] and the tiny override I used for e500v2 func is at [2]. Here I removed the integer only tests and you see the average of all runs from the Iterations/sec. column: TEST | e500v2 | e500v2 funcs | normal -|-|--|- FOURIER | 5220.30 | 4800.43 | 4017.13 NEURAL NET |8.76 | 1.61 |0.69 LU DECOMPOSITION | 287.10 |50.54 | 19.21 FLOATING-POINT INDEX | 10.75 | 3.33 |1.71 If we take FLOATING-POINT INDEX for comparing and take e500v2 as base then e500v2 funcs perform at ~31% of the original and normal at ~16%. Based on this numbers floating point intensive numbers application will perform bad. Unfortunately I don't have a classic powerpc around and coming with a new compiler for a test like this would eat at least a day. I expect it be worse than e500v2 = e500v2 funcs because all 32 FPRs remain totally unused in the program. Keeping floating point numbers in GPRS leaves less room for others things like pointers forcing them onto stack. The powerpc soft float ABI defines for the type double to use two GPRs. In hard float this type fits in one FPR so this makes the situation kinda worse because if the compiler wants to save variable in a register during a function call it needs two registers. * On generic code (one not built specifically for e500), half of the gpr would not get used. Generic code with this ABI on a G3 for instance uses all GPRs but _no_ FPRs. The Power arch defines 32 GPRs registers and 32 FPRs. The upsides would be: * Code should be ABI comptatible. So one could actually rebuild the arch for e500 only, if desired, and it would still be ABI compatible. In the same way one can rebuild the i386 port for a Celeron, and it should be ABI compatible, even if it will not work on older systems. This is kinda true. If you use this on a embedded machine with no hard disk it is unlikely you recompile it. If your CPU is slow or your resources are limited you probably don't do it. + you have to trace stable changes yourself. * If the performance is not too bad, it could even be considered to replace the current powerpc architecture? (obviously after discussion with the porters, etc) I don't think that this will happen as I already pointed out possible performance loss. Additionally: * binary only code will no longer work with this new ABI. If the vendor does not recompile its program it will no longer work on Debian and people which rely on this particular piece of software have to change the distribution. * assembly optimized code which takes floating point arguments has to be adjusted. (Not that big argument but worth to mention). * Native implementations of fp code would be used for either, and no emulation by the kernel would be needed, not even on FPU-less PowerPCs. Yes that is true. However I don't think a new port for FPU-less machines is a big thing:
Bug#575158: dpkg: Add new 'e500' architecture to triplettable and ostable
Hi!
[ Sorry for the delay, been moving house. ]
First I wanted to comment on some things said on the bug reports and
debian-devel.
Yes, lpia was a mistake, I'd have preferred that the Ubuntu people would
have created a new repository with a rebuilt i386 architecture tailored
for Atom processors, but it was problematic with their infrastructure,
anyway that port is history now. Also regarding the names, i386 is
another mistake IMO, and it should have been something like ia32, x86 or
similar (Debian doesn't even support true 386 anymore). But amd64 seems
perfectly fine to me as it represents the architecture AMD designed, and
even if Intel then cloned it and named it differently it's still amd64.
Regarding rebuilds due to architecture name changes as long as the
binaries to rebuild are ABI compatible one can always reuse the previous
system and binaries and apply some --force-architecture on installation
while packages are being replaced with the ones with the new
architecture.
On Thu, 2010-02-18 at 11:38:34 +0100, Sebastian Andrzej Siewior wrote:
* Guillem Jover | 2010-02-17 21:51:37 [+0100]:
Also from reading some mails from the libc-alpha [0] list when the port
was upstreamed, it seems that it might be possible to mix code built
for powerpc SPE and for other powerpc features? So is it really necessary
to build a whole port for this, isn't it possible to build specific
libraries using the hwcap infrastructure instead, or do the objects
built actually have a different ELF ABI and the objects would refuse
to be linked together (like in the ARM case before the EABI)?
I haven't thought about this but let me go through it:
- variant one: a library function like:
float func(float a)
{
return a + 10
}
So you go and compile this function twice: powerpc where classic
floating point is used another one where embedded floating point is
used. So we have every library twice and it will probably double the
build time on buildds. Now, what about the user of this library? Classic
FPU would pass the variable a in register f1 (floating point register
one, as I mentioned before they have dedicated floating point
registers). Embedded floating point will pass a in r3 (general purpose
register three as we don't have dedicated registers we use softfloat
ABI here). So the user of the application itself would have to be
compiled twice as well.
Well, this implies two ABIs, so it gets back to using a different
architecture name.
Another idea that just come to my mind is to use floating point as we
do now in powerpc. This will require floating point emulation in kernel
for e500 cpus and this is slow [0]. Then identify the hotpaths (i.e.
libraries which rely heavy on floating point) and compile those a second
time with SPE. The problem here is that you can't mix hard and softfloat
due to the way arguments are passed. So you would need wrappers for
them. So this looks like a total pain in the ass. Not that you have to
hunt libraries which you want optimize you have also come up with
wrappers around them. Maybe there is even something I forgot :)
And this one implies a pretty severe performance degradation, and lots
of manual work.
- variant two: a operation like a + b where we call in a library to
compute the floating point operation. Here we would put the
computation itself into a library like glibc/gcc which would use
classic or embedded floating point depending on hwcap. Again the problem
how do pass the arguments. Plus we don't utilize all registes and have
function calls for every simple operation. Not only that we have a
new ABI here we also make it slow for every one.
For this variant, it seems to me, the only sane way would be to use soft
float ABI, by default make gcc use -mfloat-abi=soft, then build
specialized hwcap versions of libgcc, libm, libc, and similar for classic
and embedded fp with -mfloat-abi=softfp. So you'd get a different ABI
than the current powerpc port, but at the same time this new port could
be used everywhere.
The downsides would be AFAICS:
* Slight overhead (how much?) due to function calls for fp operations,
and move of values from fpr to gpr on classic fp.
* lwsync would need to be handled by the kernel on e500.
* On generic code (one not built specifically for e500), half of the
gpr would not get used.
The upsides would be:
* Code should be ABI comptatible. So one could actually rebuild the
arch for e500 only, if desired, and it would still be ABI compatible.
In the same way one can rebuild the i386 port for a Celeron, and it
should be ABI compatible, even if it will not work on older systems.
* If the performance is not too bad, it could even be considered to
replace the current powerpc architecture? (obviously after
discussion with the porters, etc)
* Native implementations of fp code would be used for either, and no
emulation by the kernel would be needed, not even
Bug#575158: dpkg: Add new 'e500' architecture to triplettable and ostable
Ping?
Raphael, any chance we could get more discussion or agreement from the dpkg
developers regarding the e500v2 architecture name? Both Sebastian and I
are in full agreement that the name e500v2 most accurately describes the
fundamental architecture.
I've included the summarized rationale for the choice at the end of this
email, just in case anyone missed the discussion.
Cheers,
Kyle Moffett
--
Kyle Moffett
eXMeritus Software
Integrated Intelligence
The Boeing Company
(703) 764-0925
(703) 832-0657 (fax)
kyle.d.moff...@boeing.com
* The only chipset families that support SPE instructions are:
* PowerPC e200
* PowerPC e500v1
* PowerPC e500v2
* The incompatibility between various SPE-capable CPUs mean that an arch
spec of spe or powerpcspe is probably insufficiently descriptive.
Yes, probably. Right now we don't see any.
* The e200 processor series is an automotive processor and has
insufficient storage to run even something like Emdebian Crush, let alone to
be able to build anything on its own. It should therefore be excluded from
our discussion. This means we just care about e500v{1,2} cores.
Right. The spec says, that e200z4 and e200z6 are binary compatible with
e500. However, they also mention that double precision can only be
achieved in software. So this looks like double precision opcodes result
in an invalid opcode and we have to emulate them in kernel. This counts
as binary compatible I guess.
* Freescale has indicated that they will not be building any more chipset
families including the SPE instructions, so we don't have to worry about any
newer chipset families.
* We can't tell exactly how common or uncommon the e500v1 chipsets are
because Freescale's chipset comparison tables all just say e500 without
referring to the version. As a result, we should probably be safe rather
than sorry and refer to the version in the arch name (IE: e500v1/e500v2).
* We should just call it just e500v2:
* Sufficiently descriptive of the hardware architecture
* Shorter and easier to type in commands (of which there are a lot)
* Similar situation to lpia (which is not called i386lpia)
The easier-to-type reason is especially applicable if we do a uclibc port,
as the name uclibc-linux-powerpce500 is much more of a pain to type out
repeatedly than uclibc-linux-e500.
Is there anything I left out?
No, I think it is fine. You summarzied it well.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575158: dpkg: Add new 'e500' architecture to triplettable and ostable
* Moffett, Kyle D | 2010-03-25 17:49:33 [-0500]:
We can just use --enable-e500-double when building (recent?) GCC.
Yep, looks good.
Ok, so hopefully we can all agree on e500v2? That's the name I'm going to
go ahead and use in my newest build-cycle.
Yep, I think so. However we will see what will slips into dpkg once it
is there.
For reference, I've included a summary of the rationale behind the
suggestion:
* The only chipset families that support SPE instructions are:
* PowerPC e200
* PowerPC e500v1
* PowerPC e500v2
* The incompatibility between various SPE-capable CPUs mean that an arch
spec of spe or powerpcspe is probably insufficiently descriptive.
Yes, probably. Right now we don't see any.
* The e200 processor series is an automotive processor and has
insufficient storage to run even something like Emdebian Crush, let alone to
be able to build anything on its own. It should therefore be excluded from
our discussion. This means we just care about e500v{1,2} cores.
Right. The spec says, that e200z4 and e200z6 are binary compatible with
e500. However, they also mention that double precision can only be
achieved in software. So this looks like double precision opcodes result
in an invalid opcode and we have to emulate them in kernel. This counts
as binary compatible I guess.
* Freescale has indicated that they will not be building any more chipset
families including the SPE instructions, so we don't have to worry about any
newer chipset families.
* We can't tell exactly how common or uncommon the e500v1 chipsets are
because Freescale's chipset comparison tables all just say e500 without
referring to the version. As a result, we should probably be safe rather
than sorry and refer to the version in the arch name (IE: e500v1/e500v2).
* We should just call it just e500v2:
* Sufficiently descriptive of the hardware architecture
* Shorter and easier to type in commands (of which there are a lot)
* Similar situation to lpia (which is not called i386lpia)
The easier-to-type reason is especially applicable if we do a uclibc port,
as the name uclibc-linux-powerpce500 is much more of a pain to type out
repeatedly than uclibc-linux-e500.
Is there anything I left out?
No, I think it is fine. You summarzied it well.
The difference between a regular cross-compile and an icecc/distcc
cross-buildd is that all the ./configure shell-script madness and some of
the preprocessor crap is run *entirely* on the target system, then the
preprocessed code is shipped across the network to a big beefy x86 box for
building. The environment is indistinguishable from a native build. (except
for the fact that things build a lot faster)
I know how it works. I used it myself thus the bug I pointed you to. I
used it only for the first iteration, second (and following) were native
only.
Compile a little program with -fstack-protector native and cross with
icecc. I saw different results with gcc 4.3 and I haven't checked later.
So even a relatively wimpy 1GHz dual-core system can keep 8-16 cores worth
of beefy x86 systems busy, especially if it's ugly template-heavy C++ code
or something else very CPU intensive to compile. The downside is that the
shell scripts, preprocessor, and linker all need to be run on the target
board, but that's still way better than doing the whole build there.
Right. I'm okay using icecc/distcc on buildds if the target icecc
machine runs native architecture. I don't want to compile cross even
with icecc unless I have to.
Looking at the build time of xulrunner 1.9.0.14:
- s390: 30min
- i386: 33min
- kfreebsd i386 : 39mins
- powerpc: 1h
- alpha: 1:01
- ia64: 1:20
- me[0]: 1:29
- sparc: 1:35
- hppa: 2h
- mipsel: 3h
- mips: 3h
- armel: 14h
So I think it does not look too bad.
[0] I've built it complete, including all debs, ro clue how much extra
time it takes.
Cheers,
Kyle Moffett
Sebastian
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575158: dpkg: Add new 'e500' architecture to triplettable and ostable
On 2010/03/25 16:39, Sebastian Andrzej Siewior sebast...@breakpoint.cc
wrote:
* Moffett, Kyle D | 2010-03-24 19:28:06 [-0500]:
The e500v1 was never very popular and all of the available parts today
support double-precision floating point GPRS. With that said, I'm actually
not sure if my current compiler is built properly to enable use of the
double instructions. If it's not, that's going to be an essential part of
my rebuild the world with whatever arch name the dpkg maintainers want
project.
It is not enabled by default. You have to add -mfloat-gprs=double to
gcc. So it is required to patch the gcc to get this by default I thing.
I haven't look into this.
Actually, according to this bugreport:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42007
We can just use --enable-e500-double when building (recent?) GCC.
I guess I'll have to go rebuild the world again... :-\ This will be maybe
the 4th time... *sigh* At least I still have all the source repositories
with the cross-compile bugfixes!
The e200z6 go up to 300Mhz but I did not find anything that fast. So
there are probably glad to have everything precompiled.
I've been looking at MPC5566 and MPC5668G and they don't have anything
what coould be used as external storage (MMC/ATA/SATA and so on). They
don't seem to have a lot of flash either. So they probably run just
their application and nothing else. Unlikely that firefox mattars :)
Yeah... IMNSHO it should be either e500 or e500v2 just to keep it from
being so dang hard to type. Hopefully we've provided enough information so
the dpkg devs can pick something and we can get on with the official port?
powerpc_e500v2 would make it clear but it is a lot of typing. So right
now I would go e500v2 I guess.
Ok, so hopefully we can all agree on e500v2? That's the name I'm going to
go ahead and use in my newest build-cycle.
For reference, I've included a summary of the rationale behind the
suggestion:
* The only chipset families that support SPE instructions are:
* PowerPC e200
* PowerPC e500v1
* PowerPC e500v2
* The incompatibility between various SPE-capable CPUs mean that an arch
spec of spe or powerpcspe is probably insufficiently descriptive.
* The e200 processor series is an automotive processor and has
insufficient storage to run even something like Emdebian Crush, let alone to
be able to build anything on its own. It should therefore be excluded from
our discussion. This means we just care about e500v{1,2} cores.
* Freescale has indicated that they will not be building any more chipset
families including the SPE instructions, so we don't have to worry about any
newer chipset families.
* We can't tell exactly how common or uncommon the e500v1 chipsets are
because Freescale's chipset comparison tables all just say e500 without
referring to the version. As a result, we should probably be safe rather
than sorry and refer to the version in the arch name (IE: e500v1/e500v2).
* We should just call it just e500v2:
* Sufficiently descriptive of the hardware architecture
* Shorter and easier to type in commands (of which there are a lot)
* Similar situation to lpia (which is not called i386lpia)
The easier-to-type reason is especially applicable if we do a uclibc port,
as the name uclibc-linux-powerpce500 is much more of a pain to type out
repeatedly than uclibc-linux-e500.
Is there anything I left out?
Once I get an e500 board up and running I'm dropping the cross-compiler
package and icecc on all of those systems. I'll then replace /usr/bin/gcc
and /usr/bin/g++ on the e500 board with versions that call icecc or
distcc or whatever as powerpc-linux-gnuspe-{gcc,g++}. That should speed
up my build times considerably by sending a lot of the build jobs across
gigabit to the beefy servers.
That still looks like a cross build and you may want look at [0]. As I
said, I've been there :)
The difference between a regular cross-compile and an icecc/distcc
cross-buildd is that all the ./configure shell-script madness and some of
the preprocessor crap is run *entirely* on the target system, then the
preprocessed code is shipped across the network to a big beefy x86 box for
building. The environment is indistinguishable from a native build. (except
for the fact that things build a lot faster)
So even a relatively wimpy 1GHz dual-core system can keep 8-16 cores worth
of beefy x86 systems busy, especially if it's ugly template-heavy C++ code
or something else very CPU intensive to compile. The downside is that the
shell scripts, preprocessor, and linker all need to be run on the target
board, but that's still way better than doing the whole build there.
Cheers,
Kyle Moffett
--
Kyle Moffett
eXMeritus Software
Integrated Intelligence
The Boeing Company
(703) 764-0925
(703) 832-0657 (fax)
kyle.d.moff...@boeing.com
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble?
Bug#575158: dpkg: Add new 'e500' architecture to triplettable and ostable
* Moffett, Kyle D | 2010-03-23 17:52:57 [-0500]: Ah, my apologies. I'd actually already seen that one, but wasn't paying enough attention when submitting the bugreport. I saw in your earlier bug report that you don't have everything built (yet). At [0] I have more or less complete port of an older lenny snapshot. However, the Debian name is different. I recall that the crossbuild had some dependencies wrong and -fstack-protector did something wrong. Watch out if you building something cross :) The suggested names were different, your input in the discussion is certainly welcome so that the name can be defined once for all. e500 might not be a very wise name if it refers to a specific product rather than a processor family. The spe in the arch triplet refers to the set of extensions to the PowerPC/POWER instruction set that are implemented by the MPC85xx-series processors. The e500-series cores themselves conform to Power ISA v.2.03, but the particular implementation of floating-point support is quirky enough that it requires a separate ABI. I would not use the term quirky. It is not the traditional FPU instead it is a different one. I think it is described as embedded FPU. ARM on the other hand has a few more choices. http://www.phxmicro.com/CourseNotes/E500CORERM_rev1.pdf drivers. Customer software that uses SPE or embedded floating-point APU instructions at the assembly level or that uses SPE intrinsics will require rewriting for upward compatibility with next-generation PowerQUICC devices. I was not aware of that. So while it is theoretically conceivable that a processor core series other than the e500 would support the SPE instruction set, it is unlikely. In the event that something like that occurs however, it would be no different technically from the amd64 or i386 architectures. Neither of those names are even remotely accurate today yet they are commonly understood. They are people that install i386 instead of amd64 on their brand new intel machine because it is not an AMD. So it leads to confusion. In our case it is simple because PowerPC Lenny+ does not boot. Unfortunately, for processors which implement the SPE instruction set there is no other hardware support for floating point. As a result, efficient operation on these processors virtually requires a separate architecture port. That is true. I've backed this up with some numbers at [1] So it is my belief that e500 is the correct and appropriate name for the architecture. Which brings me to the following question: There are currently two types of the core: e500v1 and e500v2. The latter implements also the floating point type double in hardware while the former doesn't. Which one did pick? I would prefer to go for e500v2 since I don't think that there much e500v1 around plus I don't belive that those are used in multimedia like applications. And it would be probably nice to mark this in arch name. To be blatantly honest, I personally would really prefer if that's the final name as it would save me about 3 days worth of re-bootstrapping packages using a different architecture token. If you all think something else is definitely more appropriate I will however defer to your judgment (with some amount of grumbling and complaining). I hope that you don't think that I am a total ass if I say that google should have help find you [3]. No offense please. I would love to have someone on my side so that port is not just a one man show :) Anyway. My plan is to settle down on a name and get everything rebuilt for debian-ports. So even if we stick to e500 as you wish everything will be rebuilt by buildd or atleast by manual sbuild anyway. So what about keeping powerpc somewhere in the name? I think it is a good idea to denote the double type (I would prefer not to switch it once we have a port). So powerpce500v2 would make it clear, wouldn't it? It is hard to read so maybe e500v2 isn't that bad at all. Cheers, Kyle Moffett [0] http://download.breakpoint.cc/debian/linutronix-lenny-gnuspe/ [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520877#48 [2] http://www.mail-archive.com/debian-powe...@lists.debian.org/msg60499.html Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575158: dpkg: Add new 'e500' architecture to triplettable and ostable
Package: dpkg Version: 1.15.5.6 Severity: wishlist Tags: patch At this time, we have the Debian binutils, gcc, and eglibc packages building cross-compilers for e500 correctly with just a few minor patches. A few other packages (libmpfr, libgmp) needed to be crossbuilt (with minor patches only to enable cross-compilation). We do not yet have a full self-hosting e500 environment constructed, but we are actively working to complete one on our development boards. I've included inline the exported git patch from our internal dpkg source tree: From: Kyle Moffett kyle.d.moff...@boeing.com Date: Tue, 23 Mar 2010 14:45:12 -0400 Subject: [PATCH] Add new 'e500' architecture to triplettable and ostable The 'e500' architecture (also called MPC85xx) is a binary-incompatible variant of PowerPC/POWER designed and supported by FreeScale and IBM. Additional information can be found at: http://en.wikipedia.org/wiki/PowerPC_e500 It has the unfortunate GNU arch triplet of powerpc-linux-gnuspe, when it should have been powerpcspe-linux-gnu or e500-linux-gnu. This causes much the same problem and has the same solution as the lpia architecture's triplet: arm-linux-gnulp. The result is a few extra entries in the ostable file to deal with the quirk. At this time the 'e500' architecture port is still very much an unofficial port. While we hope that will change in the future, it is entirely possible that the embedded niche of the processor will make such an official Debian port problematic. Signed-off-by: Kyle D Moffett kyle.d.moff...@boeing.com --- ostable |2 ++ triplettable |2 ++ 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/ostable b/ostable index 2ef2cdd..989c220 100644 --- a/ostable +++ b/ostable @@ -15,8 +15,10 @@ # # Debian nameGNU name config.guess regex uclibceabi-linux linux-uclibceabilinux[^-]*-uclibceabi +uclibcspe-linuxlinux-uclibcspe linux[^-]*-uclibcspe uclibc-linux linux-uclibclinux[^-]*-uclibc gnueabi-linux linux-gnueabi linux[^-]*-gnueabi +gnuspe-linux linux-gnuspelinux[^-]*-gnuspe gnulp-linuxlinux-gnulp linux[^-]*-gnulp gnu-linux linux-gnu linux[^-]*(-gnu.*)? gnu-kfreebsd kfreebsd-gnukfreebsd[^-]*(-gnu.*)? diff --git a/triplettable b/triplettable index 1a2c666..d1eeadf 100644 --- a/triplettable +++ b/triplettable @@ -4,8 +4,10 @@ # # Debian triplet Debian arch uclibceabi-linux-arm uclibc-linux-armel +uclibcspe-linux-powerpcuclibc-linux-e500 uclibc-linux-cpu uclibc-linux-cpu gnueabi-linux-arm armel +gnuspe-linux-powerpc e500 gnulp-linux-i386 lpia gnu-linux-cpucpu gnu-kfreebsd-cpu kfreebsd-cpu -- 1.7.0 -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (990, 'stable'), (700, 'testing'), (600, 'unstable'), (500, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages dpkg depends on: ii coreutils 6.10-6 The GNU core utilities ii libc6 2.10.2-2 GNU C Library: Shared libraries ii lzma 4.43-14Compression method of 7z format in dpkg recommends no packages. Versions of packages dpkg suggests: ii apt 0.7.25.3 Advanced front-end for dpkg -- no debconf information From 9a567d5146c6a0a25365a20a1eee0a6f77f522f2 Mon Sep 17 00:00:00 2001 From: Kyle Moffett kyle.d.moff...@boeing.com Date: Tue, 23 Mar 2010 14:45:12 -0400 Subject: [PATCH] Add new 'e500' architecture to triplettable and ostable The 'e500' architecture (also called MPC85xx) is a binary-incompatible variant of PowerPC/POWER designed and supported by FreeScale and IBM. Additional information can be found at: http://en.wikipedia.org/wiki/PowerPC_e500 It has the unfortunate GNU arch triplet of powerpc-linux-gnuspe, when it should have been powerpcspe-linux-gnu or e500-linux-gnu. This causes much the same problem and has the same solution as the lpia architecture's triplet: arm-linux-gnulp. The result is a few extra entries in the ostable file to deal with the quirk. At this time the 'e500' architecture port is still very much an unofficial port. While we hope that will change in the future, it is entirely possible that the embedded niche of the processor will make such an official Debian port problematic. Signed-off-by: Kyle D Moffett kyle.d.moff...@boeing.com --- ostable |2 ++ triplettable |2 ++ 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/ostable b/ostable index 2ef2cdd..989c220 100644 --- a/ostable +++ b/ostable @@ -15,8 +15,10 @@ # # Debian nameGNU name config.guess regex
Bug#575158: dpkg: Add new 'e500' architecture to triplettable and ostable
forcemerge 568123 575158 thanks On Tue, 23 Mar 2010, Kyle Moffett wrote: It has the unfortunate GNU arch triplet of powerpc-linux-gnuspe, when it should have been powerpcspe-linux-gnu or e500-linux-gnu. This causes much the same problem and has the same solution as the lpia architecture's triplet: arm-linux-gnulp. The result is a few extra entries in the ostable file to deal with the quirk. We already got a bugreport about this: http://bugs.debian.org/568123 The suggested names were different, your input in the discussion is certainly welcome so that the name can be defined once for all. e500 might not be a very wise name if it refers to a specific product rather than a processor family. Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575158: dpkg: Add new 'e500' architecture to triplettable and ostable
On 2010/03/23 18:21, Raphael Hertzog hert...@debian.org wrote: On Tue, 23 Mar 2010, Kyle Moffett wrote: It has the unfortunate GNU arch triplet of powerpc-linux-gnuspe, when it should have been powerpcspe-linux-gnu or e500-linux-gnu. This causes much the same problem and has the same solution as the lpia architecture's triplet: arm-linux-gnulp. The result is a few extra entries in the ostable file to deal with the quirk. We already got a bugreport about this: http://bugs.debian.org/568123 Ah, my apologies. I'd actually already seen that one, but wasn't paying enough attention when submitting the bugreport. The suggested names were different, your input in the discussion is certainly welcome so that the name can be defined once for all. e500 might not be a very wise name if it refers to a specific product rather than a processor family. The spe in the arch triplet refers to the set of extensions to the PowerPC/POWER instruction set that are implemented by the MPC85xx-series processors. The e500-series cores themselves conform to Power ISA v.2.03, but the particular implementation of floating-point support is quirky enough that it requires a separate ABI. The Wikipedia page is particularly enlightening: http://en.wikipedia.org/wiki/PowerPC_e500 Currently Freescale is the only company that makes processors which have support for the SPE/Signal Processing Engine instructions (all of those cores are referred to with the designator e500). The core reference manual indicates: http://www.phxmicro.com/CourseNotes/E500CORERM_rev1.pdf The SPE APU and embedded floating-point APU functionality is implemented in all PowerQUICC III devices. However, these instructions will not be supported in devices subsequent to PowerQUICC III. Freescale Semiconductor strongly recommends that use of these instructions be confined to libraries and device drivers. Customer software that uses SPE or embedded floating-point APU instructions at the assembly level or that uses SPE intrinsics will require rewriting for upward compatibility with next-generation PowerQUICC devices. So while it is theoretically conceivable that a processor core series other than the e500 would support the SPE instruction set, it is unlikely. In the event that something like that occurs however, it would be no different technically from the amd64 or i386 architectures. Neither of those names are even remotely accurate today yet they are commonly understood. Unfortunately, for processors which implement the SPE instruction set there is no other hardware support for floating point. As a result, efficient operation on these processors virtually requires a separate architecture port. So it is my belief that e500 is the correct and appropriate name for the architecture. To be blatantly honest, I personally would really prefer if that's the final name as it would save me about 3 days worth of re-bootstrapping packages using a different architecture token. If you all think something else is definitely more appropriate I will however defer to your judgment (with some amount of grumbling and complaining). Cheers, Kyle Moffett -- Kyle Moffett eXMeritus Software Integrated Intelligence The Boeing Company (703) 764-0925 (703) 832-0657 (fax) kyle.d.moff...@boeing.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
