Cell and new CPU feature bits

Cell and new CPU feature bits

[Benjamin Herrenschmidt]

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:

 - The timebase errata (should we use a separate aux vector for "bugs"
than for "features" ?
 - 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...
 - 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 ?)
 - 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...

Ben.

Re: Cell and new CPU feature bits

[Olof Johansson]

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

Re: [Cbe-oss-dev] Cell and new CPU feature bits

[Andrew Pinski]

On May 18, 2006, at 10:19 PM, Olof Johansson wrote:

>>  - 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?

They are nops on the Cell though.  They are also microcoded on the 970.
>
> 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.

Yes they are implemented on the 970.

Thanks,
Andrew Pinski

Re: [Cbe-oss-dev] Cell and new CPU feature bits

[Segher Boessenkool]

>> 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?
>
> They are nops on the Cell though.

And that is a compliant implementation.  I don't see a need
or real use for a feature bit here, esp. if we do get one for
the extended dcbt insns (which often are used as a replacement
for the data streaming insns).

> They are also microcoded on the 970.

No, they are cracked, instead.  Much lower hit.  They are completion
serialized though, so the only insn in an issue group, etc.


Segher

Re: [Cbe-oss-dev] Cell and new CPU feature bits

[Benjamin Herrenschmidt]

> > 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?
> 
> They are nops on the Cell though.  They are also microcoded on the 970.

It's still useful to have a way to inform userland of their absence (or
inefficency).

> > 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.
> 
> Yes they are implemented on the 970.

Re: Cell and new CPU feature bits

[Benjamin Herrenschmidt]

So, replying to Olof and myself and asking for Steve Munroe point of
view...

> 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.

Well, I suspect so far we have avoided the problem by just assuming
there are no such erratas :)

It's an ABI issue so I'd like Steve to provide some feedback on this. I
suppose we should probably define an AT_CPU_ERRATA capability

> >  - Additional Altivec instructions (load/store right/left). A new
> > feature bit for these ?

I think a new feature bit is the way to go but we need to start now
about how to extend our feature bit facility, maybe by defining an
AT_HWCAP2 ? Steve, what is your position there ?

> >  - 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?

Yes.

> 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).

They are not implemented on Cell though. I don't know yet if they are
NOP's or if they fault but we should still inform userland of the
situation.

Thus should we add a feature bit documenting the existence of those
instructions or should we use an errata bit (provided we define
something for passing them as suggested above) ?

> >  - 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.

Yes, I think a new CPU feature bit for that too is needed. Not much of
these left...

> >  - 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?

So the question is should we specify a feature bit for fres and frsqte
or should we let userland assume they are always there on a given
microarchitecture level ?

Steve, another solution is to go to a completely different model (maybe
closer than what apple does) and add an interface similar to Apple old
Gestalt (as mentioned by Alex Rosenberg in a separate email) that could
go through the vDSO. The idea boils down to replacing our current
bitmaps with something like:

	__kernel_cpu_feature(const char *name);

(Apple Gestalt returns a long in addition to a result code that can
contain arbitrary things like version numbers etc... but I'm against
that, I have first hand experience on how that can be abused :) I prefer
a simple boolean result.

The "feature" are named (ascii strings) with a strict naming convention.
For example, erratas always start with "err-", optional architecture
bits with "opt-", totally chip specific functions "chip-", etc...

As far as userland is concerned, glibc could expose a lot of this
through sysconf, or provide a way to get to the vDSO call (though we'll
have to fight with the folks there).

That doesn't completely solve another pending problem we have with
passing down to userland other specific infos like L2/L3 cache
characteristics but I don't see a good solution yet there. Maybe a
separate vDSO call for use by glibc to use to implement sysconf ? Among
the things we've been asked are cache line sizes (we have L1 I and D
already in AT_*), cache associativity (generally available in the device
tree but not provided to userland), cache total size (we put some L1
infos in the deprecated-but-still-present systemcfg, we need a
replacement API), etc... Note that we have been requested to also add
L2/L3 infos but I noticed that our firmware doesn't tell us on modern
CPUs, thus for each of these infos, we also need a way to say "unknown".

Ben.

Re: Cell and new CPU feature bits

[Olof Johansson]

