On 15/03/2017 14:26, Segher Boessenkool wrote:
I do not think VLE can get in, not in its current shape at least.
That's unfortunate. Disregarding the SPE splitting plan for a moment,
what do you think would need to be done to get it into shape? I had
thought we were almost there with the patches that I sent to you and
David off-list last year.
> VLE
is very unlike PowerPC in many ways so it comes at a very big cost to
the port (maintenance and otherwise -- maintenance is what I care about
most).
I completely understand.
Since SPE and VLE only share the part of the rs6000 port that doesn't
change at all (except for a bug fix once or twice a year), and everything
else needs special cases all over the place, it seems to me it would be
best for everyone if we split the rs6000 port in two, one for SPE and VLE
and one for the rest. Both ports could then be very significantly
simplified.
I am assuming SPE and VLE do not support AltiVec or 64-bit PowerPC,
please correct me if that is incorrect. Also, is "normal" floating
point supported at all?
My understanding is that SPE is only present in the e500v1, e500v2 and
e200z[3-7] cores, all of which are 32-bit only and do not have classic
floating-point units. SPE and Altivec cannot coexist as they have some
overlapping instruction encodings. The successor to e500v2 (e500mc)
reinstated classic floating-point and got rid of SPE.
Do you (AdaCore and Mentor) think splitting the port is a good idea?
It wouldn't have been my preference, but I can understand the appeal of
that plan for you. I'm surprised that the amount of shared code between
SPE and PowerPC is as little as you say, but you have much more
experience with the PowerPC port than I do, so I'll defer to your
expertise on that matter.
Are you proposing to take on the task of actually splitting it yourself?
If so, that would make me a lot happier about it.
>> -te200z0
>> -te200z3
>> -te200z4
>
> These are VLE?
Yes.
> Do some of those also support PowerPC?
All the e200 cores apart from e200z0 can execute 32-bit instructions as
well as VLE, though we'll always generate VLE code when targetting them
(otherwise they're fairly standard).
Andrew
