Re: What's lacking: a good intermediate form

"Max Hailperin" <max@gustavus.edu> wrote in message
> "Tony" <tony@my.net> writes:
> ....
>> I didn't reject LLVM. I was recently at the project website and got
>> the impression that their goals will not be achieved for many
>> years. Vaporware? ...
>> Again though, because LLVM project goals are so lofty, it may not be
>> available in my lifetime...
>
> It is available *now*. Quoting from a prominently placed blurb on the web
> site:
>
> "March 2, 2009: LLVM 2.5 is now available for download!"
>
> Although this is a recent release, versions prior to 2.5 have been
> available for years. Version 1.0 was released in October of 2003.
>
> Moreover, LLVM is not just available *now*, it is in use *now*. Not
> just in student projects (which are probably comparable to your
> goals), but also in real products. Every iPhone is using LLVM.
>
> Because the LLVM project is an ongoing one, there are always goals yet
> ahead -- short term ones that will be addressed in the next release
> (currently 2.6) and loftier ones that may well never be achieved. But
> that has nothing to do with the current status. Version 2.5 is plenty
> good for your purposes.
>
> In the time you have spent writing about LLVM's imagined shortcomings,
> you ought to have been able to try it out. If you actually work on
> your project, and get stuck at some point, I will be happy to help out
> -- a real bargain for you, considering that my students pay thousands
> of dollars for this privilege. But I'm no longer going to engage in a
> hypothetical discussion.


Apparently I've struck a chord by mentioning LLVM rather casually. Oh
well, last time I looked at it, the project had a timeline that made
me dismiss it from any further examination. It's pretty much a moot
point though as LLVM does not fit into the category of being the
compelling IR I was alluding to in my OP. I don't want: my language's
"grammar" specified in LLVM code, lexing, parsing, LLVM IL, front end
written in LLVM's coding style with use of C++ libs and LLVM libs.


I don't want:


        LLVM lex->LLVM parse->AST->LLVM IL->assembly or machine code for any CPU


where the whole process at every stage is LLVM-dependent.


I want:


          lex->parse->AST->x86 assembly or machine code


where lexing and parsing into the prescribed AST is the work of my own
frontend code and the transformation into assembly or machine code is
done by the backend "product".


I just want an IR (specification of an IR and probably a well-defined
AST) and the thing that takes the IR to machine-specific assembly or
machine code without additional intermediary steps. Targeting multiple
platforms is not a goal of mine, nor is interpreting nor is
VM-capability at this time and not doing so is a simplifying
assumption so I want to avoid the large,
everything-and-the-kitchen-sink things along the way also (read the
std C++ library and LLVM). Besides losing control of the whole
language implementation process, using LLVM would mean losing site of
the level of complexity of the language.


I'm looking for something at a stage before any code
generation. Obviously I'm not at this time a big fan of the "IL as IR"
idea and LLVM revolves around the LLVM IL as such. As such, it seems
more like a platform in itself rather than something less than
that. Indeed, it is not that far removed from something like the Java
VM. Indeed, "Low Level Virtual Machine", which is all fine and dandy,
but hardly a solution to what my OP was "asking for". At this stage,
I'm just looking/categorizing/evaluating potentially useful and
compelling "products" within a pretty narrow scope of
functionality. Not to curb the general discussion of what constitutes
a "good" IR and the like though.


Tony

Return to the comp.compilers page.
Search the comp.compilers archives again.