[Libre-soc-dev] opcode allocation pressure
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Fri Sep 2 12:28:01 BST 2022
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
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
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.
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
More information about the Libre-soc-dev