[Libre-soc-dev] [Libre-soc-isa] next ISA WG RFC

[Jacob Lifshay]

On Mon, Mar 6, 2023, 04:10 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> folks we need to discuss what RFCs should go in next, and plan
> groupings
> https://libre-soc.org/openpower/sv/bitmanip/
>
> my recommendation is to not go above about 5-7 instructions
> per RFC, and to group them.  candidates:
>
> * ternlogi, crternlogi, binlut, crbinlut
>
these are a good choice to submit next with mostly obvious benefit, though
we might be able to squeeze an extra bit out of ternlogi's immediate by
deleting the redundant encodings already covered by li, and, or, xor, mv,
etc. it seems worth trying and seeing how complex that would be. we can
also just decide redundancy is ok and simplicity is worth the extra
encoding bit. maybe that should be an unresolved question that the ISA WG
can answer.

* average-sum-diff and abs-accumulate, useful for AV
>

pretty good, but imho ternlog is more compelling since av insns already
exist in vsx and, without vectorization of some sort, are not very
beneficial

* grevlut, xperm, bitmatrix
>

imho grevlut still has the major problem of using a huge amount of encoding
space for not much benefit, i think it can be greatly simplified while
retaining nearly all the practical benefit, therefore imho it's not ready
for submission. also, it needs grev and bitrev and similar aliases

> * bmask (x86 BMI on steroids) and cprop (carry-propagation)
> * bitmask ops (or/and/xor/get) actually shift operations
>
aren't those just `crand` or `and` and similar? i'm guessing that's not
what you meant, so links please.

> * crweird operations (powerful interchange between GPR and CR)
> * carryless mul/div/mod

these are basically good to go, though imho are less critical so can be
left for later when we need a break from more complex stuff.

> * int/fp mv and mv.swizzle/fmv.swizzle
>
imho int/fp mv/convert should be its own separate rfc without swizzle. imho
int/fp is basically ready, trying to smash it into fewer opcodes is imho a
fool's errand because it just doesn't fit, uses the same amount of encoding
space, and makes it harder to understand.
also imho we might want to do swizzles after submitting at least basic
svp64 subvl support. also imho swizzle might not be ready for submission,
icr reviewing it in detail, so it may need some design tweaks.

>
> transcendentals and the GF groups are a bit big to tackle at
> the moment.
>
> the most obvious priority ones (easiest to justify) would
> be the AV ones. there exist already VSX variants.
>
> thoughts?
>

in summary imho we should next submit int/fp mv/convert (no swizzle for
now) or ternlog & friends.

Jacob