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

[Jacob Lifshay]

On Thu, Dec 3, 2020 at 5:11 PM Luke Kenneth Casson Leighton
<lkcl at lkcl.net> wrote:
>
> 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 :)

A lot of the names may be confusing, but "primary opcode" is much less
so (especially compared to BHRBE), since it refers to a particular
instruction field and is aptly named.

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

Yeah, more or less.

The specification defines 2 groups of 64-bit instructions: those that
are completely new instructions (forms 8LS, 8RR) and those that prefix
existing 32-bit instructions (forms MLS, MRR, and MMIRR -- notice the
M for modified). Table 11 is the suffix primary opcode for the class
of completely new instructions, since the class of prefixed existing
32-bit instructions just uses the standard table of 32-bit
instructions for the suffix -- Table 10.

I created a 3rd group, SVP64 instructions, and allocated it from the
free space in table 12. The section I chose is specifically chosen to
be less likely to be needed since I chose it from the sections that
have the most free space.

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

Umm, by my calculation it uses 16 out of 64 which comes to exactly 25%.

> when IBM may have
> been expecting maybe to allocate... what... an average of 2 per year
> for the next 30 years?

Well, considering they allocated more than 25% already in just the
first version, maybe not.

Jacob