Why LLVM may be a step forward
Bruce M. Simpson
bms at FreeBSD.org
Thu Jan 15 23:26:02 PST 2009
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"  over GCC in the Robert
Anton Wilson sense of the phrase, and start building tools for it,
 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
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  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.]
There's a co-dependency of  with  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
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
I just hope he doesn't try to stir the tea with my spanners.
More information about the freebsd-current