[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
    
    
  
https://bugs.libre-soc.org/show_bug.cgi?id=982
--- 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"
                 self.call("rfid")
                 # and we are done here. above, rfid updates pc already
                 return
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
back-to-back:
https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=openpower/isa/system.mdwn;h=958502d3#l48
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"
effect.
test_syscall.py:
+        initial_sprs = {'SRR0': 0x12345678, 'SRR1': 0x5678}
+        sim = run_tst(prog, initial_regs,
+            initial_sprs=initial_sprs,
             initial_msr=0xffffffffffffffff,
+            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