New VM in progress

Tim Rowledge tim at sumeru.stanford.edu
Sat Dec 8 03:28:22 UTC 2001


In message <0GNZ00AOIO43AT at mta2.srv.hcvlny.cv.net>
          Anthony Hannan <ajh18 at cornell.edu> wrote:

> Tim Rowledge <tim at sumeru.stanford.edu> wrote:
> > Or how about the new VM I'm working on with closures, plugin execution
> > engine, new compiled methods, cleaned up primitive (etc) coding, dumped
> > old junk, etc etc. 
> 
> Hi Tim, how far along are you with block closures.
Oh, nowhere serious. I've managed to dig up various old notes on doing
similar things in the past, all those suggestions (mainly Alan W-B's and
EliotM's) seen on the list over the last while etc. I've been more
occupied with cleaning up prim coding and cleaning out old junk
recently.

> I have put several
> months of work into this and am pretty much done with my implementation.
>  We should share our code.  I just want to clean it up a little more
> before releasing it.
I'd be delighted to see it when you're happy with it. It sounds like you
have really been a happy hacker on this one. I do have some ideas left
over from Interval days about caching important values in contexts
(actual pc addresses etc) to speed up returns without having to have a
separate context cache; mostly the trickery there was to help with the
realtime response capability but I think it might be useful generally.

>  I have made many changes from the compiler to the
> VM.  Here are some highlights:
> 	ParseNodes no longer emit bytecodes directly but now generate an
> IRMethod (Intermediate Representation).
Should be good; EliotM did something like this for VW last year and got
big improvement in overall performance by avoiding the need for those
hybrid contexts that used to cost so much time and complexity.

> while converting old CompiledMethods to new CompiledMethods, and
> converts ContextParts to frames on a process stack.
Sounds like it ought to be easy to merge with the changes I did for the
conversion of methods to regular object from the current mixed byte/oop
monsters there are now.

> 	My new VM understands new bytecodes needed and activates methods on a
> stack instead of in ContextParts. The receiver and args stay on the
> stack where the caller put them and becomes part of the new frame, then
> the method and the previous frame pointer and instructionPointer are
> pushed then temps are reserved, then the framePointer and
> instructionPointer are updated and execution resumes for the new method.
>  The stack is a smalltalk object and when it overflows a new stack is
> started with a link to the previous stack.
This sounds like a really good rework of the stack system used in
BrouHaHa without the C complexity. Excellent prospects.

> 	I am now running the new VM with the new translated image and
> everything works, including the debugger, simulator, and exceptions. 
> The only thing I still need to do is rewrite the decompiler.
So send me the code already!

> 	I have been putting off the finishing touches to work on my own version
> of Modules, where each class is a module but each class also has a
> pointer to other classes it uses and even can specify changes to those
> classes.  I like combining modules and classes since they are so closely
> related and so we don't have two different hierarchy structures.
Please, don't get too distracted by this; Dan has already pretty much
put Henryk's module system in place. Let's live with it awhile before
going down another path in that particular forest. Redundant duplication
of unneccesarily repeated work is unneccessarily redundantly redundant.

tim

-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Machine-independent:  Does not run on any existing machine.





More information about the Squeak-dev mailing list