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

Discussion in 'Ruby' started by Curt Hibbs, Feb 28, 2004.

  1. Curt Hibbs

    Curt Hibbs Guest

    Hal Fulton wrote:
    >
    > Mark Hubbart wrote:
    >
    > > Indeed, it does :) I wasn't thinking so much of translation to C, but
    > > that would probably be much easier, and would be *much* better

    > than not
    > > having anything. And, it could pave the way for modifying a C compiler
    > > to support the subset. (I hope I'm not being completely naive :)
    > >
    > > If there *was* a compiler, then it would be perfect for projects like
    > > Rubyx and ROS. It would make it so that more people would be able to
    > > participate, since they could leverage their Ruby skills towards the
    > > project.

    >
    > 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
     
    Curt Hibbs, Feb 28, 2004
    #1
    1. Advertising

  2. Curt Hibbs

    Mark Hubbart Guest

    On Feb 27, 2004, at 9:37 PM, Curt Hibbs wrote:

    > 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
     
    Mark Hubbart, Feb 28, 2004
    #2
    1. Advertising

  3. Curt Hibbs

    Mark Guest

    Mark Hubbart wrote:

    >
    > 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.

    --
    Mark Sparshatt
     
    Mark, Feb 28, 2004
    #3
  4. Curt Hibbs

    Mark Hubbart Guest

    On Feb 28, 2004, at 12:36 AM, Mark wrote:

    > 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
     
    Mark Hubbart, Feb 28, 2004
    #4
  5. Curt Hibbs

    Mark Guest

    Mark Hubbart wrote:

    >
    > On Feb 28, 2004, at 12:36 AM, Mark wrote:
    >
    >> 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... :)
    >

    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.

    --
    Mark Sparshatt
     
    Mark, Feb 28, 2004
    #5
  6. Curt Hibbs

    Hal Fulton Guest

    Mark wrote:
    > Mark Hubbart wrote:
    >> Great name, btw.
    >>

    > Yes it is :) though credit for it goes to Phil Thomson, who first
    > started the project.


    Haha... I think he's referring to the name "Mark." :)

    Hal
     
    Hal Fulton, Feb 28, 2004
    #6
  7. Curt Hibbs

    Robert Feldt Guest

    Mark wrote:

    > Mark Hubbart wrote:
    >
    >>
    >> 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.
    >

    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
     
    Robert Feldt, Feb 28, 2004
    #7
  8. Curt Hibbs

    Kent Dahl Guest

    Lyle Johnson wrote:
    > Hal Fulton wrote:
    >> Haha... I think he's referring to the name "Mark." :)

    >
    > Don't be silly, Hal. Why would anyone want to name a Ruby compiler "Mark"?


    Matz' Almighty Ruby Kompiler?

    *ducks*

    --
    (\[ Kent Dahl ]/)_ _~_ _____[ http://www.pvv.org/~kentda/ ]_____/~
    ))\_student_/(( \__d L b__/ Master of Science in Technology )
    ( \__\_õ|õ_/__/ ) _) Industrial economics and technology management (
    \____/_ö_\____/ (____engineering.discipline_=_Computer::Technology___)
     
    Kent Dahl, Feb 28, 2004
    #8
  9. Curt Hibbs

    Phil Tomson Guest

    In article <>,
    Mark Hubbart <> wrote:
    >
    >On Feb 27, 2004, at 9:37 PM, Curt Hibbs wrote:
    >
    >> 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.


    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
     
    Phil Tomson, Feb 28, 2004
    #9
  10. Curt Hibbs

    Phil Tomson Guest

    In article <>,
    Robert Feldt <> wrote:
    >Mark wrote:
    >
    >> Mark Hubbart wrote:
    >>
    >>>
    >>> 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.
    >>

    >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
     
    Phil Tomson, Feb 28, 2004
    #10
  11. Curt Hibbs

    Mark Hubbart Guest

    On Feb 28, 2004, at 2:08 AM, Robert Feldt wrote:
    > "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.


    Fascinating read! It answers several of the questions that I had, and
    points out problems I hadn't thought of. It's giving me lots of food
    for thought. Thanks :)
     
    Mark Hubbart, Feb 29, 2004
    #11
  12. Curt Hibbs

    Mark Hubbart Guest

    >> 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
     
    Mark Hubbart, Feb 29, 2004
    #12
  13. Curt Hibbs

    Robert Feldt Guest

    Phil Tomson wrote:

    >>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.
    >
    >
    >

    Yes, but also the semantics of normal class creation, method additions
    etc, what makes Ruby Ruby... ;)

    >>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 ;-)
    >
    >
    >

    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
     
    Robert Feldt, Feb 29, 2004
    #13
  14. gabriele renzi, Feb 29, 2004
    #14
  15. Curt Hibbs

    Robert Feldt Guest

    Chad Fowler wrote:

    >
    > On Feb 29, 2004, at 3:19 PM, Robert Feldt wrote:
    >
    >>>
    >>>

    >> It was some time since I touched Ruth now but if I remember correctly
    >> it had a fairly complete Ruby AST in there. I propose you at least
    >> check it out...
    >>

    >
    > I'm sure this has appeared earlier in the thread, but I can't find
    > it....where is Ruth currently hosted? I would like to download it.
    > I've been doing some work with Ripper and would like to see your AST
    > format.
    >

    http://www.pronovomundo.com/ruth/

    /R
     
    Robert Feldt, Mar 1, 2004
    #15
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Pete Bleackley

    Introducing myself and my project

    Pete Bleackley, Sep 19, 2006, in forum: VHDL
    Replies:
    3
    Views:
    572
    rickman
    Sep 20, 2006
  2. FSX
    Replies:
    2
    Views:
    332
  3. Larry Felton Johnson

    Introducing myself and my interest in ruby

    Larry Felton Johnson, Feb 20, 2004, in forum: Ruby
    Replies:
    27
    Views:
    290
    Mark Hubbart
    Jun 11, 2004
  4. Curt Hibbs
    Replies:
    1
    Views:
    91
    Mark Hubbart
    May 1, 2004
  5. Curt Hibbs
    Replies:
    0
    Views:
    99
    Curt Hibbs
    Apr 30, 2004
Loading...

Share This Page