Re: [Lightning] Code patching, context switching

[Sandro Magi]

On Wed, Feb 20, 2008 at 1:56 AM, Paolo Bonzini <address@hidden> wrote:
> > I want to use Lightning for user-level context switching, similar to
>  > GNU Pth.
>
>  Why not use makecontext/swapcontext?  (which is what Pth uses except for
>  signal handling).

Pth uses a whole bunch of different methods, including makecontext and
fiddling with jmp_buf, depending on what's available. makecontext and
friends are more or less deprecated interfaces. An assembly generated
context switch is always going to be faster though, and I believe some
of those calls invoke the kernel, in which case I pretty much lose the
advantage of user-level threads.

>  >  1. There is currently no Lightning equivalent to the x86's 'pusha'
>  > instruction [1], correct?
>  >  2. I assume then that I would have to save all registers by iterating
>  > over JIT_R/V/FPR manually while generating this code. Are there any
>  > registers or other state that aren't accessible via Lightning that
>  > might impact context switching?
>
>  Yes.  On the PowerPC, the argument registers are *not* available to the
>  user, because they are caller-save while GNU lightning always provides
>  the illusion that they are callee-save.

I don't get it. Are you saying that the PPC's entire register file is
not accessible via JIT_R, JIT_V and JIT_FPR? Skimming this intro to
PPC doesn't point out anything immediately wrong with what I'm
proposing due to callee vs caller-save conventions:

http://www.ibm.com/developerworks/linux/library/l-ppc/

I was under the impression that PPC's general purpose register are
truly general purpose, like that article says.  If it's not possible,
how is setjmp/longjmp implemented on PPC? Hmm, just found this library
using portable setjmp fiddling and it supports PPC:

http://www.cs.uiowa.edu/~jones/opsys/threads/

I'm wary of setjmp though, because I've inspected the Windows setjmp.h
header, and it doesn't seem to save the floating point registers on
x86. Anyway, it sounds like you're implying this is a Lightning
limitation, so any clarification is much appreciated. :-)

>  > I can then take the address of ctxt_switch and pass it to Lightning as
>  > the code buffer and patch the contents of ctxt_switch to perform an
>  > actual context switch. The other alternative is to simply patch in a
>  > direct jump at &ctxt_switch into my code generated elsewhere. Any
>  > other thoughts or recommendations?
>
>  I think that the code is readonly on all the platforms I ever looked at
>  that have an MMU.  You would have to use mprotect first; then I think
>  that patching a direct jump is fast enough.
>
>  However, beware the compiler.  It will remove all those pseudo-NOP
>  statements that (it looks like this, at least) you placed to make
>  ctxt_switch big enough.  It might also inline ctxt_switch, which would
>  screw things up a lot.  I would just make ctxt_switch a function pointer.

Yup, I was concerned about inlining, but that's solvable. I don't want
to use a function pointer for the same reason that I'm avoiding CPS:
indirect calls tend to flush the pipeline. It's a weaker argument
here, because the branch predictor will probably cache the target, and
since the target never changes, it should only flush on the first
call, but I don't want to rely on a decent branch predictor.

Sandro