I have read the description of the stack vm again:
http://www.mirandabanda.org/cogblog/2009/01/14/under-cover-contexts-and-the-...
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 debugger).
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.
Cheers, -- Jecel
vm-dev@lists.squeakfoundation.org