Ruby Compiler [was Introducing myself and my interest in ruby]

C

Curt Hibbs

Hal said:
Mark,

I like the way you're thinking. I believe the principal reason a Ruby
compiler (or C translator) doesn't exist is simply that no one has
written one.

That being the case, go for it.

Of course, there are a few VM approaches out there (mostly experimental,
I think). There is also an rb2c which may still be in the RAA. (I
believe it was written for Ruby 1.4.x).

Or, how about instead of doing a compiler to emit machine code for some
particular architecture, instead do it to emit byte codes for the Parrot VM?

In other words, join the Cardinal project and help it to forge ahead!

Curt
 
M

Mark Hubbart

Or, how about instead of doing a compiler to emit machine code for some
particular architecture, instead do it to emit byte codes for the
Parrot VM?

In other words, join the Cardinal project and help it to forge ahead!

Well... for me to work on either project, I will have to do a lot of
brushing up on various things :) I have a feeling I won't actually get
around to doing anything for at least a couple months, regardless.

But when I do, I think Cardinal would be a good project for me to pore
over. They would both be parsing Ruby and translating it into,
basically, another language :) Perhaps the C translation could even
build off of work done on cardinal! Parse the tree, then emit either
cardinal bytecode, or C code. So I think helping with the cardinal
project would benefit both projects.

What are the chances of Cardinal having the ability to emit more than
one type of code structure for the tree it parses? Could it possibly
end up pluggable?

--Mark
 
M

Mark

Mark said:
What are the chances of Cardinal having the ability to emit more than
one type of code structure for the tree it parses? Could it possibly
end up pluggable?
It is my intention to do exactly this.

The plan is to write a class that outputs the correct code structure and
to pass an instance of that class into the compiler.

This is necessary since at somepoint the intermediate compiler will be
enhanced so that it can accept an abstract syntax tree and generate the
parrot byte code from that. So at that point it will be very useful to
be able to switch from outputting intermediate compiler code to just
serialising the AST.
 
M

Mark Hubbart

The plan is to write a class that outputs the correct code structure
and to pass an instance of that class into the compiler.

That sounds great! Sounds like I have a lot of reading to do... :)

Great name, btw.

--Mark the other
 
M

Mark

Mark said:
That sounds great! Sounds like I have a lot of reading to do... :)
There's not too much reading to do at the moment, at least on the
Cardinal front. I'm hoping to make a first, preliminary release over the
weekend which will include an overview of the design as it stands ATM.
Great name, btw.
Yes it is :) though credit for it goes to Phil Thomson, who first
started the project.
 
R

Robert Feldt

Mark said:
It is my intention to do exactly this.

The plan is to write a class that outputs the correct code structure
and to pass an instance of that class into the compiler.

This is necessary since at somepoint the intermediate compiler will be
enhanced so that it can accept an abstract syntax tree and generate
the parrot byte code from that. So at that point it will be very
useful to be able to switch from outputting intermediate compiler code
to just serialising the AST.
Concerning this and the discussion about what parser to use I'd say that
what we really need is to decide on a common AST representation for
Ruby. Then we can have different parser front-ends generating the
correct type of AST and have different analysis and code generation
back-ends.

I'd say that in general though it's not the design of this or the
parsing that is the hard part; these things are pretty standard in
CS/compiler construction; the hard part is what kind of run-time support
is needed (and of course how you implement it) for Ruby semantics.

BTW, I have two thesis students working (they'll be starting in 3 weeks
actually) on Ruby compilers, one for compiling to MSIL/CIL and one for
compiling to llvm. Would be great if all these different Ruby compiler
projects could eventually share code although I think it's too early for
that at this point...

On Slang (Smalltalk subset used in Squeak) and related Ruby ideas you
might wanna check out
http://www.ce.chalmers.se/~feldt/ruby/ideas/rubyvm/
and specifically
"SRuby - A Ruby dialect for low-level programming",
http://www.ce.chalmers.se/~feldt/ruby/ideas/rubyvm/sruby.pdf
might be a bit dated now but anyway.

Regards,

Robert Feldt
 
P

Phil Tomson

Well... for me to work on either project, I will have to do a lot of
brushing up on various things :) I have a feeling I won't actually get
around to doing anything for at least a couple months, regardless.

