[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 #100 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Dmitry Selyutin from comment #98)

> Ah OK, I begin to understand what you mean. The emulator just routes the
> execution to a well-known address, saving the registers and parts of
> context, right?

saving registers no, swapping MSR->SRR1 and PC->SRR0, and then
setting up MSR to a "known good state suitable for a kernel"... yes.
i just sorted that out - it was a bit of a mess

> And we basically emulate the whole world, kinda like regular
> qemu,

aka qemu-system, yeeees

> and it'll be up to OS run in the emulator to establish the code at
> that address where we jump, is it what you mean?

by running the pseudocode for sc (after compiling to python) just like
any other pseudocode instruction... which i've just had to modify to
get the damn thing to work... yes.

https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=c91aa3ee

> > 
> > so those three lines must go, as they prohibit us from running
> > the "sc" instruction when the simulator is in the same type
> > of mode as "qemu-system".
> 
> Not like that we were able to do it before. :-)

in TestIssuer (the HDL) yes.  ISACaller no, because the Power ISA
spec says, in the pseudocode, "assign MSR to new_value"

   MSR <- new_value

then takes you on a stupid stupid wild goose chase "go to this page"
which then says "go to this other page"

> I kinda had an impression
> from comment #2 that the point of this task was to enable userspace syscall
> emulation.

yeees... but not in the process making it impossible to do the equivalent of
qemu-system! i was not expecting to have to sort out the sc pseudocode
"on-the-fly" but it was important to do so, so that when we come to
doing HDL-vs-ISACaller tests of "sc", ISACaller-in-qemusystem-mode
actually works.

gaah.

https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/test/trap/trap_cases.py;h=32b20125f#l54

you can see, after the sc instruction executes, what the expected
value of MSR, PC, SRR0 and SRR1 should be

  59   # expected results: PC should be at 0xc00 (sc address)
  60   e = ExpectedState(pc=0xc00)
  61   e.intregs[1] = 1
  62   e.sprs['SRR0'] = 4                  # PC to return to: CIA+4
  63   e.sprs['SRR1'] = 0x9000000000022903 # MSR to restore after sc return
  64   e.msr = 0x9000000000000001          # MSR changed to this by sc/trap

> OK, if we still have some work to do, it'd be great to adjust the
> budget: even the works I already completed were somewhat bigger to fit into
> 1000 I have as of now. :-)

yes i know. one for tomorrow.

> > i will write an sc unit test and commit it so that you can run it,
> > and see what i mean ok?
> 
> Sure, that'd be great! Thank you!

done, but i had to revert some code that jacob had added.
you'll need to re-run pywriter and pyfnwriter

jacob can you please take a look as i have absolutely no clue
why copy_assign_rhs was added, it really should not have been,
there are ways to write the pseudocode such that it is not
necessary to do (variable <- [0]*64 is the usual one)

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