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

Reply via email to