Creating new context classes for Exupery

Bryce Kampjes bryce at
Wed Nov 16 22:24:54 UTC 2005

Hi Andreas,
Thanks for the response.

I'm asking two separate questions: The first is to make sure that what
I'm planning will be acceptable for a production release of Squeak
when ready. The second is to get feedback about some design decisions
I'll be making in the next few weeks.

I'm thinking about creating two new contexts. Only the new block
context will be created soon. The new method context is only needed
for inlining which is still a long way off. They will both need to be
compact classes.

I need the new contexts first to quickly check whether they are
interpreted contexts or compiled contexts and second as a place to put
a native machine code program counter. Every context change (send,
return, or block entry) needs to check if it's a compiled or
interpreted context to execute it appropriately. I currently do this
by checking whether the unused slot in a message context is an
integer, it's always an integer for compiled contexts and always a nil
(pointer object) for interpreted contexts. The interpreter uses this
trick to detect if it's a block or message context. There's no unused
slots in block contexts so I'm thinking about creating my own context.

Having my own context objects will provide a place to put image level
support code. Compiled contexts can not be single-stepped so may need
to be deconverted into interpreted contexts while debugging. More
drastic deconversions will be needed after inlining.

There shouldn't be any backwards compatibility issues because the
contexts will have to be removed when the image is saved. They contain
references to natively compiled code which isn't saved with the image.
If they are not cleared out when necessary then the image will crash
if they are entered.

There may be things that I haven't thought about. Dealing with the
interpreter is fairly easy however there is a large amount of
primitive code that could access contexts internals.  I'm assuming
that if I leave the stack pointer and the stack at the same locations
then primitives should just work with Exupery's new contexts. Even
with new context objects, I'll still need to be compatible with any
VM code that may be called.

While I'd like Exupery to eventually be incorporated in the main
production releases, it is being developed with it's own custom
VMs. I'd like to make sure that my decisions now do not cause 
avoidable problems later.


P.S. I'm unable to respond to email until Monday.

More information about the Vm-dev mailing list