On Fri, May 26, 2006 at 04:19:17PM +1000, Benjamin Herrenschmidt wrote:
> So, replying to Olof and myself and asking for Steve Munroe point of
> view...
> 
> > 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.
> 
> Well, I suspect so far we have avoided the problem by just assuming
> there are no such erratas :)
> 
> It's an ABI issue so I'd like Steve to provide some feedback on this. I
> suppose we should probably define an AT_CPU_ERRATA capability
> 
> > >  - Additional Altivec instructions (load/store right/left). A new
> > > feature bit for these ?
> 
> I think a new feature bit is the way to go but we need to start now
> about how to extend our feature bit facility, maybe by defining an
> AT_HWCAP2 ? Steve, what is your position there ?

And what happens when that gets full? Or can we make that one dynamic in
size?

> > >  - 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?
> 
> Yes.
> 
> > 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).
> 
> They are not implemented on Cell though. I don't know yet if they are
> NOP's or if they fault but we should still inform userland of the
> situation.
> 
> Thus should we add a feature bit documenting the existence of those
> instructions or should we use an errata bit (provided we define
> something for passing them as suggested above) ?

Only if there's truly uses for it. Do we really want to allocate global
bits for every errata that every vendor introduces?

Do we see this likely to be used in "global userspace", or more likely
in the processor-specific glibc sections? If it's in the
processor-specific ones, maybe we should have a per-processor bitfield
with erratas/features instead of a global one. That'd make allocation
easier too.

I.e. a main feature bitmask like we have now (architecture base
version), and a sub-bitmask with the optional features. That also avoids
the issue of allocating a global bit for something that is a feature in
version X but non-optional in X+1, you can never "get that bit back".

> > >  - 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.
> 
> Yes, I think a new CPU feature bit for that too is needed. Not much of
> these left...

Well, are these instructions architected in some later version past
2.02? If so, the bit is only needed on the older processors -- yet again
a case for sub-feature/errata bitmasks.

[rest is good discussion but I don't have much input on it at this time.
Something gestalt-like could be good, it'd help remove some of the
current limits on bitmap sizes, etc]


-Olof

Re: Cell and new CPU feature bits

[Benjamin Herrenschmidt]

> > I think a new feature bit is the way to go but we need to start now
> > about how to extend our feature bit facility, maybe by defining an
> > AT_HWCAP2 ? Steve, what is your position there ?
> 
> And what happens when that gets full? Or can we make that one dynamic in
> size?

You can't make AT_* entries dynamic, though we can be ugly and have them
contain an offset to some space on the stack with a blob, though that
would require serious hacks in the kernel's binfmt_elf I suppose. Even
if it's a bit ugly, there is no fundamental problem with adding
AT_HWCAP2 and maybe later 3 etc... A given bit is defined to be in a
given one of these, thus apps who know about a bit that is in AT_HWCAP-N
(and are looking for it) will also know about AT_HWCAP-N. Still ugly
tho.

> > Thus should we add a feature bit documenting the existence of those
> > instructions or should we use an errata bit (provided we define
> > something for passing them as suggested above) ?
> 
> Only if there's truly uses for it. Do we really want to allocate global
> bits for every errata that every vendor introduces?

If they affect userland, yes.

> Do we see this likely to be used in "global userspace", or more likely
> in the processor-specific glibc sections? If it's in the
> processor-specific ones, maybe we should have a per-processor bitfield
> with erratas/features instead of a global one. That'd make allocation
> easier too.

Do we have to deal with that many errata that affect userland ? It's
generally an area where processors are fairly well validated... I don't
think we need to scale up that much on this one.

> I.e. a main feature bitmask like we have now (architecture base
> version), and a sub-bitmask with the optional features. That also avoids
> the issue of allocating a global bit for something that is a feature in
> version X but non-optional in X+1, you can never "get that bit back".

Could be. Steve, what do you think ?

> > Yes, I think a new CPU feature bit for that too is needed. Not much of
> > these left...
> 
> Well, are these instructions architected in some later version past
> 2.02? If so, the bit is only needed on the older processors -- yet again
> a case for sub-feature/errata bitmasks.

I have to check but I suspect it's still optional.

> [rest is good discussion but I don't have much input on it at this time.
> Something gestalt-like could be good, it'd help remove some of the
> current limits on bitmap sizes, etc]

Ben.

Re: Cell and new CPU feature bits

[Olof Johansson]

On Fri, May 26, 2006 at 05:33:51PM +1000, Benjamin Herrenschmidt wrote:

> > Do we see this likely to be used in "global userspace", or more likely
> > in the processor-specific glibc sections? If it's in the
> > processor-specific ones, maybe we should have a per-processor bitfield
> > with erratas/features instead of a global one. That'd make allocation
> > easier too.
> 
> Do we have to deal with that many errata that affect userland ? It's
> generally an area where processors are fairly well validated... I don't
> think we need to scale up that much on this one.

