[Libre-soc-dev] next ISA WG RFC

Jacob Lifshay 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>
> wrote:
> >>
> >> 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.

k, sorry.

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

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

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 mailing list