This is the mail archive of the
mailing list for the GCC project.
Re: RTL/tree (from gcc) and Scheme
- From: Per Bothner <per at bothner dot com>
- To: Bradley Lucier <lucier at math dot purdue dot edu>
- Cc: khamenya at mail dot ru, gcc at gcc dot gnu dot org, feeley at iro dot umontreal dot ca
- Date: Wed, 13 Aug 2003 10:55:24 -0700
- Subject: Re: RTL/tree (from gcc) and Scheme
- References: <D37574BA-CD43-11D7-83CB-003065BA681E@math.purdue.edu>
Bradley Lucier wrote:
Well, we may need a new Scheme GCC front-end to compile Scheme to more
efficient code. There could be several areas where new internal support
could be helpful:
1. Generating and using better aliasing information. (Objects on the
heap can't alias objects on the stack, etc.)
That's not a Scheme-specific optimization. It also applies to Java,
for example, and hence also to Scheme-to-Java-bytecodes. Also, a
Scheme-to-C-compiler could use Gcc-specific attributes.
2. Having lighter-weight trampolines and better support for tail
recursion than is available going through C.
3. Having more efficient support for multiple values, a la the paper by
Dybvig and someone else.
Yes. Though again that doesn't require a specific front-end. If you
go via C, you can use a combination of attributes and Gcc __builtin
functions that Ccc could be taught to handle specially. If you go via
bytecodes, Gcc could recognize certain special idioms and classes.
Of course this can be tedious and awkward. On the other hand a
complete Scheme front-end is even more work, and probably requires
more maintainance. I'm just pointing of there are alternatives.
4. Using knowledge of type tags internally (i.e., if all fixnums have
their three lowest bits zeroed, then this knowledge can be used when
indexing vectors, shifting, etc.)
You can take advantage of this to some extent if generating C code.
It is harder when using Java bytecode as an intermediate format.
(Kawa doesn't use type tags. It does pre-allocate "small" integers.)
In the same vein, I don't think people should have stopped developing
C++ compilers after cfront came out.
Weird phrasing: I though cfront (or what led to cfront) was the first
C++ compiler. G++ came later. But I get your point. Of course cfront
was not Free Software, so it wasn't much use if you wanted a Free C++
People can do whatever they want. However, there are very limited
resources for Scheme compilers, and the "market" and developers
for a true Gcc Scheme front-end don't seem to be there. However, it
takes just a few enthusistic developers to make it happen!