Asm-Generator with VMPointers plugin

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 :)

_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery

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: ''>
_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery

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 mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery