[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 #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
elwidth overrides".


> 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
length/mode decode).

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

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
      different meaning
   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

so:

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
allocation)

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

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