Simon & Wolfgang:

OK, let me address these as far as I know them from my miniscule research so far:

Global Register Variables -- I'm not sure I understand the point here. LLVM is a... well, a virtual machine. It's not a real target. The LLVM code is then either simulated in a VM (as per, say, Java) or it is further compiled to a native representation. (Or it is JITted, etc.) If it's run in a VM, there is no register anythings. For the rest, well the simplicity of the LLVM format is supposed to make optimisations easier. The experience with the gcc3.34 port seems to bear this out since it supposedly actually generates superior running code to actual GCC3. (I don't know if this is true for GCC4, though.) My guess would be that any half-decent optimiser would spot a global pointer variable that's hit a billion times per second and would mark it as a candidate for register usage. And if it doesn't? It sounds like an optimiser that does just that could be written pretty simply.

The ability to put data next to code -- I'm not exactly sure what you mean by this. Do you mean some kind of inlined data like this kind of psuedo-assembler?

    move r1,mem-whatever
    jmp foo

    mem-data-inline db 1, 2, 3, 4, 5, 6, 7, 8

:foo
    move r2,mem-data-inline
    ...

Tail calls purport to be supported. The wording, however, says that marking a call as "tail", enables tail-call optimisation. I'm not positive what that translates to in practical terms. I'll dig deeper into it. It could be that some kind of back-end optimiser has to be provided to make this work. (This is part of the charm of LLVM in my opinion, though. The ability to relatively easily write such back-ends.)

I'm not sure about the concurrency issues. I'm not sure I understand what you mean here. I'll see what LLVM's ability to cope with "zillions of little stacks" is like, however.

Exception handling: there's an "invoke" primitive (a call, basically, with decorations) and an "unwind" primitive. These are in place specifically for exception-handling purposes. Given that GCC (3 & 4) is a front-end for LLVM, and given that GCC supports exception handling, I'm guessing this works just fine.

Garbage collection has extensive support. Conservative collection is supported without any work required at all. Accurate garbage collection has a whole web page devoted to it: http://llvm.org/docs/GarbageCollection.html The precis:

support is claimed for "compacting semi-space collectors, mark-sweep collectors, generational collectors, and even reference counting implementations";
it provides read and write barrier support;
meta-data association with stack objects is supported.

There is a full API for front-ends to use for garbage collection (detailed on the provided link). Of interest is that the garbage collector seems to be unlinked from the front-end client; you implement a garbage collector (or take another implementation) on the back-end and use it with the generic API provided. How practical this will turn out to be in real life work is, of course, the rub. But it does look like they thought about it at least.

--
Michael T. Richter
Email: ttmrichter@gmail.com, mtr1966@hotpop.com
MSN: ttmrichter@hotmail.com, mtr1966@hotmail.com; YIM: michael_richter_1966; AIM: YanJiahua1966; ICQ: 241960658; Jabber: mtr1966@jabber.cn

"Thanks to the Court's decision, only clean Indians or colored people other than Kaffirs, can now travel in the trams." --Mahatma Gandhi