[#7055] More on VC++ 2005 — Austin Ziegler <halostatue@...>

Okay. I've got Ruby compiling. I'm attempting to get everything in

17 messages 2006/01/05
[#7058] Re: More on VC++ 2005 — nobuyoshi nakada <nobuyoshi.nakada@...> 2006/01/06

Hi,

[#7084] mathn: ugly warnings — hadmut@... (Hadmut Danisch)

Hi,

22 messages 2006/01/10
[#7097] Re: mathn: ugly warnings — Daniel Berger <Daniel.Berger@...> 2006/01/10

Hadmut Danisch wrote:

[#7098] Design contracts and refactoring (was Re: mathn: ugly warnings) — mathew <meta@...> 2006/01/10

Daniel Berger wrote:

[#7118] Re: Design contracts and refactoring (was Re: mathn: ugly warnings) — mathew <meta@...> 2006/01/12

*Dean Wampler *<deanwampler gmail.com> writes:

[#7226] Fwd: Re: Question about massive API changes — "Sean E. Russell" <ser@...>

Hello,

23 messages 2006/01/28
[#7228] Re: Question about massive API changes — Caleb Tennis <caleb@...> 2006/01/28

>

Re: CRC - a proof-of-concept Ruby compiler

From: Anders Hkersten <chucky@...>
Date: 2006-01-09 18:33:08 UTC
List: ruby-core #7080
tis 2006-01-10 klockan 02:16 +0900 skrev Nicolas Cannasse:
> Anders H旦ckersten wrote:
> > Hello everyone,
> > 
> > During the last few months me and Andreas Farre have been doing our
> > master's thesis on a proof-of-concept compiler for Ruby. The idea is to
> > test how well a language like Ruby can be compiled to C--[1]. We are
> > nearing the end of our thesis and will be focusing most of our remaining
> > time towards writing our report. We would however like feedback on our
> > work from the Ruby community.
> 
> Hello,
> 
> Some people are interested in doing the same thing for Neko 
> (http://nekovm.org). How you would compare the work needed to target 
> Neko against targeting directly x86 bytecode ? What where the difficult 
> point is writing the compiler ? Is there some Ruby Language Reference 
> available somewhere on what you work is based ?
> 
> Best,
> 
> Nicolas

Nicolas,

The focus of C-- is different from that of Neko. C-- is designed as a
portable assembly language. What that means is that we (when writing a
Ruby compiler for C--) write code that targets "x86 C--". In other
words, our code and the C-- compiler can take advantage of knowing that
the underlying machine has certain characteristics. The C-- developers
claim that in theory, generating C-- could lead to perhaps 90-95% the
speed of generating native x86 assembler (unfortunately, current C--
compilers are not that good).

Generating good C-- is also much easier than generating x86 assembly
directly (for example, C-- does register allocation for us). Retargeting
our compiler to another platform than x86 should also be relatively easy
- we just have to rewrite some of the platform specific parts. Of
course, that assumes a C-- compiler is available for the platform we
wish to target.

C-- also provides a very simple runtime system that we hook our own
runtime system (written in a mix of mostly C and some C--) into. This
enables us to do all the dynamic stuff that Ruby needs.

I have not looked extensively at Neko, so most of the following will be
guessing from looking through the specification. I think it should be at
least slightly easier to target Neko than C--, since Neko provides a
much larger existing runtime system to use. I read the discussion you
had on this list a few months ago about Neko with much interest and I
think a Ruby to Neko compiler is a very interesting idea.

The most difficult part of writing our compiler was finding out how
things were supposed to work. The closest thing we have found to a
reference is the "Programming Ruby" book, but it does not go into great
details about the semantics of Ruby. It does however have a very good
description of the object model Ruby uses, as well as an informal
description of all language constructs. This together with experimenting
with the Ruby interpreter gave us a decent picture of how things were
supposed to work, but I'm certain some things are wrong.

This got rather long. I hope I answered all your questions in some
way. :)

All the best,
Anders

Attachments (1)

signature.asc (189 Bytes, application/pgp-signature)

In This Thread