[libre-riscv-dev] PowerISA 3.1 (Power10) spec released

Luke Kenneth Casson Leighton lkcl at lkcl.net
Tue May 12 10:09:33 BST 2020

crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Tue, May 12, 2020 at 9:49 AM Lauri Kasanen <cand at gmx.com> wrote:
> On Tue, 12 May 2020 09:33:52 +0100
> Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:
> > i recall (and could be wrong about) seeing that there's different
> > bits, one covering instructions, one covering data.  would need to
> > read them more closely.  are you saying that the BE-for-instructions
> > bit will flip *data* order as well?
> I'm not that familiar with the low level details, I was speaking from
> the compliance POV. Aka BE instructions only is not enough to be
> compliant. If there are plans to support full BE, then it'd be fine.

ok so, combining page x "Linux Optional Features"

Big Endian (BE)
(LE is required for LCS. Linux supporting
LCS is 64b LE Linux.)

this basically defines - *defines* - the Linux Compliancy Subset - as
64 bit LE, with BE being optional

and page xi "Scalar Float Optional Features":

Little Endian (LE)
(BE is required for SFFS and SFS. Linux
supporting SFFS and SFS is 32b BE

this *defines* the "Scalar Fixed (+Float) Compliancy Subset" - both
SFFS and SFS - as *32-bit* BE, with **LE** being optional - the
*opposite* of the 64-bit case.


i recognise this pattern.  i know what this is for.

* AIX compliance is for IBM internal support of AIX - running on IBM POWER9
* Linux compliance is for debian / fedora ppc64le - running on IBM POWER9
* SFFS compliance is for NXP Quorl (2.07B compliant) such as that used
in powerpc-notebook.org
* SFS compliance is for NXP MCP5xxx processors - 32-bit non-FP-based
embedded (32 to 300 mhz)

(there's probably other processor products out there which match with
those 4 levels, i just don't know what they are).

so they're recognising the various product ranges that already exist
in the various market(s).  which is sensible.

what they haven't had time to do is take into full consideration our
design, which needs to be GNU/Linux compliant but not completely
overwhelm both us and the power consumption and the die area, only to
support instructions suited to high-end server and supercomputing
markets (VSX and VMX), placing even the Quad-Core ASIC into markets
it's *never going to be in*.


More information about the libre-riscv-dev mailing list