[Libre-soc-bugs] [Bug 911] svshape2 instruction (with offsets)

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Wed Aug 24 20:54:25 BST 2022


https://bugs.libre-soc.org/show_bug.cgi?id=911

--- Comment #4 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


More information about the libre-soc-bugs mailing list