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 .

where is llvm in concurrency? (vid)

. 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:

. some at code.google are doing

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.

python has concurrency via lib's too:

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).

5.1 web.addm/llvm vs c--/news of libJIT starts critique of llvm

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:

http://lists.ximian.com/pipermail/mono-devel-list/2009-April/031640.html

http://lists.gnu.org/archive/html/dotgnu-libjit/2004-05/index.html

(Rhys Weatherley (libJIT) vs Chris Lattner (LLVM))

Try to Google for libJIT.

Look for very detailed technical information here:

http://www.gnu.org/software/dotgnu/libjit-doc/libjit_1.html

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

http://code.google.com/p/libjit-linear-scan-register-allocator/

libJIT is both much easier and much faster than LLVM.