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

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Sun Jun 4 12:20:04 BST 2023


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

--- Comment #56 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Luke Kenneth Casson Leighton from comment #2)
> a rather annoying quirk showed up: LD/ST-update when changed to EXTRA3
> and used for a linked-list-walking test came across a problem where
> the "normal" check "assert RA!=RT" must now be
> 
>     "assert RA||EXTRA3_bits != RT||EXTRA3_bits"
> 
> with the usual method being to write out a prefix as ".long XXXXX"
> followed by its 32-bit Defined Word (suffix) it will be necessary
> as a temporary workaround to use pysvp64dis and SVP64Asm to bypass this
> check and perform its own.
> 
> this needs to have a corresponding spec update as well as binutils

Paul this comes down to "RA" and "RT" *not* changing "meaning" but
instead... dare i say it... "moving to a different namespace"
(the uniform orthogonal SVP64-RISC-paradigm-namespace)"

if we had to write this up as explicit RTL it would be extremely
dumb, being only an "operand qualification".

    if insn == "sv.ldu" then
       rt <- EXTRA3_PREFIXED(RT, SVRM.EXTRA) # 7-bit
       ra <- EXTRA3_PREFIXED(RA, SVRM.EXTRA) # 7-bit
    else
       rt <- RT                              # 5-bit
       ra <- RA                              # 5-bit

then replace "if RT != RA EXCEPTION()"
with         "if rt != ra EXCEPTION()"

and it looks pretty pointless an exercise, worse it is unnecessary
work after which *the spec is rendered unreadable*!

thus it is much better to have a chapter that defines the
format and operand-maps, and says "apply this namespace as a
uniform transformation"

in this way not even the English Language parts of the Scalar spec
change.

now, would it be useful to have some auto-generated header information
that shows SVP64 Operand Mapping, in the instruction definition?
it is debatable.

* on one hand it will interfere with spec readability due to reducing
  compactness (estimated 1.5 inches of PDF lines *per instruction*)
* on the other it will "make clear" the context of what SVP64 is
  actually about

to that end can i suggest doing a trial-run on one single instruction?
(i would recommend addi precisely because it is EXT1xx prefixable)

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


More information about the Libre-SOC-ISA mailing list