On 04 Nov 2008, at 10:56, Michael Schnell wrote:
But OTOH I feel a bit uncomfortable to see yet another intermediate
code (after GCC's "RTL", CLR's (.Net/Mono) "CIL" and FPC's own
stuff) in the game.
GCC's RTL and FPC's node tree representation were never designed as a
generic intermediate layer that you can target from any other
compiler. GCC's RTL also has too little high level information to be
useful when performing whole program optimisation and various advanced
transformations. That's the whole reason why they came up with gimple.
CLR is more high level than LLVM. As mentioned in the main LLVM paper (http://llvm.org/pubs/2004-01-30-CGO-LLVM.ps
):
***
[Smalltalk, Self, Java, CLR]
Note that these systems all represent a program in a much higher (and
language specific) representation than LLVM does. Although this
presents a lot of high-level information to the runtime optimizer, it
also makes it largely impossible for the static compiler to do a
meaningful amount of optimization before runtime. As mentioned in
Section 1.1.2, this requires the runtime optimizer to perform many
mundane optimizations at runtime just to get acceptable code, which
makes aggressive optimizations even more costly.
[...]
Another strength of LLVM is that it does not require a specific object
model, set of exception semantics, or any other high-level language
feature from a front-end. This makes it very flexible, but a set of
inter-language conventions would need tobe defined to allow code
produced by different front-ends to communicate (an LLVM Application
Binary Interface, or ABI).
***
BTW: it is possible to "up-compile" LLVM bitcode into CLR. There even
is a proof-of-concept backend for that, but nobody is interested
enough in that functionality to maintain it (so it doesn't work
anymore).
Jonas
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
