[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 11:46:29 GMT 2020
--- Comment #118 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #111)
> > 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
does. SVPrefix *does* provide an elwidth override.
> 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,
unfortunately - and this is why it's in the Compressed spec - there's simply
not enough room to have Compressed halfword and bytelevel LD/ST.
consequently i made the note, "if you want 8/16-bit LD/ST, use SV Prefix
> I don't think Power
> has f16 load/store, though I'm likely wrong),
haven't seen it
> Currently, there are no defined instructions for compressed 16-bit
> instructions using SVPrefix,
that's incorrect... or... it is and it isn't.
SVPrefix is *specifically* designed so that it applies *uniformly* to *any*
instruction with no "interference" between the two (i.e. it is a 1st-phase
therefore, to say "there are no defined instructions for compressed 16-bit
instructions using SVPrefix" is misleading.
*all* Compressed instructions may have SVPrefix applied to them... *WITHOUT*
any "specific definition being applied".
that's the entire point of SVPrefix. therefore, by *defining* a new Compressed
instruction, **AUTOMATICALLY** it **IS** the case that a SV-Compressed version
exists and **IS** defined... [without us actually explicitly defining one]
caveats to that:
1) certain instructions (trap, branch, nop) you simply can't vectorise. ever.
adding an SVPrefix to "trap" makes absolutely no sense and is simply not
2) in the past - multiple times, jacob and i point out every time that it needs
to be a last resort - you have envisaged that certain brownfield encodings of
SVPrefix when applied to certain encodings should be allocated *completely*
different meanings. either
a) bits in the SVPrefix are set that change the meaning of the
instruction (complete new decoder)
b) bits in the *instruction* which, if prefixed, have a completely
c) both of the above
whilst we may in fact have to do that, it should be a route of last resort,
because of the back-interference it causes between phase 1 (length/mode decode)
and phase 2 (actual opcode decode)
3) we have not yet done the register allocation for Compressed, therefore
it makes no sense to do the SVPrefix-Compressed register allocation
in the sense (1) you were correct in that the exception (nonsensical)
SVP-Compressed instructions have not been indentified
in the sense (2) you were correct in that no "last resort"
completely-different-from-what-is-obvious-application of SVP to Compressed
re-encodings have been defined... but only because if you had tried to suggest
any i would have raised a massive red flag / alarm bell
in the sense (3) you are correct because we haven't got that far (register
however in the general sense, giving the impression that SVP-Compressed "does
not exist because it requires every single opcode to be listed as defined",
this is definitely 100% categorically false.
*every* Compressed instruction inherently and automatically and implicitly *is*
SVPrefix-able [except nonsensical caveats such as branch] because that's how
You are receiving this mail because:
You are on the CC list for the bug.
More information about the libre-soc-bugs