On Fri, May 19, 2006 at 02:07:01PM +1000, Benjamin Herrenschmidt wrote:

The Cell has a couple of "features" that should be exposed to userland
in a way or another. That raises some questions however about how those
should be done. Among others that come to mind:

Good questions, to make things scale when going from here on out
(including new products from various companies in the PPC arena), more
fine-grained features would certainly be useful.

 - The timebase errata (should we use a separate aux vector for "bugs"
than for "features" ?

How are other userspace-exposed erratas normally handled? How are they
handled on other architectures? Adding it to the feature aux table
sounds like a bad idea.

 - Additional Altivec instructions (load/store right/left). A new
feature bit for these ?
 - Lack of data stream instructions. Until now, it was assumed that
those were tied to the presence
   of an Altivec (and they are documented in the Altivec manual). Maybe
we should split that to a
   new bit. I don't know if existing applications use them though, if
they do, there will be a 
   problem to get them updated as the new bit isn't present on older
kernels...

I'm assuming you mean the instructions described under "AltiVec Memory
Bandwidth Management" in secion 5.2 of the Altivec PEM -- dst, dstt,
dstst, dss and dssall?

Since they're explicitly part of the Altivec ISA, not the PPC ISA,
I don't see a need for a separate feature bit for them. They are not
marked as optional in the version I'm looking at right now (2.0).

 - Extended implementation of dcbt. (Another bit ? Or sould we just have
a "CELL" bit ? In which
   case should it cover the altivec additions too or are those likely to
exist in future non-Cell 
   processors ?)

If you're referring to the extended dcbt that includes streaming hints
(as documented in the 64-bit PEM, but not in PPC book2 2.02), then a
separate bit is likely needed -- obviously at least 970 seems to
implement them.

 - Not strictly Cell specific but we currently don't expose the support
for optional instructions
   fres and frsqte (which are supported by Cell)

Part of the problem is that we only have 32 userland feature bits and
for some reason decided to put the microarchitecture in there, thus we
are running out fast...

 From what I understood by Paul's choice of feature naming (see the
POWER6 patch discussions), PPC_ARCH_2_05 and similar will mean base
architecture version implemented and should not be used to assume
anything about optional features.

So, with that as a base, there will need to be a way to
indicate which optional features are available, plus what possible
extensions/implementation-specific features are there, at least if they
are common to more than one implementation/processor version. Bit arrays
seem to be the New Way of doing it between firmware and kernel, maybe
the same can/should be used for kernel->userspace? Can the aux vectors
be of arbitrary length?


-Olof