[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: summer of code ideas
From: |
Noah Lavine |
Subject: |
Re: summer of code ideas |
Date: |
Mon, 7 Mar 2011 17:37:22 -0500 |
Hello,
>> We talked about having a Scheme-based language that could compile to
>> both plain C and JIT, but decided that would make the VM too
>> complicated,
>
> Maybe I forgot to feed that thread, but I think it might be easier to
> have a high-level representation the VM opcodes as sexps (possibly a
> subset of Scheme), and then write the C files from that.
>
> Though the main difficulty is to find a sufficiently expressive way to
> write opcodes in.
Oh dear. My impression was that we had decided to use a C parser. If
not, I think the hardest part of making this work would be making the
C output look nice. Libjit and C are such similar languages that
making the translator would be quite simple.
>> I notice that GCC now has the ability to use plugins,
>
> The plug-in API doesn’t allow plug-ins to add new front-ends
> (info "(gccint) Plugins").
Ah, I see. I read their wiki a bit. It does look like using GCC would
be difficult, but I still think it would be worthwhile to do just
because they have such a nice compiler already written. It looks like
what you need to build a frontend is the ability to manipulate GCC's
data structures and the ability to write functions that C code can
call back to. I believe the FFI can do both of these things now (not
that it wouldn't be a pain to fit everything together).
Also, after looking at the MELT project and the Modula-2 frontend, I'd
say they might be receptive to the idea of using a high-level language
to write parts of GCC.
Noah
CPAN for Guile, Andreas Rottmann, 2011/03/07
Re: summer of code ideas, Noah Lavine, 2011/03/07