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 on FPU-less
PowerPCs.
Do you see this as a possible workable solution, or is it completely
unnacceptable? Did I miss something besides what I listed here?
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
> >> * 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?
> > 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.
> >> * 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
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.
> >> * Shorter and easier to type in commands (of which there are a lot)
Sure, but then something like ppcspe is quite short too, maybe not as
readable though.
> >> * Similar situation to "lpia" (which is not called "i386lpia")
That would be redundant. :) Anyway as mentioned before i386 is
probably not the correct thing to compare against IMO, and lpia is quite
close to ia32 for example.
> >> 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".
If you are doing anything not using glibc, you should be up for the pain
anyway. :)
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.
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.
thanks,
guillem
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
