[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