LLVM / C--

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

LLVM / C--

Guillaume FORTAINE
Hello,

I would want to know what are the main differences between LLVM and C--. We
need a robust compiler ( or at least the most promising to work on it ) with
these features :

-A GLR parser (use a modified Elkhound as C/C++ front-end):
 
http://www.cs.berkeley.edu/~smcpeak/elkhound/

-Complete the ARM back-end

-To be able to compile a complete Cross Linux from scratch for
arm with uclibc-nptl.

http://trac.cross-lfs.org/milestone/CLFS 3.0.0


I look forward to your answer,

Best Regards,

                        Guillaume

PS : Don't speak me of GCC :)


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM / C--

Chris Lattner
On Wed, 1 Nov 2006, Guillaume FORTAINE wrote:
> I would want to know what are the main differences between LLVM and C--.

In general, C-- is an interesting piece of research code that has little
to do with LLVM anymore.   C--'s strengths are it support for tail calls
and automatic GC (which LLVM supports, but not as well) which are mostly
useful for functional languages.

C--'s weakness is it's incompleteness (missing many major features),
instability/bugginess, poor performance (both time to compile and the
generated code), lack of high-level optimizations, lack of ABI
compatibility with the native tools, lack of C++ frontend support, and the
small size of its community.

In contrast, LLVM is (almost) fully feature-complete in terms of C/C++
language features and GNU extensions, is robust (being used by several
commercial organizations), has leading edge high-level optimizations, is
ABI compatible with the rest of the system, supports C/C++/ObjC, and has a
medium sized community that is growing all the time.

To get a balanced perspective, you should probably ask the C-- people what
they think.

> We need a robust compiler ( or at least the most promising to work on it
> ) with these features :
>
> -A GLR parser (use a modified Elkhound as C/C++ front-end):
>  
> http://www.cs.berkeley.edu/~smcpeak/elkhound/

Neither C-- nor LLVM provide this.  Why do you need a GLR parser
specifically?

> -Complete the ARM back-end

Right.

> -To be able to compile a complete Cross Linux from scratch for
> arm with uclibc-nptl.
>
> http://trac.cross-lfs.org/milestone/CLFS 3.0.0

C-- doesn't have *any* real C or C++ front-end, AFAIK.

-Chris

--
http://nondot.org/sabre/
http://llvm.org/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM / C--

Guillaume FORTAINE
In reply to this post by Guillaume FORTAINE
>Neither C-- nor LLVM provide this.  Why do you need a GLR parser
>specifically?

http://www.cs.berkeley.edu/~smcpeak/elkhound/

Parsing with arbitrary context-free grammars has two key advantages: (1)
unbounded lookahead, and (2) support for ambiguous grammars. Unbounded
lookahead is achieved by allowing multiple potential parses to coexist for as
long as necessary. Similarly, ambiguity is handled by letting potential
parses be coalesced, with special action taken to handle the ambiguous region
of the input. In general, by using the GLR algorithm, Elkhound avoids the
difficulty of trying to make a language grammar fit the LALR(1) restrictions.


http://en.wikipedia.org/wiki/GLR_parser

Advantages
When implemented carefully, the GLR algorithm has the same time complexity as
the CYK algorithm and Earley algorithm -- O(n3). However, GLR carries two
additional important advantages:
The time required to run the algorithm is proportional to the degree of
nondeterminism in the grammar -- on deterministic grammars the GLR algorithm
runs in O(n) time (this is not true of the Earley and CYK algorithms)
The GLR algorithm is "on-line" -- that is, it consumes the input tokens in a
specific order and performs as much work as possible after consuming each
token.
Since most programming languages are deterministic or "almost deterministic",
in practice the GLR algorithm often performs markedly better than others.


In short : to have cutting-edge stuff and to forget bison another GNU tool ...

Best Regards,

                                Guillaume

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM / C--

Chris Lattner
On Wed, 1 Nov 2006, Guillaume FORTAINE wrote:

> In short : to have cutting-edge stuff and to forget bison another GNU
> tool ... Best Regards,

Is your goal to implement a new language, or to implement C++?

-Chris

--
http://nondot.org/sabre/
http://llvm.org/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM / C--

Guillaume FORTAINE
In reply to this post by Guillaume FORTAINE
>C--'s weakness is it's incompleteness (missing many major features),
>instability/bugginess, poor performance (both time to compile and the
>generated code), lack of high-level optimizations, lack of ABI
>compatibility with the native tools, lack of C++ frontend support, and the
>small size of its community.

To quote Tony Hoare :

"premature optimization is the root of all evil."

http://www.acm.org/ubiquity/views/v7i24_fallacy.html

"That would then force us to choose a
versatile target architecture (such as PPC) and minimize
architecture-dependent optimizations."

