The three things that have been added since the last release are:
* More x86 addressing modes
* Generic primitives (calling out to the interpreter's primitives)
* Eliot's closure bytecodes and Freetype support merged into the VM
More x86 addressing modes and generic primitives have helped out
with performance.
The addressing modes help out in send/return code which accesses
VM variables. Previously the address of the variable had to be loaded
into a register, then that used to access it. Now it can be done in
a single instruction.
Generic primitive support improves the number of cases Exupery
can increase performance. If a primitive is called now that Exupery
doesn't know how to compile, it can now dispatch to it via a PIC which
is much faster than running through the interpreters lookup code.
Eliot's closure bytecodes have been merged in because the Pharo
developers would like to start using them. I'd like to see proper
closure support. At the moment the VM will run closure code but
Exupery will not be able to compile it. That will take another VM
change, and an Exupery compiler change to free up the "unused" slot in
MethodContext.
The subpixel changes to bitblt have been merged into the VM, and
the exupery-dev project on the Universes modified to load the packages
required to build the FreeType plugin. I've got makefiles that work,
they're not ideal but I ran into autoconf/automake issues that
prevented using a better solution.
Also, I think I know what one of the remaining bugs is. When returning
into compiled code from interpreted code the compiled context is not
being marked as a root. Contexts are real objects, and need to keep
the garbage collector book-keeping. Any objects in old space must be
marked as roots if they point to new space. To avoid write barrier
checks on context writes (all stack operations, and temporary
assignments), all contexts are marked as roots if they're in old space
when they're entered. Exupery's code does the marking in the return
bytecode because there are less returns than points to return to.
Every send, or potential send has an entry point, which is much more
than the number of return bytecodes.
Next, I'll investigate this potential bug then fix it if it's real.
Bryce
_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
Locked
