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@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: TOAC: Turn Off Air Conditioner