[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 #12 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(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.

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

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.

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