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

What about an implementation of Ruby that works in the Java VM?  There are
many projects underway to speed up the JVM using both hardware and VM
software.  Also the JVM will be available on almost every platform.


"Mathieu Bouchard" <[e-mail]> wrote in message
news:Pine.LNX.3.96.1010204231658.31619F-100000@relayer...
>
> 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
>
>