[Libre-soc-dev] next ISA WG RFC
programmerjake at gmail.com
Tue Mar 7 02:28:36 GMT 2023
On Mon, Mar 6, 2023, 10:45 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> On Monday, March 6, 2023, Jacob Lifshay <programmerjake at gmail.com> wrote:
> > On Mon, Mar 6, 2023, 04:10 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> >> folks we need to discuss what RFCs should go in next, and plan
> >> groupings
> >> https://libre-soc.org/openpower/sv/bitmanip/
> >> * 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.
i'll note my comments throughout the full email only apply to the one
bullet list item directly above, here i wasn't asking about bmask or cprop.
> bmset, etc in the bitmanip page.
ah, thx! found them. my only comment is that imho the bit-reversed versions
are likely uncommon enough that using whatever combination of grevi and
bmext or similar that that turns out to be is probably better.
> >> * crweird operations (powerful interchange between GPR and CR)
likewise, no comment on these for now.
>> * 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.
> ack, good assessment.
> >> * int/fp mv and mv.swizzle/fmv.swizzle
> > imho int/fp mv/convert should be its own separate rfc without swizzle.
> ack. yes they are different.
> > imho int/fp is basically ready,
> ah i forgot, it's not ready.
> > trying to smash it into fewer opcodes is imho a fool's errand
> please don't denigrate rational arguments in this way.
> > because it just doesn't fit, uses the same amount of encoding space, and
> makes it harder to understand.
> irrelevant. i have gone over this already am am not repeating
how about waiting to see what it looks like before deciding...
reducing the number of "actual" instructions is critical
> and the absolute top priority.
well, i guess i'll have to try that on a branch and see what people think.
ternlogi is not submitted
> as 256 instructions. please review tom forsyth's video on
this has nothing to do with ternlog afaict.
please can you adjust the spec page to account for that
> otherwise i am forced to do it
yeah, i'll do that in a branch or copy of the file so we can see what it
looks like. please don't merge it until we've all had a chance to decide.
More information about the Libre-soc-dev