Right, amount of erratas should be limited. BUt the amount of features
can be larger, especially as they grow over time and never go away.

> > > Yes, I think a new CPU feature bit for that too is needed. Not much of
> > > these left...
> > 
> > Well, are these instructions architected in some later version past
> > 2.02? If so, the bit is only needed on the older processors -- yet again
> > a case for sub-feature/errata bitmasks.
> 
> I have to check but I suspect it's still optional.

Ok. Features like that tend to be implementation-specific in the firt
processor they show up in, and later make it into the architecture.
That's why I'm asking. :-)

-Olof

Re: Cell and new CPU feature bits

[Gabriel Paubert]

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:
> 
>  - The timebase errata (should we use a separate aux vector for "bugs"
> than for "features" ?

Is this bug really going to be exposed in the wild or is it
an early silicon bug that will only bite early-testers?

>  - Additional Altivec instructions (load/store right/left). A new
> feature bit for these ?

Yes. So IBM was not happy with Altivec instructions to generate
vsel control words and got their inspiration from MIPS?

>  - 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...

Is it really important? These instructions become nop on Cell, so their
impact on performance should be minimal while they may be useful in
code designed to run on any processor having Altivec.

>  - 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 ?)

I believe that a Cell bit would be useful. After all you need a bit
that tell you that you have the SPUs and related infrastructure?

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

Should be exposed IMHO. But these instructions have been present
in a lot of PPC processors AFAIR, they are in my original 603 and
604 manuals from 1994 (fsel is also marked as optional and is not
implemented on the 601, but I'm not sure it's really supported
anymore). I don't know about Power processors. 

> 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...

It will have to be extended and perhaps become a variable length
structure, better sooner than later.

	Regards,
	Gabriel

Re: [Cbe-oss-dev] Cell and new CPU feature bits

[Alex Rosenberg]

On May 19, 2006, at 1:16 AM, Gabriel Paubert wrote:

> 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:
>>
>>  - The timebase errata (should we use a separate aux vector for  
>> "bugs"
>> than for "features" ?
>
> Is this bug really going to be exposed in the wild or is it
> an early silicon bug that will only bite early-testers?

Is this or any other errata published somewhere? I didn't think they  
were.

>>  - Additional Altivec instructions (load/store right/left). A new
>> feature bit for these ?
>
> Yes. So IBM was not happy with Altivec instructions to generate
> vsel control words and got their inspiration from MIPS?

I think you can blame Waternoose for this, not Cell.

>>  - Not strictly Cell specific but we currently don't expose the  
>> support
>> for optional instructions
>>    fres and frsqte (which are supported by Cell)
>
> Should be exposed IMHO. But these instructions have been present
> in a lot of PPC processors AFAIR, they are in my original 603 and
> 604 manuals from 1994 (fsel is also marked as optional and is not
> implemented on the 601, but I'm not sure it's really supported
> anymore). I don't know about Power processors.

Our solution back at Apple was to put OF properties on the CPU node  
for each optional feature. e.g. for fres and frsqrte we put  
"graphics" since that's the official term for that group of optional  
instructions. We also put in "data-streams" instead of presuming that  
dss, etc. were always part of "altivec". These properties nicely fit  
into our Gestalt() API where "ppcf" had 32 bits to describe these to  
userland software.

-----------------------------------------
Alex Rosenberg
Runtime Lead, Tools & Technology team
Sony Computer Entertainment America, Inc.

Re: [Cbe-oss-dev] Cell and new CPU feature bits

[Benjamin Herrenschmidt]

> > Is this bug really going to be exposed in the wild or is it
> > an early silicon bug that will only bite early-testers?
> 
> Is this or any other errata published somewhere? I didn't think they  
> were.

I don't know, but I got approval to publically talk about that one (that
is to get a fix in the kernel, the vDSO, and see with Steve Munroe about
getting one in glibc hptiming as well)

> Our solution back at Apple was to put OF properties on the CPU node  
> for each optional feature. e.g. for fres and frsqrte we put  
> "graphics" since that's the official term for that group of optional  
> instructions. We also put in "data-streams" instead of presuming that  
> dss, etc. were always part of "altivec". These properties nicely fit  
> into our Gestalt() API where "ppcf" had 32 bits to describe these to  
> userland software.

Our firmwares do something similar, at least on pSeries (the cell blade
firmware may need a bit of kicking there). But that's only useful for
the kernel. I'm more interested about what is best to expose those to
userland and we have no such thing as good ol' Gestalt there :) We have
AT_HWCAP which we already use for a combination of things, and I was
wondering about the risk of running out of bits in there. Maybe we'll
have to extend the thing a bit.

