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

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=982

--- Comment #110 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Dmitry Selyutin from comment #106)
> (In reply to Luke Kenneth Casson Leighton from comment #104)
> > (In reply to Dmitry Selyutin from comment #102)
> > > I've updated the code logic so that it executes in a common way, except that
> > > we can use emulation if this was desired:
> > > 
> > > https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;
> > > h=c215d24e6a3983e9da525ea04bc710abb605c256
> > 
> > briilliant. so yes, if self.syscalls is not set up, that's perfect.
> > 
> > errr hang on though, you forgot these:
> > 
> >    -                self.update_pc_next()
> >    -                return
> 
> https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/
> decoder/isa/test_syscall.py;h=74b336839ae677be9f25e66a8f3f422d7ef18718;
> hb=a31c1b972039ff28c0d4e289e759c93e22bf65ff#l19
> 
> This is explicitly checked here. The trick is that some code later already
> does it. Also, if we return, we won't execute the pseudocode, which is
> something we want to do.
> 
> > the actual sequence *to be emulated* is (i left out MSR):
> > 
> >    PC=0x00000 addi r0,r0,N # syscall number
> >    PC=0x00004 sc LEV=0     # syscall which causes saving to SRR1/SRR0
> >    PC=0x00C00 ....         # OS starts doing context-switch here
> >    PC=0x00C70 ....         # OS starts doing actual syscall about here
> >    PC=0x00Ce0 ....         # OS starts RESTORING context here
> >    PC=0x00Ce4 rfid         # rfid *RESTORES* SRR1/SRR0 into MSR/PC...
> >    PC=0x00008 usercode     # ... aaand we are back to after the syscall

> Is rfid handled by the kernel? Kinda like sysret/sysexit in x86?

kernel - as in: the above sequence when PC is between 0xc00 and 0xce4... yes.

PC=0x000 USER
PC=0x004 USER
PC=0xc00 KERNEL
...
PC=0xce4 KERNEL
PC=0x008 USER

> 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

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

you have misunderstood.

> This seems to update PC twice, if I'm not mistaken.

not "seems" - *DOES*. please use that sequence (also include the comments).

> > to be absolutely honest there's no point when you can just do
> > self.call("sc") and self.call("rfid")
> 
> Yes, mine impression is the same. After all, emulating system calls is not
> the only thing we have to support in order to emulate user mode; however, I
> feel that the rest is outside of the scope of the changes we initially
> discussed.

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.

> 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.