[Libre-soc-dev] opcode allocation pressure

[Luke Kenneth Casson Leighton]

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

On Fri, Sep 2, 2022 at 8:16 AM Jacob Lifshay <programmerjake at gmail.com> wrote:
>
> On Thu, Sep 1, 2022 at 4:03 AM Luke Kenneth Casson Leighton
> <lkcl at lkcl.net> wrote:

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

or, they just reject everything based on the quantity.  no, not a joke.

yes go for it,  as we discussed on IRC do try to preserve the patterns,
these are important as they will reduce MUX gates on decode

0b00 exp{something}-minus-one12:02
0b01 log{something}-plus-one12:03
0b10 exp{something}12:03
0b11 log{something}

likewise for sin cos atan

there's an additional pattern in that EXT058 and EXT063 are
*almost* identical but there are some overlaps - i first did
an analysis of the free "columns" (bits 26-30) and you can
see that some of the 2-arg ones don't have identical
5-bit XOs as a result of non-orthogonality between 058 and 063.

and then the cube-root recip-sqrt recip dropped into some
unused entries in the sin/cos/tan group, taking advantage
of the fact that with only 3 entries using 2 bits that's obviously
one spare.

so it all made a lot of sense and it's been completely screwed
by v3.1 prefixed 64-bit operations dropped non-orthogonally
into that same space.

sigh.

anyway do what you can, and don't be limited to trying
to fit everything: we can cut some of the operations entirely
or move them to other major ops, but i'd prefer that didn't
happen.

l.