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 subset
> he/she can pick a new name which denotes this and recompile. The only
> thing that has to be touched are code generators and only if they are
> required. So this is just a matter of enough compile HW.
If deciding on "powerpcspe" (using the "--enable-e500_double" GCC build
option) makes everybody happy and lets us move forward quickly with this
port that's good for me :-D. I guess the next step is to go pester the
folks running debian-ports.org to see if they can help me set up a
"powerpcspe" buildd server that communicates with their "wanna-build"
infrastructure and repository.
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.
Cheers,
Kyle Moffett
--
Kyle Moffett
eXMeritus Software
Integrated Intelligence
The Boeing Company
(703) 764-0925
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
