gnupic: Re: [gnupic] LLVM - was Re: [gnupic] gputils development


Previous by date: 15 Nov 2008 20:09:19 -0000 Re: [gnupic] LLVM - was Re: [gnupic] gputils development, Scott Dattalo
Next by date: 15 Nov 2008 20:09:19 -0000 Re: [gnupic] LLVM - was Re: [gnupic] gputils development, Scott Dattalo
Previous in thread: 15 Nov 2008 20:09:19 -0000 Re: [gnupic] LLVM - was Re: [gnupic] gputils development, Scott Dattalo
Next in thread: 15 Nov 2008 20:09:19 -0000 Re: [gnupic] LLVM - was Re: [gnupic] gputils development, Scott Dattalo

Subject: Re: [gnupic] LLVM - was Re: [gnupic] gputils development
From: Ralph Corderoy ####@####.####
Date: 15 Nov 2008 20:09:19 -0000
Message-Id: <20081115200913.7EAED4449@blake.inputplus.co.uk>

Hi Scott,

> Walter Banks wrote:
> > LLVM's approach to standardizing IR doesn't solve this problem.
> 
> As a matter of principal, one cannot disagree. (And any of you who are
> unfamiliar with Walter should know that he is the most experienced PIC
> C-compiler writer on this list... And perhaps the most experienced in
> the world! - his opinion probably weighs in the most on this subject.)

LLVM is more than has been suggested by concentrating on just its IR and
I wouldn't like to see LLVM dismissed lightly.  It seems Microchip, who
should know a thing or two about the awkwardness of targetting the PIC's
architecture, agree.

> Had I stuck with this project, I would have extended pCode to the
> linker. This seems to be the new addition that LLVM brings to the
> table.

It's one.  LLVM is a large beast, but they've tried to avoid it getting
too complex.  The people behind it are academics and researchers who
have battled with gcc internals in the past and know what they dislike
about it.

> Somewhat off topic, but I've been thinking about the concept of
> 'process' lately. Some people seem to think if you have the write
> 'process' in place that the chances of success are increased. But
> ultimately, success hinges on execution. Successful execution depends
> on individuals. And successful individuals seldom need a process for
> guidance. The LLVM framework defines a process for writing compilers.

No, it provides much more than just a framework;  there's real hard work
done in there for you, work which makes adding to it to experiment with
architecture specific issues easier.  It's more than a lexer, parser,
and IR, more than, e.g. the lcc compiler.
http://www.cs.princeton.edu/software/lcc/

> Its success ultimately hinges on those performing the execution...

The people behind LLVM are top-notch, and Chris Lattner has shown he's
able to lead a project, providing clear direction, without preventing
others from making large contributions.  Apple are now providing
corporate backing.  Cutting edge researchers have been attracted to
using it for their experiments.  Yes, I agree, the results of
Microchip's efforts need to be examined, but I suspect there's more
chance of them steadily improving with LLVM compared with, for example,
if they'd used some gcc fork.

Anyway, there's no need to argue amongst ourselves about this.  I just
don't want to see LLVM dismissed lightly before it's been given a few
iterations to see how it copes with the oddities of PIC compared with
its existing targets.  We'd all like better FLOSS PIC C support;  I
happen to think LLVM might help us get there, and have done for some
years.  I was delighted to see a Microchip email address pop up on the
LLVM list some time ago.

Cheers,


Ralph.


Previous by date: 15 Nov 2008 20:09:19 -0000 Re: [gnupic] LLVM - was Re: [gnupic] gputils development, Scott Dattalo
Next by date: 15 Nov 2008 20:09:19 -0000 Re: [gnupic] LLVM - was Re: [gnupic] gputils development, Scott Dattalo
Previous in thread: 15 Nov 2008 20:09:19 -0000 Re: [gnupic] LLVM - was Re: [gnupic] gputils development, Scott Dattalo
Next in thread: 15 Nov 2008 20:09:19 -0000 Re: [gnupic] LLVM - was Re: [gnupic] gputils development, Scott Dattalo


Powered by ezmlm-browse 0.20.