as we found in bug #794 a way to easily set offsets is needed. that will be similar to svindex, but fitting into SVRM of svshape https://libre-soc.org/openpower/sv/remap/discussion/ binutils spec simulator unit tests, all needed. * instruction spec: DONE * pseudocode DONE * CSV file DONE * fields.txt DONE * sv/trans/svp64.py DONE * unit tests DONE * binutils TODO
notes: offset will need to be signed. the instruction should have a mode where it doesn't change vl or mvl. imho having it be able to enable remap in the same instruction is more important than being able to set matrix modes, it saves an instruction in the common code sequence (the arithmetic operation and elwid will vary): # not actual proposed svshape2 syntax, just to tell you what gets set svshape2 offset=-1, remap=rb, persistant=0 # merged vslideup and alu op, reads 1 byte from end of r63 sv.add/elwid=8 *32, *64, *32 equivalent to: for i in range(vl): regs[32 + i // 8].byte[i % 8] += regs[64 + (i - 1) // 8].byte[(i - 1) % 8]
maybe have a 5-bit field for which remap to enable (in0, in1, in2, out0, out1), and a 2-bit field for which svshape register to overwrite.
there is a gotcha with the instruction database, the entries needed for using two of the SVRM 4-bit field encodings for a new instruction means that *14* lines in the minor_22.csv file are needed: 0000---00011,OP_SVSHAPE 0001---00011,OP_SVSHAPE ... ... which is exactly what was just "fixed" for rlwimi etc. the proper fix therefore is to allow an instruction to match against a *list* of integer patterns, not just one. i will track down the lines in openpower-isa in the next post
(In reply to Jacob Lifshay from comment #1) > notes: offset will need to be signed. this makes me jittery as it is an extra bit. at least 3 bits are needed to be able to offset to a byte within a 64 bit register. now it is 4 bits, they are very precious in SVSTATE. i think there is room. and it makes sense because not all ops are... swap-args. A-B != B-A. > the instruction should have a mode > where it doesn't change vl or mvl. nowhere near enough space to do otherwise. > imho having it be able to enable remap in > the same instruction is more important than being able to set matrix modes, > it saves an instruction in the common code sequence (the arithmetic > operation and elwid will vary): i already came up with something that fits into the existing svshape instruction, and is similar to svindex. both in HDL and encoding (In reply to Jacob Lifshay from comment #2) > maybe have a 5-bit field for which remap to enable (in0, in1, in2, out0, > out1), and a 2-bit field for which svshape register to overwrite. i already have an encoding and implementation for svindex, which can be copied / adapted to make svshape2. see svindex spec. the more similar the instructions are the (a) less work the (b) less HDL the (c) higher the chance of acceptance. adding new highly-strategic instructions like this at such a late stage is pretty risky in so many ways i don't even want to begin listing them. the more they are identical to other REMAP instructions the less risk.
(In reply to Luke Kenneth Casson Leighton from comment #4) > (In reply to Jacob Lifshay from comment #1) > > notes: offset will need to be signed. > > this makes me jittery as it is an extra bit. at least 3 bits are needed > to be able to offset to a byte within a 64 bit register. now it is 4 bits, > they are very precious in SVSTATE. i think there is room. assuming you meant SVSHAPE0-3, not SVSTATE. imho it'd make more sense to just expand SVSHAPE0-3 to 64-bits...we'd want more than i4 for offset, since many instructions can only access every other or every 4th register iirc, so offset should be able to cover the rest of the bytes. also, it just occurred to me we don't need signed offset after all, e.g. if you want offset -2 for bytes, just use offset -2 % 8 = 6 instead and use the previous register in the sv.* instruction. rather than: svshape2 offset=-1, remap=ra sv.add/elwid=8 *32, *64, *32 do: svshape offset=6, remap=ra sv.add/elwid=8 *32, *63, *32 or: svshape offset=14, remap=ra sv.add/elwid=8 *32, *62, *32 # if you can't address every register...
(In reply to Jacob Lifshay from comment #5) > (In reply to Luke Kenneth Casson Leighton from comment #4) > > (In reply to Jacob Lifshay from comment #1) > > > notes: offset will need to be signed. > > > > this makes me jittery as it is an extra bit. at least 3 bits are needed > > to be able to offset to a byte within a 64 bit register. now it is 4 bits, > > they are very precious in SVSTATE. i think there is room. > > assuming you meant SVSHAPE0-3, not SVSTATE. ... yes. > imho it'd make more sense to just expand SVSHAPE0-3 to 64-bits... no, because i kept them very specifically to 32 bit so as to reduce context switch latency. on the TODO list is to merge into 1/2 the number of 64 bit SPRs. > we'd want > more than i4 for offset, since many instructions can only access every other > or every 4th register iirc, so offset should be able to cover the rest of > the bytes. future version. > also, it just occurred to me we don't need signed offset after all, e.g. if > you want offset -2 for bytes, just use offset -2 % 8 = 6 instead and use the > previous register in the sv.* instruction. face-palm moment, of course. i still have 4 bits anyway because of VSX 128-bit registers (quad.prevision, not the SIMD ones) > rather than: > svshape2 offset=-1, remap=ra > sv.add/elwid=8 *32, *64, *32 > > do: > svshape offset=6, remap=ra > sv.add/elwid=8 *32, *63, *32 > > or: > svshape offset=14, remap=ra > sv.add/elwid=8 *32, *62, *32 # if you can't address every register... neat. like it. that fixes the EXTRA2 problem. like it.
added CSV files, fields.txt entries, and stub pseudocode https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=29ea1c07e1632b99c94371cc6da9b181283e7995
add first draft svshape2 pseudocode https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=a448d0bb54913f1f894fb1032a32d159b80804e9
added an "inv" option which only does one dimension. other bits can be added later with an "sv.svshape2" https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=77a4f7104968859385e0b8117ea74041cbe6e436
nope. decided to revert this as the cost is too great. https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=0d7d7b0059cf5835461b5b2e1d9fa2352f8f6d4d
unit test showing how offset works, and explaining how it could be used with operations restricted to EXTRA2 https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=0ae4b42d6f7bcb1fa83f8e62e46578eff2141f10
Since lkcl submitted his RFP, I'm assuming that means it's completed.