[Libre-soc-bugs] [Bug 238] POWER Compressed Formal Standard writeup

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Mon Nov 30 05:19:45 GMT 2020


--- Comment #111 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Alexandre Oliva from comment #109)
> - "SV Prefix over-rides help provide alternative bitwidths for LD/ST" -> I
> had previously assumed this was an instruction prefix, a little bit like the
> extend-next-insn opcode I'd suggested before.

It is, actually, though we haven't yet figured out if/how it will work with
anything other than 32-bit operations as the base instruction. We did decide
64-bit base instructions won't get SVPrefix versions, since those are mostly
useful for scalar only and we don't want to handle 80/96-bit instructions.
64-bit is the biggest instruction we'll support.

>  Now, I assume it's not.  how
> does that work, then?  I suppose I may have to know it, to estimate
> correctly the compression of these instructions.

SVPrefix is supposed to provide the element width for prefixed instructions
since most instructions don't support 8/16-bit operations (no 8-bit add). Since
load/store instructions *do* provide all of the required element widths (at
least for integer load/store instructions, I don't think Power has f16
load/store, though I'm likely wrong), those bits in the prefix can be reused to
encode things load/store specific such as a strided load. Alternatively we
could require those bits anyway to simplify the decoder.

Currently, there are no defined instructions for compressed 16-bit instructions
using SVPrefix, so that won't yet need to be accounted for. Even when we do
want to start defining smaller-than-64-bit SVPrefix instructions, we don't yet
have any compiled code that uses SVPrefix (since the compiler support is not
yet implemented), so we'd be making an educated guess.

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

More information about the libre-soc-bugs mailing list