But when I do, I think Cardinal would be a good project for me to pore
over. They would both be parsing Ruby and translating it into,
basically, another language :) Perhaps the C translation could even
build off of work done on cardinal! Parse the tree, then emit either
cardinal bytecode, or C code. So I think helping with the cardinal
project would benefit both projects.

There are several projects that could benefit. I actually think that what
we need is some directed effort put into a Ruby parser (frontend) of some
sort and then other (backend) projects like Cardinal could be plugged in.
It should be a whole other project (some already exist, like Ripper, Ruth,
Rockit, etc.) that is architected in such a way that it's easy to plug in
different backends like:
Cardinal (emits Parrot bytecode)
Ruby2C (emits C code)
Ruby2Java(emits Java)
Ruby2Rite(emits Rite bytecode)
....etc.

What are the chances of Cardinal having the ability to emit more than
one type of code structure for the tree it parses? Could it possibly
end up pluggable?

Why not, there's really not code or architecture to Cardinal yet.
However, I'm proposing that Cardinal just be a 'backend' project
(meaning that given some sort of AST it emits Parrot bytecode) and
that another frontend project be created to actually Parse Ruby. This
frontend project should be architected in such a way that it's easy to
plug in different backends.

It could be that this frontend project already exists (I would tend to
thing so) in the form of Ripper or Ruth or Rockit. We just need to get a
consensus as to which of those projects to direct resources toward.


Phil
 
P

Phil Tomson

Concerning this and the discussion about what parser to use I'd say that
what we really need is to decide on a common AST representation for
Ruby. Then we can have different parser front-ends generating the
correct type of AST and have different analysis and code generation
back-ends.

Yes, quite true.
I'd say that in general though it's not the design of this or the
parsing that is the hard part; these things are pretty standard in
CS/compiler construction; the hard part is what kind of run-time support
is needed (and of course how you implement it) for Ruby semantics.

Right, like how do you deal with eval - it should be doable in the runtime
lib.
BTW, I have two thesis students working (they'll be starting in 3 weeks
actually) on Ruby compilers, one for compiling to MSIL/CIL and one for
compiling to llvm. Would be great if all these different Ruby compiler
projects could eventually share code although I think it's too early for
that at this point...

That's great we've got grad student slaves working on a Ruby compiler ;-)

But seriously, this sounds like a great time to coordinate efforts. I'm
not sure it's too early to do that.

BTW: What's llvm?
On Slang (Smalltalk subset used in Squeak) and related Ruby ideas you
might wanna check out
http://www.ce.chalmers.se/~feldt/ruby/ideas/rubyvm/
and specifically
"SRuby - A Ruby dialect for low-level programming",
http://www.ce.chalmers.se/~feldt/ruby/ideas/rubyvm/sruby.pdf
might be a bit dated now but anyway.


Yup, there's nothing new under the sun.

Phil
 
M

Mark Hubbart

Sounds like I have a lot of reading to do... :)
There's not too much reading to do at the moment, at least on the
Cardinal front. I'm hoping to make a first, preliminary release over
the weekend which will include an overview of the design as it stands
ATM.

Before I have a chance of understanding the project, I'll have to brush
up my C, and read up on VMs and stuff. I don't come from a CS
background, hence many many many gaps in my knowledge. So I do have a
lot of reading to do. :)

--Mark
 
R

Robert Feldt

Phil said:
Yes, quite true.




Right, like how do you deal with eval - it should be doable in the runtime
lib.
Yes, but also the semantics of normal class creation, method additions
etc, what makes Ruby Ruby... ;)
That's great we've got grad student slaves working on a Ruby compiler ;-)
They're mid-level thesis so it's two 10 week projects but yes, basically
you're right ;). The goal is to get two prototypes that covers some
small part of Ruby to show if/how it's feasible to do it. Based on that
one can decide how to proceed.
But seriously, this sounds like a great time to coordinate efforts. I'm
not sure it's too early to do that.
Coordinate by creating common AST format I'd say, the rest is not clear
how much overlap it's going to be imho.
BTW: What's llvm?
http://llvm.cs.uiuc.edu/
Compiler infrastructure with abstract assembly language which they can
generate different machine codes from => we can abstract away from
back-end; if we just generate llvm assembly they take care of the
CPU-specific stuff.

/Robert
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top