[fpc-devel] Why is FPC so self-contained ?

[Jonas Maebe]

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