[ruby-talk:10364] Re: RFC: RubyVM (long)

On Fri, 2 Feb 2001, Robert Feldt wrote:

> >From matz description of the next-generation interpreter (hereafter
> called MNG) it seems that his main goal is to address issues I1 and
> I2. He intends to design a bytecode format for Ruby

I'd like to see a draft of the bytecode format description when Matz
writes it.

> Squeak has the following main components:
>   * Smalltalk interpreter written in a subset of Smalltalk (hereafter
>   we call it mSt as in micro Smalltalk) that can be easily compiled to C
>   * Compiler compiling mSt to C written in "full" Smalltalk
>   * Smalltalk libs written in "full" Smalltalk

I basically agree that we should do something like that.

> mSt is a subset of Smalltalk that maps directly onto C
> constructs. It excludes blocks, message sending and even objects.

This I'm not sure I agree with. I don't know how mSt can in any way be
a subset of SmallTalk if it doesn't support the three main elements that
make SmallTalk what it is. I think our equivalent of mSt should be Ruby
itself or a real subset of it.

> 1. RubyVM-Core in C (or even assembler). This is basically MNG,
> possibly with some differences in design.
> 2. RubyVM-Core in (pure) Ruby.

I think #1 is a better for a start. We'll see about #2 when the rest is
done.

> Alternative to compiling mRb to C
> ---------------------------------
> Instead of compiling to C we could compile to native code directly. We
> can probably come up with a nice OO design where code generators for
> different machines can be plugged in but it will probably be more
> difficult to implement the many different optimizations of modern C
> compilers.

If you want to compile to native code you should first compile to C. The
mRb-to-C compiler is much more important than any native-code generators. 
I don't think I want another Self interpreter that runs only on 2
processors. 

> We should probably learn from the fast Self and Smalltalk
> implementations around.

The Self implementation I've tried cannot possibly be described as "fast".
I guess the PowerPC implementation is not up to par with the SPARC
implementation. Is that the case?

> * unboxed floats and long integers (Self only supports 30-bit integers)

Ruby has its Float boxed too, right?

> * arbitrary control flow within a method (Java) (gotos for multiple
> branching) 

This is given you depart from the AST system. Converting to a more
free-form (bytecode) control-flow can hinder some optimizations. OTOH,
some other optimizations are only possible with bytecode. The idea is to
make the AST -> bytecode translation at the right time, not too early, and
not too late. 

matju