[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 #14 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Paul Mackerras from comment #4)

> In this and subsequent paragraphs, you keep hammering on the idea that the
> underlying scalar instruction is (a) a word instruction 

this is mandatory and inviolate, yes.

> and (b) completely unchanged in its behaviour.

except for elwidth-overrides, yes.

it goes like this:

  for i in range(VL):
      {DO_SCALAR_DEFINED_WORD_INSTRUCTION}

where predication would be:

  for i in range(VL):
      if predicate_mask[i]:
          {DO_SCALAR_DEFINED_WORD_INSTRUCTION}

the instruction *hasn't* changed - not in the slightest bit - just because it
is predicated.

> Neither is in fact true. As to the unchanged
> behaviour, it is not clear why that would be so crucially important even if
> it were true.

dramatic simplification of Decode Phase.

> Instead it would be far more helpful to put a complete list of the ways that
> the behaviour of the underlying instruction is (or can be) changed.

strictly-speaking: element-width overrides, and that's it.
that's the *only* change, and that's covered by ls005.xlen.

  for i in range(SVSTATE.VL):
      if PREFIX.elwidth == 8:
          {DO_SCALAR_DEFINED_WORD_INSTRUCTION... BUT @ XLEN=8-bit}
      else if PREFIX.elwidth == 16:
          {DO_SCALAR_DEFINED_WORD_INSTRUCTION... BUT @ XLEN=16-bit}
      else if PREFIX.elwidth == 32:
          {DO_SCALAR_DEFINED_WORD_INSTRUCTION... BUT @ XLEN=32-bit}
      else if PREFIX.elwidth == 64:
          {DO_SCALAR_DEFINED_WORD_INSTRUCTION... BUT @ XLEN=64-bit}

that *still* does not imply that the actual Defined Word Instruction
itself "changed" [became a multiply instead of an add, had access
to other operands, etc.]

the looping *REALLY IS* a completely separate concept from the
{execution-of-the-Defined-Word-Instruction} - it *REALLY IS*
a Sub-Current-Execution-Counter (CIA.SVSTATE)


(strictly-speaking not so for Register numbers, which techincally
 become "split fields" - but i demonstrate here why attempting to
 put those into the actual RTL - of every single damn instruction -
 would be absolute hell
 https://libre-soc.org/openpower/sv/ls010/hypothetical_addi/ )

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