[LLVMdev] [Oink-devel] Status of Elsa->LLVM

Daniel Wilkerson daniel.wilkerson at gmail.com
Sat Dec 22 20:57:45 PST 2007

On Dec 22, 2007 7:53 PM, Richard Pennington <rich at pennware.com> wrote:
> Daniel Wilkerson wrote:
> >> I've build gcc many times over the years for different target processors
> >> and was never able to get my head around it internally. It is incredibly
> >> complex. I also didn't like the fact that I had to have N copies of gcc
> >> to support N processors.
> >
> > Scott McPeak is rather familiar with the internals of gcc and edg and
> > says elsa is far simpler.
> I agree, very much.

Having the entire Abstract Syntax Tree represented in our own language
(astgen) really helps.

> >> I became interested in Elsa (via google) because I liked its extensible
> >> nature. I can drop in new syntax rules easily. It was also fairly easy
> >> to understand.
> >
> > We worked very hard to make it that way just so people like you can do
> > what you are doing :-).
> You guys did a great job!

You're welcome.

> >> It was easy to lower the Elsa AST to LLVM by using Elsa's extension
> >> capability.
> >
> > I'll be pretty interested to see how you did that.
> You'll see it soon. But basically think about cc2c. There is now a cc2llvm.

We did a lot of work to implement C++ as just a "lowering": re-writing
into a simpler version of the language.  You would have thought that
Stoustrup would have done that, but no, as far as I can tell he did
not.  For example, there are things you can imply in C++ that as far
as I can tell you cannot state explicitly, such as a copy constructor
for an array member.  In some places I think we added to C++ just so
we could do this.  (I say "I think" because sometimes you do something
and then later throw it out.)  Stroustrup did a pretty bad job with
the syntax but we did our best.  The C++ spec is a piece of shit in my
opinion (Scott seems to like it) so there is a lower limit on how
clean of a C++ implementation you can do just because the problem you
are solving is not clean in the first place.

> >> Does Elsa provide an advantage over g++? For me, understanding it is a
> >> big plus. ;-) In addition, Elsa has a Berkeley-like license which I prefer.
> >
> > Read it more carefully: the license is not just BSD-like, it *is* BSD!
> Yes.

I have always been wondering what would happen if someone stuck a code
generator onto Elsa; I think Stallman will not be happy :-).

> >> I'll let you know if Elsa is a good choice after I get a little further
> >> along adding the C++ support.
> >>
> >> Since I only have a few weeks invested in this project, I won't feel too
> >> bad if Elsa turns out to be a dead end.
> >
> > Would you mind explaining what a dead-end would look like?
> A dead end would be something in the C++ part of Elsa that didn't allow
> me to generate a correct LLVM file to execute it and that I couldn't
> fix. If I knew what it looked like, I'd look for it first and decide
> now. ;-)

The language implementation is incomplete in that there are exotic
uses of templates that we do not support.  However the subset of the
language that we do support should admit of a compilation as far as I
can tell as we tried our best to "lower" the C++ everywhere.  Hm, we
never implemented operator new(); oops.


More information about the llvm-dev mailing list