[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
Tue Jun 6 15:45:42 BST 2023
https://bugs.libre-soc.org/show_bug.cgi?id=1056
--- Comment #65 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Paul Mackerras from comment #62)
> (In reply to Luke Kenneth Casson Leighton from comment #56)
> >
> > to that end can i suggest doing a trial-run on one single instruction?
> > (i would recommend addi precisely because it is EXT1xx prefixable)
> >
> > edit: made a start
> > https://libre-soc.org/openpower/sv/rfc/ls010/trial_addi/
>
> This has a lot going for it. It doesn't express the looping aspect of
> sv.addi, but that may well be preferable, i.e. we probably want to define
> the looping in the SV chapter and say that the individual instruction
> descriptions just define one iteration.
>
> (I think you need to change 'if "addi" then' in the RTL to 'if "addi" or
> "sv.addi" then'.)
the logical implication then unfortunately being that even non-Vectorized
instructions need "if addeo or sv.addeo" which will get very tedious
and again give the impression there exists a difference between the
two.
the only one(s) actually different RTL are LD/ST-postinc and
Branch-Conditional, and even there bc is a subset of sv.bc,
with certain (new) immediate-operands set to defaults that
are back-compatible to give bc
which hm gives me the wording i need for clarifying "orthogonal
behaviour"
> On that page you say "a danger of even declaring the existence "sv.addi
> RT,RA,SI" is the assumption that it is different from addi RT,RA,SI". People
> don't get to make assumptions about what sv.addi is; you get to define it
> for them. If people have latitude to make assumptions about it then the spec
> is not precise enough.
interesting. this important insight needs to be in the "spec writer's guide".
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the Libre-SOC-ISA
mailing list