On Sat, Dec 17, 2022 at 2:21 AM Andreas Schwab <sch...@linux-m68k.org> wrote: > > On Dez 17 2022, Andrew Waterman wrote: > > > On Sat, Dec 17, 2022 at 2:10 AM Andreas Schwab <sch...@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, sch...@linux-m68k.org > GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 > "And now for something completely different."
