From: Gabriel Paubert <paubert@iram•es>
To: Benjamin Herrenschmidt <benh@kernel•crashing.org>
Cc: linuxppc-dev list <linuxppc-dev@ozlabs•org>,
Paul Mackerras <paulus@samba•org>,
cbe-oss-dev@ozlabs•org, Arnd Bergmann <arnd@arndb•de>
Subject: Re: Cell and new CPU feature bits
Date: Fri, 19 May 2006 10:16:55 +0200 [thread overview]
Message-ID: <20060519081654.GB22952@iram.es> (raw)
In-Reply-To: <1148011621.13249.7.camel@localhost.localdomain>
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
next prev parent reply other threads:[~2006-05-19 8:17 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-19 4:07 Cell and new CPU feature bits Benjamin Herrenschmidt
2006-05-19 5:19 ` Olof Johansson
2006-05-19 5:27 ` [Cbe-oss-dev] " Andrew Pinski
2006-05-19 7:49 ` Segher Boessenkool
2006-05-26 6:19 ` Benjamin Herrenschmidt
2006-05-26 6:19 ` Benjamin Herrenschmidt
2006-05-26 6:43 ` Olof Johansson
2006-05-26 7:33 ` Benjamin Herrenschmidt
2006-05-26 15:16 ` Olof Johansson
2006-05-19 8:16 ` Gabriel Paubert [this message]
2006-05-22 19:46 ` [Cbe-oss-dev] " Alex Rosenberg
2006-05-23 21:52 ` Benjamin Herrenschmidt
2006-05-26 6:22 ` Benjamin Herrenschmidt
2006-05-19 10:11 ` [Cbe-oss-dev] " Arnd Bergmann
2006-05-19 16:18 ` Olof Johansson
2006-05-19 22:33 ` Paul Mackerras
2006-05-26 6:22 ` [Cbe-oss-dev] " Benjamin Herrenschmidt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060519081654.GB22952@iram.es \
--to=paubert@iram$(echo .)es \
--cc=arnd@arndb$(echo .)de \
--cc=benh@kernel$(echo .)crashing.org \
--cc=cbe-oss-dev@ozlabs$(echo .)org \
--cc=linuxppc-dev@ozlabs$(echo .)org \
--cc=paulus@samba$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox