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: [EMAIL PROTECTED], [EMAIL PROTECTED]
MSN: [EMAIL PROTECTED], [EMAIL PROTECTED]; YIM:
michael_richter_1966; AIM: YanJiahua1966; ICQ: 241960658; Jabber:
[EMAIL PROTECTED]
"Thanks to the Court's decision, only clean Indians or colored people
other than Kaffirs, can now travel in the trams." --Mahatma Gandhi
smiley-4.png
Description: PNG image
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
