[Libre-soc-isa] [Bug 1056] questions and feedback (v2) on OPF RFC ls010

[bugzilla-daemon at libre-soc.org]

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

--- Comment #25 from Paul Mackerras <paulus at ozlabs.org> ---
(In reply to Luke Kenneth Casson Leighton from comment #12)
> (In reply to Paul Mackerras from comment #5)
> > "SVP64 encoding features" section:
> >
> > At this point, what readers need to understand is the following:
> > 
> > * SVP64 instructions are always prefixed (64 bit) instructions.
> 
> there aren't any SVP64 instructions. there *really is* only
> "32-bit Prefix followed by any Scalar 32-bit instruction".
> 
> it is absolutely prohibited to Prefix an UNDEFINED 32-bit word,
> and it is absolutely prohibited to assume that just because
> any given UNDEFINED 32-bit word has a prefix in front of it,
> it can be ALLOCATED a new meaning.

In all of that, I take it that you are talking about the cases where bit 6 of
the SVP64 prefix is 1, or there is no SVP64 prefix. A SVP64 prefix with bit 6
equal to 0 does exactly what you are saying is absolutely prohibited, doesn't
it? In that case the suffix *is* interpreted quite differently from any meaning
it might have without the prefix.

> i go over this in more detail here:
>     https://libre-soc.org/openpower/sv/rfc/ls001/
>     "Example Legal Encodings and RESERVED spaces"
> 
> > * The prefix word controls various aspects of the vectorisation, and is
> > defined below in this section.
> > * The suffix word is either a defined word instruction,
> 
> it is *always* a Defined-word-instruction, where that DWI **MUST**
> have the exact same definition as if it had no prefix at all
> (caveat: bar the niggles on elwidth).

I think it's not just element width, it's also the possiblity of doing multiple
operations, and potentially not doing some or all of them, leaving the
corresponding parts of the destination register unchanged.

> i.e.: all operands MUST NOT change meaning, just because of prefixing
> 
> 
> 
> let us take addi as an example (because of paddi)
> See Public v3.1 I 3.3.9 p76
> 
> here is the operands:
> 
> addi:
> 
>     DWI   : PO=14  RT RA SI
> 
> paddi: 
> 
>     Prefix: PO=1   R     si0
>     Suffix: PO=14  RT RA si1
> 
> here is the RTL:
> 
>     if “addi” then
>         RT ← (RA|0) + EXTS64(SI)
>     if “paddi” & R=0 then
>         RT ← (RA|0) + EXTS64(si0||si1)
>     if “paddi” & R=1 then
>         RT ← CIA + EXTS64(si0||si1)
> 
> 
> what ABSOLUTELY MUST NOT HAPPEN is:
> 
>     else if “sv.addi” then
>         RT ← 55 * (RA|0) + EXTS64(SI) << 5 + 99
> 
> and even more insane and damaging:
> 
>     else if “sv.addi” then # actually redefined as multiply
>         RT ← (RA|0) * EXTS64(SOME_TOTALLY_DIFFERENT_OPERAND)
> 
> it should not really even be necessary to put this into the addi spec:
> 
>     SVPrefix: PO=9  (24-bit RM)
>     Suffix  : PO=14 (RT RA SI)
> 
> why not? *because there is no change*: it is prohibited!
> 
> think about it.  if it was allowed, then even the spec goes
> haywire.  pages and pages of:
> 
>     addi:      {PO14}     DWI addi
>        DWI   : PO=14 (RT RA SI)
> 
>     paddi:            uses {PO1-PO14} but still "addi" (in effect)
>        Prefix: PO=1  ( R si0)
>        Suffix: PO=14 (RT RA si1)
> 
>     sv.somethingelseentirely  {PO9-PO14} conflicts with addi?? WTF????
>        SVPrefix: PO=9  (then 24-bit RM)
>        Suffix  : PO=14 (RT RA differentoperand)     XYZ99-Form
> 
> 
> total nightmare just from a spec-writing perspective,
> as well as damaging Decode.
> 
> the only things you are "allowed" to do is to extend the reg numbers.
> i do appreciate that given that PO1 does in fact "change" immediate
> operands (si0 || si1), flipping from using SI to instead using
> split-field si0-si1, it seems like i am freaking out, but i really
> *really* don't want to hit the Power ISA Spec with 200+ changes
> to the RTL and instruction definitions.

Yeah, neither do I. But the effects of vectorization do have to be completely
and accurately described somewhere.

> if you really really are asking for split fields to be introduced
> for RT, RA, RS, RB, BA, BFA, FRS, FRC, BT (basically everything)
> then i feel the entire suite - over 200 {PO9-DWI}s - should be
> autogenerated.

Sorry, I don't get why you're talking about split fields here. I don't recall
mentioning split fields in this discussion.

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