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

[bugzilla-daemon at libre-soc.org]

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

--- 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.