[Libre-soc-bugs] [Bug 982] Support PowerPC ABI in ISACaller

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Fri Oct 20 22:42:14 BST 2023


--- Comment #111 from Dmitry Selyutin <ghostmansd at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #110)
> > I don't quite get how trap_cases do it. They have separate tests for rfid,
> > that's true. But I don't see rfid in the sc test case itself...
> that's because i have only just written it.
> https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=9605c45

OK, will check.

> > > but for now you are missing the "updatepcnext" and the return,
> > 
> > See above.
> you have misunderstood.

Then, please, explain _what_ is misunderstood. If I do not return prematurely
then I still get an incremented PC, which is shown by the test. I want the code
to follow the same logic everywhere and avoid custom cases.

> > This seems to update PC twice, if I'm not mistaken.
> not "seems" - *DOES*. please use that sequence (also include the comments).

I see one issue with the sequence you suggest. Even if we're fine with updating
PC twice (and it seems we are, because we have to do rfid anyway), we have a
completely custom sequence, and I don't see a good rationale to have it
customized there.

> no it is not. the scope (goal) has not changed in any way. however i
> had not predicted that the *implementation* would *require* the simulator
> to not only run the full pseudocode of sc but also run the full pseudocode
> of rfid *after* the emulated-syscall as a way to *meet* that goal.

OK, this wording makes it clearer.

> > Sorry, I didn't get it. Do you suggest to check that MSR just got changed
> > from that initial value (assertNotEqual)?
> run the unit test that i have just written, you will then understand what
> is required (which is written out in comment #114).


You are receiving this mail because:
You are on the CC list for the bug.

More information about the libre-soc-bugs mailing list