Re: What's lacking: a good intermediate form

"Pertti Kellomaki" <pertti.kellomaki@tut.fi> wrote in message
> Tony wrote:
>> I read the tutorial and it showed that with LLVM, one creates the
>> lexing and parsing code via the LLVM API.
>
> Sorry to flog a dead horse, but there must be some confusion.
> I am 100% sure that LLVM does not have an API that deals with
> lexing and parsing. Which tutorial do you mean?


http://llvm.org/docs/tutorial/index.html


I got there from other than the index page and only looked at the code and
not the accompanying text which says:


".Chapter #1: Introduction to the Kaleidoscope language, and the definition
of its Lexer - This shows where we are going and the basic functionality
that we want it to do. In order to make this tutorial maximally
understandable and hackable, we choose to implement everything in C++
instead of using lexer and parser generators. LLVM obviously works just fine
with such tools, feel free to use one if you prefer.
.Chapter #2: Implementing a Parser and AST - With the lexer in place, we can
talk about parsing techniques and basic AST construction. This tutorial
describes recursive descent parsing and operator precedence parsing. Nothing
in Chapters 1 or 2 is LLVM-specific, the code doesn't even link in LLVM at
this point. :)"


Oops, I thought they were using the LLVM API to create the lexer/parser/AST.
Now though, the tutorial deserves another look for potential usefullness as
another simple lexer/parser/AST example. :)


> > 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.
>
> Take the following source file:
>
> -----------------------------
> int f(int x) {
> return x+1;
> }
> -----------------------------
>
> Here is the corresponding textual LLVM IR. If your compiler
> produces something like this in a text file, the LLVM tools
> can take over from there and produce the native binary.
>
> -----------------------------
> ; ModuleID = 'f.bc'
> target datalayout =
> "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32"
> target triple = "i686-pc-linux-gnu"
>
> define i32 @f(i32 %x) nounwind {
> entry:
> %tmp2 = add i32 %x, 1 ; <i32> [#uses=1]
> ret i32 %tmp2
> }
> -----------------------------
>
> To compare, here is the x86 assembly produced from the
> same source. This you can feed to the native assembler
> (and linker) to produce a binary.
>
> -----------------------------
> .file "f.c"
> .text
> .p2align 4,,15
> .globl f
> .type f, @function
> f:
> pushl %ebp
> movl %esp, %ebp
> movl 8(%ebp), %eax
> popl %ebp
> addl $1, %eax
> ret
> .size f, .-f
> .ident "GCC: (GNU) 4.2.4 (Ubuntu 4.2.4-1ubuntu3)"
> .section .note.GNU-stack,"",@progbits
> -----------------------------


I think that "IL as IR" does not extablish enough of an abstraction to
be compelling (but whether something else is possible, I don't
know). That's why I keep focusing on "AST as IR" as better suited for
standardization. The above looks to be doing the UNCOL thing (aka,
"standard assembly language") which I thought had been abandoned many
years ago. I don't see a need to replace native assemblers either.


Tony

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