Callbacks, simplified.
Andreas Raab
andreas.raab at gmx.de
Tue Jun 6 02:06:44 UTC 2006
Hi Tim -
setjmp/longjmp are probably slow as hell but the real issue is whether
we want to keep changes minimalistic and local (I do) or whether we're
up for some serious rework of other parts (I'm not).
An alternative I have pondered was to give interpret() an argument,
namely a pointer to a variable that external code can set when it's time
to return. This would solve the problem without doing setjmp/longjmp,
BUT it would come at the cost of a pointer-dereferencing and test at
every single bytecode (at the very least at each primitiveResponse but
there are gotchas with that) and would potentially defeat the dispatch
optimization in gnuification.
Knowing you guys (and knowing myself too) those tradeoffs would be
completely unacceptable for the VM in general - if you want to use
callbacks and you're willing to pay a price for that then you really
should pay the price when you use the callback and not elsewhere. That's
why I'm opting for a setjmp/longjmp solution.
Besides, given the simplistic interface if another implementation
becomes available it should be possible to implement an interface as
trivial as the one proposed here. Since the interface doesn't expose
anything about its implementation (e.g., all you get is an opaque
callback ID) it's quite literally up to the VM how it wants to implement
the semantics properly. It could even do this via threading and IPC if
that were of interest.
Cheers,
- Andreas
tim Rowledge wrote:
> Last time I used setjmp/longjmp was probably 1990. Back then it was
> considered a seriously tacky thing to do and a cause of lost
> performance. I think BrouHaHa got non-trivially faster after I beat
> Eliot up to get him to stop using it in the interpreter code.
>
> Is it less of an issue these days?
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Strange OpCodes: TOAC: Turn Off Air Conditioner
>
>
>
More information about the Vm-dev
mailing list