Yes, but ...
isn't the state of dc->fsr_qne at translation time irrelevant?
And changing it at translation time (line 4593) is dangerous
(because it pertains to runtime, not translation time); i.e. why
is 0 stored at both translation time (4593) and at runtime (4591)?
I think that the if on line 4583 needs to be a run-time test. But
I get very tangled up in these distinctions. For me, generating a
call to a helper function instead of trying to generate all the
correct logic made it easier to keep straight what was happening.
On 8/16/24 15:05, Richard Henderson
wrote:
On 8/17/24 07:46, Carl Hauser wrote:
OK, I think the problem is the handling of dc->fsr_qne in trans_STDFQ, lines 4583 and 4593 -- the code is evaluating dc->fsr_qne at translation time and not at runtime.
That's what patch 4 does, ensure that the runtime value is available at translation time.
r~
