Re: What's lacking: a good intermediate form

"Tony" <tony@my.net>
Sat, 14 Mar 2009 00:42:59 -0500

          From comp.compilers

Related articles
[31 earlier articles]
Re: What's lacking: a good intermediate form pertti.kellomaki@tut.fi (Pertti Kellomaki) (2009-03-09)
Re: What's lacking: a good intermediate form bobduff@shell01.TheWorld.com (Robert A Duff) (2009-03-10)
Re: What's lacking: a good intermediate form bartc@freeuk.com (Bartc) (2009-03-11)
Re: What's lacking: a good intermediate form tony@my.net (Tony) (2009-03-10)
Re: What's lacking: a good intermediate form pertti.kellomaki@tut.fi (Pertti Kellomaki) (2009-03-12)
Re: What's lacking: a good intermediate form pertti.kellomaki@tut.fi (Pertti Kellomaki) (2009-03-12)
Re: What's lacking: a good intermediate form tony@my.net (Tony) (2009-03-14)
Re: What's lacking: a good intermediate form jon@ffconsultancy.com (Jon Harrop) (2009-03-15)
Re: What's lacking: a good intermediate form jon@ffconsultancy.com (Jon Harrop) (2009-03-15)
| List of all articles for this month |

From: "Tony" <tony@my.net>
Newsgroups: comp.compilers
Date: Sat, 14 Mar 2009 00:42:59 -0500
Organization: at&t http://my.att.net/
References: 09-02-132 09-02-136 09-02-144 09-03-003 09-03-010 09-03-019 09-03-023 09-03-034 09-03-042 09-03-052 09-03-055
Keywords: LLVM
Posted-Date: 14 Mar 2009 19:33:42 EDT

"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



Post a followup to this message

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