Re: [C--] C-- compared to LLVM

On Mon, Sep 07, 2009 at 12:33:48AM +0400, Sergey Shepelev wrote:
> Hello.
> 
> Reading C-- FAQ, i was particularly astonished by these features:
> 
> * Optimized tail calls to any procedure
> * Ways to tie garbage-collection information to particular program points
> * Support for exceptions
> * Support for lightweight concurrency
> 
> These four feel enough to make wanting to write a frontend.
> 
> Main page states that "You might use somebody else's [machine code
> generator]: perhaps VPO, MLRISC, or the gcc back end."
> So, the question is, how LLVM fits in here? I understand that LLVM is
> not really same thing. But it's kinda close, right? They may and are
> used for similar tasks.
> 
> Choosing between C-- and LLVM backend, what would you consider?

I chose C-- over LLVM for several reasons, even though LLVM appears at 
the moment to support more systems (one of which I have in hand).

(1) It's a cleaner language design.  It seems to be based on an analysis 
on what's really needed and what goes well together conoceptually, 
rather than having a kitchen sink as a feature because C has one.

(2) It was designed to work well with a garbage collector.  My front-end 
language, Algol 68, needs this.

(3) LLVM seems to have no mechanism for letting the garbage colector know 
where temporaries are stored.  The result is that you have to make sure 
that all so-called temporaries are explicitly allocated as part of an 
activation record (which you end up explicitly defining) and passing 
pointers to that record explicitly so that when you finally call the 
collector there are explicit chains of pointers to all your activatin 
records, chains that are explicit enough that even an LLVM optimizer can 
see that pointers in those records maight get altered.

Not really a show-stopper, but C-- is much cleaner in this respect.

(4) The remaining consideration are really a feature that LLVM appears 
to have, but restricted in such a way that it ended up being useless. 
I'd much rather use a system that really, fully, orthogonally has a 
limited set of features than one with lop-sided holes in its apparently 
greater functionality.

I can call an LLVM library to build a parse tree in RAM, which LLVM 
can then just compile to machine code, even loading it into RAM along 
the way for immediate execution.  But when I started to use this, I 
discovered that it's not that liberal.  In particular, every type haas 
to be copletely and utterly defined before you can use it in a parse 
tree. For run-time structures whose contents are gradually collected 
from information that comes from many places program, this effectively 
means a two-pass code-generator -- one to build the type definitions, 
and another to generate the ccode that uses them.  While there may be 
some logic in requiring definition before use, there is no sense in 
having to build the parse tree for definitions before the parse tree 
that uses them.

In C-- there is no such feature, and so no danger of being led down the 
garden path.  Instead, I knew that I would have to generate a text file 
and, to the extent that I needed to generate it out of order, I knew 
up-front what evasive actions and clever data structures I'd need to 
use.

(As it happens, the same data structures for out-of-order text-file 
generation would have worked for LLVM if I had generated a text file 
instead of using the LLVM RAM interface for building a parse tree.  But 
unexpected restrictions have made me wary.)

Of course, those decisions were taken about a year ago, and things might 
very well have changed since then.

-- hendrik
_______________________________________________
Cminusminus mailing list
[email protected]
https://www.eecs.harvard.edu/mailman/listinfo/cminusminus