[#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: Nicolas Cannasse <ncannasse@...>
Date: 2006-01-10 07:23:47 UTC
List: ruby-core #7093
> 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).
[...]

Hello,

Yes I knew about C-- way of doing things, I just mistake my questions by 
saying "x86 bytecode" instead of "C-- intermediate code" :)

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

There is actually someone that is interested in working on this :
http://lists.motion-twin.com/pipermail/neko/2005-December/000146.html

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

Yes I think too this is an important problem. Did someone already tried 
to extract a complete language specification from the current 
interpreter implementation ? It might be an interesting thing to do, 
since in general this is a good way to understand the language and would 
serve as a base document for compilers.

I don't know so much about Ruby right now, but does the language evolve 
a lot between releases ? (question for everybody)

Nicolas

In This Thread

Prev Next