Why LLVM may be a step forward

Hi,

I'll chime in with my analysis...

Garrett Cooper wrote:
> On Sun, Jan 11, 2009 at 4:31 PM, Eitan Adler <eitanadlerlist_at_gmail.com> wrote:
>   
>> I never took care about GPLv2 and v3
>>     
>>> differences but know, this seems to come to relevance in some way.
>>>       
>> I don't seem to understand this.  Why should gpl v3 affect the OS?  The
>> output of the compiler isn't affected by the license.  Is it?
>>     
>
> Yes the GPLv3 is `extremely viral' when dealing with proprietary
> innovations and features, compared to GPLv2. Hence that's why Apple,
> Cisco, Intel, Juniper, etc are incredibly wary of licensing, and are
> sidestepping around the whole GPLv3 issue as much as possible,
> wherever possible.

Why LLVM is new

   I believe based on the data to hand re LLVM, that we are actually 
seeing 2 major advances over GCC in compiler design.  LLVM, like GCC, is 
freely available open-source software, so there is much greater chance 
these things will take seed across the world.

   The market dominators already realise the compiler market is devalued 
in terms of profit opportunity -- it's infrastructural monopoly, and I 
wonder how the heck M$ still manage to profit from Visual Studio (hint: 
support network and maintenance, same as open source).

   But because of the need for innovation, and the licensing limitations 
of the GPLv3, LLVM is going to get attention. The smart kids out there 
will realise LLVM is an erm, "paradigm shift" [1] over GCC in the Robert 
Anton Wilson sense of the phrase,  and start building tools for it, 
fingers crossed.

[1] RAW described the phenomenon of "paradigm shift" in terms of waiting 
for a current generation of scientific dogma-followers to die off before 
a new, testable *and* experience-able theroem about reality could be 
shared with all other humans. A bit cutting, but sometimes we have to be 
to administer the medicine!

   The other big driver for LLVM is the fact that the GPL version 3 is 
being pushed. LLVM offers a non-encumbering alternative.


But more on those 2 major, mutally dependent, advances in LLVM:

1. Traceability in translation.

The fact that the same LLVM compiler can build both the native objects 
(i386 ELF in this instance) and its own low-level representation of that 
in LLVM-space, means you have a direct chain of causality, and 
traceability, back to the compiler front-end which was responsible 
building the meta-models of the C++ code, for translation, at t = 0.

If you needed to map a symbol in either translation (object vs LLVM) 
back to the C++ code, you can do that, with the appropriate markers. 
Doug Hofstader probably has some nice mathematics for this.

This is going to make a big difference to their time/people costs re 
maintaining LLVM just in simple, shop-floor, "dirty hands" engineering 
terms.


2. Transparency in translation.

   Whilst gcc does compile to its own intermediate representation, this 
has never been a "lingua franca" for optimization tools to communicate 
-- e.g. you can't simulate L2 cache fetches easily from it, or do 
coverage analysis. The job of intermediate representation is limited -- 
it is oriented towards the GNU assembler only, and only for the 
generation, not the analysis, of code in the higher level language 
you're working in.

   LLVM changes this, by making it possible to translate source to LLVM 
bit-code, a transparent representation which in [1] you can trace 
directly back to the original C++ source code.

[Note: Whilst you can probably do these two things with GCC, you can't 
do them out of the box, and that is where LLVM scores points.]

Strange loop

   There's a co-dependency of [1] with [2] here. Transparency in 
translation only becomes useful if you can trace the product back to the 
source. And on the other hand, traceability in translation is only truly 
possible if you have a *transparent* and easily understood 
representation which analysis tools can use too.

I wager this "strange loop" of improved compiler software, originates 
from something which process engineers e.g. in agriculture and the food 
sciences have understood for years -- and an isolated example of where 
engineering in the physical world, can lead to better engineering in the 
virtual world.

   e.g.: mass producing food for safe consumption depends on 
traceability -- and the "sweet spot" temperature for any unwanted 
bacteria doesn't generally change, thus making the measurement of 
whatever is going on transparent -- you measure temperature of your mix, 
e.g. for soft cheese, at all stages in the production process.

   If you apply the same reasoning to compiling software in a high-level 
language, you end up with LLVM.

   Makes me wonder what the characters really are in LLVM, and if they 
are in any way involved in the Food Hacking movement.

Gweeds has recently been attempting to combine programming with food 
science:
   http://www.foodhacking.com/

I just hope he doesn't try to stir the tea with my spanners.

later
BMS