I suppose the datastream instructions will mandate their own bits,
though nobody on the field seem to use them on linux at least on open
source code I've seen, and I'll probably add a separate bit for the new
altivec instructions. I was wondering if I should define a bit for those
"graphics" instruction and dcbf X form (at least the later could be just
derived from the uArchitecture bits in there)

Cheers,
Ben.

Re: Cell and new CPU feature bits

[Benjamin Herrenschmidt]

On Fri, 2006-05-19 at 10:16 +0200, Gabriel Paubert wrote:

> Is this bug really going to be exposed in the wild or is it
> an early silicon bug that will only bite early-testers?

In the wild.

> >  - Additional Altivec instructions (load/store right/left). A new
> > feature bit for these ?
> 
> Yes. So IBM was not happy with Altivec instructions to generate
> vsel control words and got their inspiration from MIPS?

No idea ;)

> Is it really important? These instructions become nop on Cell, so their
> impact on performance should be minimal while they may be useful in
> code designed to run on any processor having Altivec.

We can ignore that problem (datastream, I cut too much of the original
message :) I suppose but I'd like to have as much point of views here as
we are tackling kernel ABI issues so we can't change things every five
minutes here.

> I believe that a Cell bit would be useful. After all you need a bit
> that tell you that you have the SPUs and related infrastructure?

We already have microarchitecture and SPUs can be detected via the
device-tree or sysfs. But that dcbt X form also exist on other
processors

> >  - Not strictly Cell specific but we currently don't expose the support
> > for optional instructions
> >    fres and frsqte (which are supported by Cell)
> 
> Should be exposed IMHO. But these instructions have been present
> in a lot of PPC processors AFAIR, they are in my original 603 and
> 604 manuals from 1994 (fsel is also marked as optional and is not
> implemented on the 601, but I'm not sure it's really supported
> anymore). I don't know about Power processors. 

So what do you suggest I do ? Add feature bits for them and for fsel
too ?

Re: [Cbe-oss-dev] Cell and new CPU feature bits

[Arnd Bergmann]

On Friday 19 May 2006 06:07, Benjamin Herrenschmidt wrote:
>  - 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 ?)

Isn't that already covered by PPC_FEATURE_CELL? Git log shows

| commit a7ddc5e85351931b67a48afa22788d77763837d8
| Author: Paul Mackerras <paulus@samba.org>
| Date:   Thu Nov 10 14:29:18 2005 +1100
|
|    powerpc: Add user CPU features for POWER4, POWER5, POWER5+ and Cell.
|
|    This is at the request of the glibc folks, who want to use these bits
|    to select libraries optimized for the microarchitecture and new
|    instructions in these processors.
|
|    Signed-off-by: Paul Mackerras <paulus@samba.org>

	Arnd <><

Re: Cell and new CPU feature bits

[Olof Johansson]

On Fri, May 19, 2006 at 12:11:18PM +0200, Arnd Bergmann wrote:
> On Friday 19 May 2006 06:07, Benjamin Herrenschmidt wrote:
> >  - 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 ?)
> 
> Isn't that already covered by PPC_FEATURE_CELL? Git log shows

First, please don't use the cell bit for this since other processors
seem to implement the same things.

Second, the quoted information is 6 months old, and seemingly stale by
now. When Paulus pushed the POWER6 patch, he switched from the notion
of it signifying processor model to being base arch version. See:

http://ozlabs.org/pipermail/linuxppc-dev/2006-April/022525.html

(My patch to rename the existing POWER* bits to ARCH_2_* wasn't picked
up, I'll resend)


-Olof

Re: Cell and new CPU feature bits

[Paul Mackerras]

Olof Johansson writes:

> (My patch to rename the existing POWER* bits to ARCH_2_* wasn't picked
> up, I'll resend)

The problem is that those names are now part of the API.  I'll need an
ack from the glibc developers before I apply your patch to change them.

Paul.

Re: [Cbe-oss-dev] Cell and new CPU feature bits

[Benjamin Herrenschmidt]

On Fri, 2006-05-19 at 12:11 +0200, Arnd Bergmann wrote:
> On Friday 19 May 2006 06:07, Benjamin Herrenschmidt wrote:
> >  - 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 ?)
> 
> Isn't that already covered by PPC_FEATURE_CELL? Git log shows

Not specific to cell, 970 at least has it too.

Ben.