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