[Libre-soc-dev] next ISA WG RFC

[Jacob Lifshay]

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

> 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/

<snip>

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

Jacob