Power ISA has moved on to v3.1, and if Draft SVP64 is to be accepted in a future version of Power it must be on the future version (not v3.0). However PO1 (IBM 64-bit Prefixing) is too complex and is excluded from the scope. Only the 32-bit SFFS instructions of Power ISA v3.1 are to be implemented in ISACaller, binutils, and insndb.
instructions these are all Scalar and they are Vectoriseable: simulator & unit tests: * DONE: cntlzdm and trailing (masked) * DONE: cfuge, pextd, pdepd * DONE: brh brw brd - these are actually all covered by grevlut done in bug #1119 * DONE: setbc, setbcr, setnbc etc. done in bug #1123 binutils (whatever steps are necessary for SVP64 support, recent binutils should already support the scalar instructions themselves): * DONE: cntlzdm and trailing (masked) * DONE: cfuge, pextd, pdepd * DONE: brh brw brd - these are actually all covered by grevlut done in bug #1119 * DONE: setbc, setbcr, setnbc etc.
I assume binutils are affected too?
(In reply to Luke Kenneth Casson Leighton from comment #1) > instructions (note, these are all Scalar and they are UnVectoriseable) > > * cfuge, pextd, pdepd > * brh brw brd - these are actually all covered by grevlut > * setbc, setbcr, setnbc etc. these are vectorizable
(In reply to Dmitry Selyutin from comment #2) > I assume binutils are affected too? yes. we should take the opportunity to reorganise SVP64.RM Field and implement PO9 at (roughly) the same time. https://libre-soc.org/openpower/sv/po9_encoding/
(In reply to Jacob Lifshay from comment #3) > (In reply to Luke Kenneth Casson Leighton from comment #1) > > * cfuge, pextd, pdepd > > * brh brw brd - these are actually all covered by grevlut > > * setbc, setbcr, setnbc etc. > > these are vectorizable missed that, good catch, edited comment #1 to match. reg profiles: * p105 cntlzdm cnttzdm cfuged pextd pdepd RA,RS,RB X-Form * p119 brh brw brd RA,RS X-Form * p129 setbc setbcr setnbc setnbcr RT,BI X-Form these are: * GPR 2R GPR 1W * GPR 1R GPR 1W * CR 1R GPR 1W none of these 3 groups alter anything else, no XER or PC or SPRs.
(In reply to Luke Kenneth Casson Leighton from comment #1) > instructions (note, these are all Scalar and they are UnVectoriseable) > > * prefixed ld/store immediate byte thru quad > plbz plhz plha plwz plwa pld plq > pstb psth pstw pstd pstq > plfs plfd pstfs pstfd > * paddi > * pnop - prefixed nop > * prefixed FP load/store immediate all of these according to Public v3.1 p23 Section 1.6.3-4 Book I are strictly Immediate-only operands. the only reg operands are MSK and those are unused by the above instructions. therefore - and this is the important bit - the above instructions do *not* have or require different register profiles from their unprefixed counterparts. all they need is extra immediate fields, and immediates are *not* part of *register* profiles.
I started working on implementing some of these instructions, since there are quite a lot, I made a sub-bug for what I've completed so far, as well as adjusting comment 1 to have a to-do list.
(In reply to Jacob Lifshay from comment #7) > I started working on implementing some of these instructions, since there > are quite a lot, I made a sub-bug for what I've completed so far, as well as > adjusting comment 1 to have a to-do list. good idea. skip EXT1xx entirely please. i have a better way to do paddi (TBD: sv.b)
I'm going through the list of new instructions after v3.0, some instructions you missed that we might be required to implement: * hashst[p]/hashchk[p] * mffsc*/mffsl * slbiag ultravisor instructions: * msgclru/msgsndu * urfid
(In reply to Jacob Lifshay from comment #9) > I'm going through the list of new instructions after v3.0, some instructions > you missed that we might be required to implement: > * hashst[p]/hashchk[p] can't find it. > * mffsc*/mffsl part of v3.0 so goes in the FP set > * slbiag no. not implemented by microwatt ==> "out". > ultravisor instructions: > * msgclru/msgsndu > * urfid again: not implemented by microwatt ==> "out". it took 18 months to get the MMU and caches working. if IBM Research implement hypervisor in microwatt then we stand a reasonable chance of also implementing it.
(In reply to Luke Kenneth Casson Leighton from comment #10) > (In reply to Jacob Lifshay from comment #9) > > I'm going through the list of new instructions after v3.0, some instructions > > you missed that we might be required to implement: > > * hashst[p]/hashchk[p] > > can't find it. it's in v3.1B, which is the pdf you should be using by default... section 3.3.17.2 page 121 (147) > > > * mffsc*/mffsl > > part of v3.0 so goes in the FP set ahh, copied too far when building my sorted list of new insns. > > > * slbiag > > no. not implemented by microwatt ==> "out". well, afaict it's in the base instruction set...so we may be stuck.
(In reply to Jacob Lifshay from comment #11) > it's in v3.1B, which is the pdf you should be using by default... > section 3.3.17.2 page 121 (147) drat, i have a beta copy (v3.1 not v3.1B). there is no section 3.3.17.2. > ahh, copied too far when building my sorted list of new insns. they should be added instead to the "list of FPR" instructions (in the separate bugreport covering "implement FP operations" you'll have to look it up) > well, afaict it's in the base instruction set...so we may be stuck. not doing it. it'll be about 2 years extra work whereas it'll take IBM Research Engineers a couple of months max.
my part (ISACaller simulator and unit tests) of this is done (updated comment #1 to reflect the current state), binutils support is Dmitry's part. so, Luke, can I submit an RFP for my part of this?
(In reply to Jacob Lifshay from comment #13) > so, Luke, can I submit an RFP for my part of this? yes we're all done here shold have been changed to FIXED months ago, doh