Ok, this is the snapshot of my classes concerning asm-generator and VMPointers plugin.
I prefer to see VMPointers in Exupery, because it provides something which is useful for Exupery and for my ASM-Generator - get pointers from VM executable :)
Also, Bryce, see how i added a class into VMMaker. I think you can do same with Exupery and put all methods which changing VM to separate class (instead of Interpreter), and then just add it to list of classes needed to generate interp.c , as i did. This will make code much cleaner and separate your code from other :)
I'm also found that primitives can be implemented directly in interp.c and since Exupery uses modifications to Interpreter class, there is no real need in having extra ExuperyPlugin class. A primitive exported by VM can be called using: <primitive: 'primitivename' module: ''>
sig writes:
I'm also found that primitives can be implemented directly in interp.c and since Exupery uses modifications to Interpreter class, there is no real need in having extra ExuperyPlugin class. A primitive exported by VM can be called using: <primitive: 'primitivename' module: ''>
ExuperyPlugin was created when I initially started integrating Exupery with the VM. Originally, I was hoping to keep most of the changes in ExuperyPlugin with a few small hooks in the Interpreter. That didn't happen.
There is some things that probably should remain in ExuperyPlugin such as the code cache support. Though the PIC support needs some hooks into the GC. I've added a simple hook mechanism for this so the changes here are at least generic.
You're right, much of the code on ExuperyPlugin should just be on Interpreter or replaced by your more generic address getting code (VMPointers).
Where the rest of the code should be is an open question. It would be nice to have generic mechanisms, but some things also need to be performant. For instance, it's silly to make the code to return into compiled code too generic as that will slow down all returns.
Bryce
exupery@lists.squeakfoundation.org