Re: What's lacking: a good intermediate form

"Pertti Kellomaki" <pertti.kellomaki@tut.fi> wrote in message
> Tony wrote:
>> I don't want:
>>
>> LLVM lex->LLVM parse->AST->LLVM IL->assembly or machine code for any
>> CPU
>
> And you are not very likely to get it, because there is no such
> thing as "LLVM lex" or "LLVM parse".


I didn't mean it literally like there were those 2 components to be used
that way. I read the tutorial and it showed that with LLVM, one creates the
lexing and parsing code via the LLVM API.


>
>> 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".
>
> So what's wrong with the following?
>
> (your code): lex -> parse -> AST -> LLVM IL
> (LLVM): LLVM IL -> x86 binary


I don't recognize LLVM IL as a standard assembly language and I do
recognize x86 assembly as probably all I'll ever need. I really just
want a nice clean implementation devoid of attempts at generalization.


>
> I think you are still erroneously conflating LLVM with its frontends
> like llvm-gcc and clang.


No. Though I was thinking about that last week when I was talking about the
project timeline.


> It is perfectly possible to utilize LLVM
> as if it were the system's native assembler. Simply make your compiler
> generate a text representation of the IL, and use LLVM's command line
> tools to produce the native executable.


It's a possibility, as I'm not THAT worried about the backend right now and
don't care THAT much how the executable gets built, I think. I'm not sure
what you mean by "text representation of the IL" and wonder if it's about as
difficult as emitting native assembly. I really would prefer an x86 library
of some sort to help generate native assembly over introducing an IL.


Tony

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