[Vm-dev] stack vm questions

Jecel Assumpcao Jr jecel at merlintec.com
Wed May 13 22:46:51 UTC 2009

I have read the description of the stack vm again:

> http://www.mirandabanda.org/cogblog/2009/01/14/under-cover-contexts-and-the-big-frame-up/

It seems to me that it would be possible to keep the arguments and the
remaining temporaries together. This would require keeping the numTemps
in the flags word instead of the numArgs. It would also mean moving the
code to nil out the temps towards the beginning of
#internalActivateNewMethod and #activateNewClosureMethod:numArgs:
(before pushing the IP). The idea is that then #temporary:in: would
become simpler, which is important since it is a very popular operation.

This change would make it a little harder to fix the bug in #marryFrame:
but I don't see any other changes that would be needed. Is there some
important design issue with keeping the arguments and temps separate
that I am missing? I can imagine a compiler that avoids initially
filling out the temps with nils by creating them lazily on first
assignment and that wouldn't work with my change. But I don't know if
this is a planned feature (it complicates reflection a bit since you
have to fake the uninitialized temps in order not to confuse the

I found the use of a one byte flag to indicate that the context pointer
is valid interesting since it seems to me that the same information is
available by looking at the pointer itself (nil or not). Is this just a
performance issue or are there situations where the flag can be zero but
the pointer is not nil?

Some small details that seem like errors to me but could be a lack of
understanding on my part:

- the drawing above the definition of "activateNewClosureMethod:
blockClosure numArgs: numArgs" shows the flag word right after fp but
the code indicates that it should be a method pointer instead.

- callersFPOrNull is used in #commonCallerReturn but not assigned to. Ah
- I see that the first definition near the top of the text is
incomplete. The real definition in the discussion about return does have
the assignment.

-- Jecel

More information about the Vm-dev mailing list