Anthony,

this sounds great! Any timeline?


I've just restarted (after a long pause out of different reasons, one was
your announcement of doing this stuff with a more ambitious approach than
me) my quick&dirty approach (compared with AWB's hints) for doing BCs, but
lost orientation in the VM stuff. Something does not work...

Now I have learned something about the InterpreterSimulator and have been
faced with some tricky problems there. And in the simulator my broken VM
runs and runs and runs...
Besides I've found a bug in the simulator (see previous '[VM][Simulator]
InterpreterSimulator broken?' mail from me), so I don't know how much to
trust it.

My next step would be to apply my VM changes slowly one after each other to
see by trial and error, which is the one leading to the crashes...

Have you used the InterpreterSimulator to test and improve your work?


I have thought, independent of other efforts my work could serve as a
benchmark as a push to *finish* and publish other efforts, since there have
been many announcements, but no code so far...

But it would take months for me to come to an end, since
- I don't know very much about compilers,
- I've started a new - luckily Smalltalk! - job,
- it's really hard stuff.

So if you are short to the end I'd appreciate to see the results as soon as
possible! Then I'm *not* forced to continue working on this and could switch
to higher level programming (for which I want to have BC's)...

I'm very curious about your work! And it *has* to go into the main
distribution, if it works as expected.

Keep up!


Greetings,

Stephan Rudlof



Anthony Hannan 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.  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 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).  An IRMethod represents each
> abstract machine instruction (like PushTemp) as a separate object and
> groups them by basic block.
>         The IRMethod is then analyzed to see which captured temps need to be
> put in holders.  A captured temp is a temporary variable that a block
> references and must stick around after the method in case the block
> sticks around.  Instead of having the block reference the entire home
> context I just give it the temps it needs.  But if either the block or
> method changes it and the other references it later, then I put the temp
> in a holder which the method and block will reference using a new
> bytecode to get and store into the holder.  Most of the time the holder
> is not needed and the block just get a pointer the temp value itself.
>         Once the IRMethod is analyzed and annotated with which temps require
> holders, then the CompiledMethod is generated from it.
>         I've written a version of the SystemTracer that writes the entire image
> while converting old CompiledMethods to new CompiledMethods, and
> converts ContextParts to frames on a process stack.
>         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.
>         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.
>         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.
> Anyway, let me know where you are, and if your working on
> compiler/interpreter stuff right now I will stop what I'm doing, clean
> up what I have, and send it to you.
> 
> Cheers,
> Anthony

-- 
Stephan Rudlof (sr at evolgo.de)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3