[Libre-soc-dev] opcode allocation pressure

Jacob Lifshay programmerjake at gmail.com
Fri Sep 2 08:16:12 BST 2022


On Thu, Sep 1, 2022 at 4:03 AM Luke Kenneth Casson Leighton
<lkcl at lkcl.net> wrote:
> > looking over the transcendentals encodings, they both have
> > 5 bits set to `///`, which iirc is don't care bits, this seems like a waste,
>
> those kinds of subtle decisions would be down to the IBM Architectural
> Resource (aka "opcode allocator" team) although we can obviously
> make recommendations.

yup, but imho if our recommendations are actually reasonable and don't
waste a huge amount of already limited encoding space unnecessarily,
they'd be more inclined to accept our proposals.

> > we should have those be an `EO` expanded opcode field (where RA would
> > go for single-input instructions) or just part of XO (for 2-in instructions),
> > reducing the number of XO values used by 32x.
>
> the problem is that doing so complicates the decoder as it becomes
> not 2 levels but now 3 levels of MUXing.

Looking through the existing instructions, it seems as though it's
pretty common to ignore RA for X-Form, so I drop my objection for
that.
>
> if you look at the tables i am following the pattern set by the IBM
> Architectural Resource Allocation team, there are already other 2-op
> A-Form instructions which likewise ignore bits 21-25.

If you look through PowerISA v3.1B appendix F, which is all the
instructions sorted by version, you can see that the last instruction
added that reserves half of XO like that was added back in the
original PPC, *every* instruction added since then either uses the
FULL 10-bit XO or takes bits out for actually-used fields, not for
reserved bits. Therefore I think all A-Form instructions we're
proposing should instead be X-Form like fcpsgn and not waste half of
XO:

# 1.6.7 X-FORM
    |0     |6 |7|8|9  |10  |11|12|13  |15|16|17     |20|21    |31  |
    | PO   |   FRT         |   FRA       |   FRB       |   XO |Rc  |


>
> there will be a reason for it.
yup, for the 2-in instructions, the reason was apparently a mistake
for all later versions.

Jacob



More information about the Libre-soc-dev mailing list