<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 6, 2023, 10:45 Luke Kenneth Casson Leighton <<a href="mailto:lkcl@lkcl.net" target="_blank" rel="noreferrer">lkcl@lkcl.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Monday, March 6, 2023, Jacob Lifshay <<a href="mailto:programmerjake@gmail.com" rel="noreferrer noreferrer" target="_blank">programmerjake@gmail.com</a>> wrote:<br>> On Mon, Mar 6, 2023, 04:10 Luke Kenneth Casson Leighton <<a href="mailto:lkcl@lkcl.net" rel="noreferrer noreferrer" target="_blank">lkcl@lkcl.net</a>> wrote:<br>>><br>>> folks we need to discuss what RFCs should go in next, and plan<br>>> groupings<br>>> <a href="https://libre-soc.org/openpower/sv/bitmanip/" rel="noreferrer noreferrer" target="_blank">https://libre-soc.org/openpower/sv/bitmanip/</a></blockquote></div></div><div dir="auto"><snip></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">>><br>>> * bmask (x86 BMI on steroids) and cprop (carry-propagation)<br>>> * bitmask ops (or/and/xor/get) actually shift operations<br>><br>> aren't those just `crand` or `and` and similar? i'm guessing that's not what you meant, so links please.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>bmset, etc in the bitmanip page.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">>><br>>> * crweird operations (powerful interchange between GPR and CR)<br></blockquote></div></div><div dir="auto">likewise, no comment on these for now.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">>> * carryless mul/div/mod<br>><br>> 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.<br><br>ack, good assessment.<br><br>>><br>>> * int/fp mv and mv.swizzle/fmv.swizzle<br>><br>> imho int/fp mv/convert should be its own separate rfc without swizzle.<br><br>ack. yes they are different.<br><br>>  imho int/fp is basically ready, <br><br>ah i forgot, it's not ready.<br><br>> trying to smash it into fewer opcodes is imho a fool's errand <br><br>please don't denigrate rational arguments in this way.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">k, sorry.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>> because it just doesn't fit, uses the same amount of encoding space, and makes it harder to understand.<br><br>irrelevant. i have gone over this already am am not repeating<br>it.</blockquote></div></div><div dir="auto"><br></div><div dir="auto">how about waiting to see what it looks like before deciding...</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> reducing the number of "actual" instructions is critical<br>and the absolute top priority.</blockquote></div></div><div dir="auto"><br></div><div dir="auto">well, i guess i'll have to try that on a branch and see what people think.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  ternlogi is not submitted<br>as 256 instructions. please review tom forsyth's video on<br>larrabee.</blockquote></div></div><div dir="auto">this has nothing to do with ternlog afaict.</div><div dir="auto"><br></div><div dir="auto"></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">please can you adjust the spec page to account for that<br>otherwise i am forced to do it</blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Jacob</div></div>