http://www.cs.ualberta.ca/~pengzhao/open64-devel/msg00205.html

Will we be able to retarget easily LLVM ?

Has it a sense to retarget a compiler ?

Nowadays, this is the holy grail, if not we will not be able to get rid of
legacy architectures ...

For example, here is cutting-edge stuff in the embedded design :

http://www.sandbridgetech.com/sandbridge_solutions.htm

http://www.arc.com/configurablecores/arc700/750.html

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MXC300-30

But when you ask where is the compiler, there is nobody to answer to your
question ... :)

The goal of C--  is to have a multiple language/architecture framework.

Personally, I believe that if we don't follow this philosophy, we will fall
into the GCC game and have a painful retargetable compiler ...

I believe that in the compiler design issues, the main concern will be : What
is our philosophy ?

"In order" or "out of order" :The programmers do/ do not learn to optimise
their algorithms... Who does what ? :)

The secular war ... x86 vs PPC.

Note : For me it's PPC ... :)

And why doesn't LLVM use lcc instead of gcc ?

Best Regards,

                        WIll
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM / C--

Devang Patel


On Nov 1, 2006, at 11:27 AM, Guillaume FORTAINE wrote:

[snips]

> And why doesn't LLVM use lcc instead of gcc ?

I have doubt so let me ask. Do you understand what is LLVM ?

-
Devang
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM / C--

Andrew Lenharth
In reply to this post by Guillaume FORTAINE
On 11/1/06, Guillaume FORTAINE <[hidden email]> wrote:
> >Neither C-- nor LLVM provide this. Why do you need a GLR parser
> >specifically?
>
> Parsing with arbitrary context-free grammars has two key advantages:
>
> In short : to have cutting-edge stuff and to forget bison another GNU tool ...

This doesn't really answer the question.  If you need to get C/C++
into llvm, it would make sense to use the most mature, stable, and
supported tool you can.  In this case that is llvm-gcc.  If what you
need is hacking on languages, do whatever.

Andrew
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM / C--

Bill Wendling
In reply to this post by Guillaume FORTAINE
On 11/1/06, Guillaume FORTAINE <[hidden email]> wrote:

> >C--'s weakness is it's incompleteness (missing many major features),
> >instability/bugginess, poor performance (both time to compile and the
> >generated code), lack of high-level optimizations, lack of ABI
> >compatibility with the native tools, lack of C++ frontend support, and the
> >small size of its community.
>
> To quote Tony Hoare :
>
> "premature optimization is the root of all evil."
>
You are taking that quote out of context. Hoare is refering to people
who try to optimize their code before making sure that it runs
correctly, not an optimizing compiler (such as LLVM). (Of course, if
you don't want optimizations, simply use -O0 on the command line
during compilation.)

> Will we be able to retarget easily LLVM ?
>
> Has it a sense to retarget a compiler ?
>
Yes of course. It supports C, C++, and Objective-C. It also has many
different back-ends: PowerPC, X86, X86-64, Alpha, ARM, etc. And it has
many target-independent optimizations.

> "In order" or "out of order" :The programmers do/ do not learn to optimise
> their algorithms... Who does what ? :)
>
I don't follow...What does this have to do with an optimizing compiler?

> And why doesn't LLVM use lcc instead of gcc ?
>
LCC's front-en is not as full-featured as GCC's front-end. In
particular, it doesn't have C++ or Objective-C support. And, note,
that GCC is *only* used as the front-end (i.e., parser) in LLVM.

-bw
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM / C--

Emil Mikulic
On Wed, Nov 01, 2006 at 12:58:03PM -0800, Bill Wendling wrote:
> On 11/1/06, Guillaume FORTAINE <[hidden email]> wrote:
[...]
> > Will we be able to retarget easily LLVM ?
> >
> > Has it a sense to retarget a compiler ?
> >
> Yes of course. It supports C, C++, and Objective-C.

Don't forget Stacker!  =)
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM / C--

Chris Lattner
In reply to this post by Guillaume FORTAINE
On Wed, 1 Nov 2006, Guillaume FORTAINE wrote:

>> C--'s weakness is it's incompleteness (missing many major features),
>> instability/bugginess, poor performance (both time to compile and the
>> generated code), lack of high-level optimizations, lack of ABI
>> compatibility with the native tools, lack of C++ frontend support, and the
>> small size of its community.
>
> To quote Tony Hoare :

I'm sorry, I think you misunderstood my question.

What are you trying to *accomplish*?

Philosophy is wonderful, all else being equal.  In practice, if you want
to accomplish a particular goal, some approachs are more useful than
others.  Note that, in practice, LLVM lives up to much of the stuff you
cited.

What are you trying to build, and how much of the existing support we have
do you intend to reuse?

-Chris

--
http://nondot.org/sabre/
http://llvm.org/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev