> 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.
Exupery mailing list