to llvm or not

6.6: summary
. let clang translate hll to llvm,
and let adda take the much smaller step of
transforming adda`hll to clang`hll -- obj'c (which includes plain c) .

5.1: web.addm/what's new with llvm?
The llvm-py is a Python package, consisting of 6 modules,
that wrap over enough LLVM APIs to allow the implementation of
your own compiler/VM backend in pure Python .

. you can extend the llvm
just as you can reach any libraries you want from c .
. this is how Apple`c gives access to concurrency .

5.1: addm/python concurrency is alive despite gil:
something like pypy,
but the emphasis is llvm
not python coded in itself:
. they intend to remove the GIL
and fix the state of multithreading in Python
. We believe this is possible through
the implementation of a more sophisticated
GC system, something like IBM's Recycler
(Bacon et al, 2001).
. here is their comment on
an llvm binding for python:
llvm-py has such wrapper types,
but using Python-defined types
in the core interpreter
is very difficult,
so we'll write our own
. These won't be full wrappers
(leave that to llvm-py)
. Just what's convenient and useful for debugging.
The switch to LLVM
itself isn't solving the
concurrency problem
. That's being solved separately,
by getting rid of the Global Interpreter Lock.

I like the GIL; it makes my life a lot easier
not having to think about
tricky synchronization issues.
I use threads mainly to deal with
blocking I/O,
not to take advantage of multicore processors
(for that, I would use the multiprocessing module
to spawn separate processes).
I can recommend libJIT for its simplicity
and performance (LLVM is overkill):
. just a couple of things
LLVM did not easily support for us:
in .NET and Microsoft CIL
(Common Intermediate Language ECMA-335):
* the whole spectrum of ECMA 335 for
CLR types and operations
* async exception handling
* precise stack marking
* multiple custom call conventions
* fast Just-In-Time compilation
All these features are supported in libJIT.
Also libJIT has been already used
and well tested in real life
in DotGNU Portable.NET Just-In-Time compiler, ILDJIT,
and, moreover, in HornetsEye
where libJIT is integrated with Ruby
to accelerate video and image digital signal processing.
See also
other information about why LLVM is overkill,
from people who have done a lot of research on
JIT compilation:
(Rhys Weatherley (libJIT) vs Chris Lattner (LLVM))
Try to Google for libJIT.
Look for very detailed technical information here:
libJIT is both much easier and much faster than LLVM.