[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 20:59:49 BST 2023


--- Comment #104 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(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

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

therefore hmmm what must be done by the emulator is:

   PC=0x00000 addi r0,r0,N # syscall number
   PC=0x00004 sc LEV=0     # syscall *and effect of sc and rfid* EMULATED
   PC=0x00008 usercode     # ... aaand we are back to after the syscall

strictly speaking some bits of MSR must be set to zero,
it must be as if sc is called then rfid called.

> I also checked that sc test from trap_cases works.
> I tried to adopt the SRR1 and MSR checks there, but the values I got are
> different, no idea why.

ah. right. ok.  the clue is the modifications to SRR1 and MSR made
by the back-to-back sc and rfid.

BUT... to properly check this you have to have a program that
does both an sc and an rfid, hmmm....

but for now you are missing the "updatepcnext" and the return,
but this is still *not* quite correct, see below

> https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;
> h=a31c1b972039ff28c0d4e289e759c93e22bf65ff
> Ideas on SRR1/MSR checks are highly appreciated.

ok i know what to do.

1943     def call(self, name, CHEAT=False):

2056         # Usermode system call emulation
2057         if asmop in ("sc", "scv") and self.syscall is not None
                                       AND NOT CHEAT:
                 # must emulate the effect of sc followed by rfid.
                 self.call(asmop, CHEAT=True)
                 # now do the emulated syscall...
2058             identifier = self.gpr(0)
2059             arguments = map(self.gpr, range(3, 9))
2060             result = self.syscall(identifier, *arguments)
2061             self.gpr.write(3, result, False, self.namespace["XLEN"])
                 # now emulate "return from interrupt"
                 # and we are done here. above, rfid updates pc already

see what's happening there? the sc is performed on a "cheat", which
*runs the sc pseudocode*, then you emulate the syscall, then
pretend that there was an OS that swapped all the context back and
as the last thing, does rfid which we can emulate by *running the
rfid pseudocode*

worst most elegant hack i can think of that gets the job done fast.
otherwise you have to analyse the effect of the sc and rfid pseudocode


to be absolutely honest there's no point when you can just do
self.call("sc") and self.call("rfid")

what i suggest is just to set MSR=0xfffffffffffffff and see what value
it gets set to afterwards.  then use that to work out the "masking"


+        initial_sprs = {'SRR0': 0x12345678, 'SRR1': 0x5678}
+        sim = run_tst(prog, initial_regs,
+            initial_sprs=initial_sprs,
+            use_syscall_emu=True)

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

More information about the libre-soc-bugs mailing list