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

[Tobias Platen]

On Mon, 2023-03-06 at 10:10 -0800, Jacob Lifshay via Libre-soc-dev
wrote:
> 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/
soon going to have a look at the first 3-5 instructions, others next
week.
> > 
> > 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
> _______________________________________________
> Libre-soc-dev mailing list
> Libre-soc-dev at lists.libre-soc.org
> http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev