Re: [PATCH] RISC-V: Note that __builtin_riscv_pause() implies Xgnuzihintpausestate

[Andrew Waterman <andrew@sifive.com>]

On Sat, Dec 17, 2022 at 2:21 AM Andreas Schwab <schwab@linux-m68k.org> wrote:
>
> On Dez 17 2022, Andrew Waterman wrote:
>
> > On Sat, Dec 17, 2022 at 2:10 AM Andreas Schwab <schwab@linux-m68k.org> wrote:
> >>
> >> On Dez 17 2022, Andrew Waterman wrote:
> >>
> >> > It took me a few minutes to understand the purpose of this chicanery, but
> >> > there's indeed a contradiction in the ISA spec.  HINT instructions _do_
> >> > affect architectural state in a limited fashion--namely, updating the PC.
> >>
> >> How can an insn _not_ affect the PC? (Other than the trivial infinite
> >> loop.)
> >
> > Heh, yeah, that's roughly what I meant by "common-sense reading" (and
> > that's my rationale for simply clarifying the spec and nuking this
> > Xgnuzihintpausestate extension).
>
> My point is that the implicit update of the PC cannot be part of the
> architectural state in the first place.  Even the trivial infinite loop
> has this, before the actual state change (setting PC back) is performed.

It's just a definitional issue.  By analogy, this is why we have the
concept of "explicit memory access" (the thing a load or store is
trying to do) and "implicit memory access" (all of the other memory
accesses, like the instruction fetch or page-table walk).  The PC
update is very much an architectural-state change, but it would be
fair to call it an "implicit architectural-state change" to contrast
with e.g. writing an x-register being an "explicit architectural state
change".

Anyway, I don't think we're disagreeing with each other (and I still
think there's no problem to be solved here).

>
> --
> Andreas Schwab, schwab@linux-m68k.org
> GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
> "And now for something completely different."