[Libre-soc-dev] v3.1B prefix

[Luke Kenneth Casson Leighton]

On Fri, Dec 4, 2020 at 12:30 AM Jacob Lifshay <programmerjake at gmail.com> wrote:
>
> On Thu, Dec 3, 2020, 16:11 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> wrote:
>
> > On 12/3/20, Jacob Lifshay <programmerjake at gmail.com> wrote:
> >
> > > See https://libre-soc.org/openpower/sv/svp_rewrite/svp64/ for a WIP
> > version
> > > of SVP64, it should explain/answer some of your questions.
> >
> > ok, so i see a redesign of the 32 bits of the EXT01 space, some fixed
> > bits (6, 9) which i will need to look up to understand, but basically
> > the TBD bits total 24.
>
>
> those two fixed bits are used to select an unallocated quarter of the
> 64-bit prefix space.
>
> >
> > the other part is a table of the EXT01 64 Major opcodes.
> >
>
> The table is not actually primary opcodes, it is instead a table of bits
> 6-11 (iirc) of the prefix (matching the table in the v3.1 spec appendix),

urrrrr.... argh.... mind-melted.... bits 6 thru 11 of the *prefix*....
which is not in the slightest bit obvious how that works by examining
p22 1.6.3 and 1.6.4.


> showing the spaces already allocated in OpenPower ISA v3.1, as well as
> showing the quarter allocated to SVP64. In all cases, the primary opcode of
> the prefix is 1. For SVP64, the primary opcode of the suffix is always just
> the primary opcode of the underlying instruction, that is not modified.
>
> aside: please use the names from the spec. -- "major opcode" is not a term
> defined in the spec.; assuming you meant "primary opcode", please use that
> term instead since it's unambiguous (or at least has much less ambiguity)
> and is actually defined in the OpenPower ISA spec.

i'm going to need some help interpreting it.  i see page 1350, table
11 and 12 and they are both utterly meaningless... even and especially
when reading page 22 1.6.3.  on its own sections 1.6.3 and 1.6.4 mean
absolutely nothing to me: i find no evidence of 6 bits being
available; in combination with the p1350 table 11 and 12, which refer
to some magic suffix bits 0-5 that have *no defintion* as to where or
what they are it is even less meaningful.

i cannot refer to something by an unambiguous name when it's complete
shite :)  sorry IBM engineers, but it's all nonsense unless it has
something other than terse descriptions.  we know this because we end
up doing it too :)

ok i think i got it.  prefix bits 6-11 are the "deciders" that qualify
the other 32 bits.  so.  taking up the bottom corner(s) of table 12,
"Reserved" space, this makes... 4 bits out of the 6 bits of prefix
bits 6:11 available for use by SV prefix.

gaah ok got it.

which leaves the allocation issue.  there are currently 19 of the
available 6:11 bits taken up by v3.1B.  that means that 16 more is a
whopping *thirty six percent* of space taken up, when IBM may have
been expecting maybe to allocate... what... an average of 2 per year
for the next 30 years?

l.