Collaborating on other kernels/compilers
Brian Mitchell
new Io [0] implementation built on top of Rubinius. I've mentioned
this a few times but have not really announced anything yet because
I've only had time to mess with some new parser implementations and
some other non-Rubinius specific implementation work. I'm getting
closer to the point where I want to start producing real bytecodes
with an early compiler.
I've been watching the construction of compiler2 and I've read the
documents relating to that, but I'm still not sure how to really get
started on this. I've come to the point that a simpler example
compiler might be a better first step. I'd like to try and build a
super simple RPN compiler/runner using Ruby and a custom kernel [1].
If anyone has any pointers that would be appreciated... if anyone
would like to work on this as well, let me know and I'll see about
finding a place to put a git repository [2].
Brian.
[0] Written as Io not IO to denote the language. See iolanguage.com
for more info. Long story short, I think a new implementation would
help Io tremendously.
[1] If anyone can think of a better example language for this I'd be
up for the challenge. Kernel-wise, I'm not sure if we would need
anything for basic arithmetic; I'm sure we can contrive some cool
built-in functions that would belong in the kernel.
[2] I don't plan on placing the Io work directly in the Rubinius repo
if possible. I'd love to figure out how to either wrap Rubinius as a
submodule in another project or inject a small submodule into a branch
off master. I plan on placing all this work under a BSD style license.
Evan Phoenix
On Jan 10, 2008, at 6:16 AM, Brian Mitchell wrote:
>
> Since shortly after RubyConf this year, I've been working on getting a
> new Io [0] implementation built on top of Rubinius. I've mentioned
> this a few times but have not really announced anything yet because
> I've only had time to mess with some new parser implementations and
> some other non-Rubinius specific implementation work. I'm getting
> closer to the point where I want to start producing real bytecodes
> with an early compiler.
>
> I've been watching the construction of compiler2 and I've read the
> documents relating to that, but I'm still not sure how to really get
> started on this. I've come to the point that a simpler example
> compiler might be a better first step. I'd like to try and build a
> super simple RPN compiler/runner using Ruby and a custom kernel [1].
> If anyone has any pointers that would be appreciated... if anyone
> would like to work on this as well, let me know and I'll see about
> finding a place to put a git repository [2].
Well, what is the output from your parser? If you have the output be
sexp's similar to what we have now, you should be able to start just
plugging that output into c2. Thats the simplest route to take.
As for writing a new compiler, it might be useful to work backwards.
Check out CompiledMethod.from_string, then work back to how
Compiler::Generator works.
You could write a very simple compiler by reusing Compiler::Generator,
just calling it's methods to build up the bytecode you want to output,
then calling #to_cmethod to have it do most of the dirty work.
I'd think for Io, the only things you'd use would be send to call a
method, and jump to move to a different piece of code.
Hope that helps!
- Evan
Brian Mitchell
> Well, what is the output from your parser? If you have the output be
> sexp's similar to what we have now, you should be able to start just
> plugging that output into c2. Thats the simplest route to take.
I've got two parsers I want to merge from separate attempts first (I'm
aiming to use a dynamic PEG for parsing -- more on this once I get it
completed). I also need to do some analysis work to get the messages
partitioned into more specific sexps (the AST is too vague about what
constitutes blocks of code since Io enforces none). To get there
shouldn't take long once the merge is done. I'll consider looking at
reusing c2 but I have the gut feeling it won't match up as well for
the sexp structure.
Io's similarity to Ruby happens more on the runtime side (object
interaction) than the syntactical/expression side anyway, which is why
I am more interested in the core VM + some Ruby interop. than sharing
a compiler.
> As for writing a new compiler, it might be useful to work backwards.
> Check out CompiledMethod.from_string, then work back to how
> Compiler::Generator works.
>
> You could write a very simple compiler by reusing Compiler::Generator,
> just calling it's methods to build up the bytecode you want to output,
> then calling #to_cmethod to have it do most of the dirty work.
This sounds more promising. I think I could get more out of this from
experimenting with simple Ruby expressions.
> I'd think for Io, the only things you'd use would be send to call a
> method, and jump to move to a different piece of code.
Almost... Io has some behaviors I need to emulate in regard to things
like local variables, but that should largely compile down to simple
locals bytecodes in many cases. I might also make use of ivars to a
limited extend in keeping internal records for certain types of
objects (there are some crazy things that Object removeAllProtos can
cause).
Concurrency will be another issue to solve. Things like Io's
exceptions will largely depend on this.
Finally, last but not least, Io is a heavy and mean allocator so I
will probably build optimizations around allocation of certain types
of objects, avoiding reification of messages where possible.
> Hope that helps!
I think it will get me started at least. I think I will still start
with a simple compiler for a trivial language and move to Io once I've
understood the generation process a little more in depth.
Brian.
Phil Hagelberg
> [1] If anyone can think of a better example language for this I'd be
> up for the challenge. Kernel-wise, I'm not sure if we would need
> anything for basic arithmetic; I'm sure we can contrive some cool
> built-in functions that would belong in the kernel.
other folks have expressed some interest in getting that to compile to
Rubinius bytecode. I would love to help with that as well, but I'm
fairly clueless as to how that would happen, so I'd need a fair amount
of help too. As it so happens I just finished support for closures
earlier today, and I would love to make compilation the next step.
Repo is up at git://git.caboo.se/bus-scheme.git. Perhaps we can help
each other out.
-Phil
Brian Mitchell
Ah! I do have a local copy of bus scheme. A cool project indeed. It is
probably still a larger project, but if I make any significant
progress in alternative compilers I'd certainly be willing to document
my findings and possibly help start a guide to hosting non-Ruby
languages on Rubinius. Hopefully the closet polyglots can emerge with
some great Ruby interop capabilities with support for things like
Rubinius bytecodes.
Brian.