----- Original Message ----
> From: Jonas Maebe <jonas.ma...@elis.ugent.be>
> To: FPC developers' list <fpc-devel@lists.freepascal.org>
> Sent: Tue, November 10, 2009 3:46:59 PM
> Subject: Re: [fpc-devel] LLVM Backend?
>
>
> On 10 Nov 2009, at 21:35, Samuel Crow wrote:
>
-snip-
> > Do the object-oriented features of FPC require name-demangled C bindings
> rather than the raw C++ name mangling techniques? Reason: If we can call
> C++
> code directly we can invoke the LLVM code generation classes to go directly
> to
> bitcode rather than tinkering with the Assembly parser of LLVM.
>
> We have a C++ name mangler in the compiler, but it's
> a) barely used/tested
> b) only usable for calling regular functions/procedures, not for calling
> methods
> (someone recently started some preliminary work on supporting that though)
>
> In general, the most common way to interface with external C++ libraries is
> indeed via C wrappers.
>
> Directly linking against LLVM (be it via C or C++) would also only seem
> advisable if that API is considered stable. One of the main pluses of FPC is
> that both the compiler and the generated programs are generally very much
> forward and backward compatible. E.g., you can run FPC and FPC-compiled
> binaries
> on any 2.4+ kernel Linux system, with no dependencies on glibc versions or
> anything else. Same goes for Mac OS X: the PPC compiler run on 10.3+, and the
> compiled binaries on 10.2.8+. For Windows it's also similar.
>
> With an LLVM backend, there will obviously be a dependency on LLVM (either as
> a
> library or as an installed tool chain) and hence on its dependencies, but it
> would be nice if we could be compatible with as many different LLVM releases
> as
> possible at the same time (so that people having to stick to an older LLVM
> version for whatever reason can upgrade FPC independently of that). In that
> respect, I don't know to what extent the C++ interface of the LLVM code
> generator is more or less stable than the assembler format (I know that the
> LLVM
> developers reserve the right to break backwards compatibility in the
> assembler
> format only when releasing new major versions).
>
The IRBuilder class http://llvm.org/doxygen/classllvm_1_1IRBuilder.html is as
stable as the instruction set it builds and is maintained as such since it is
used by Clang, LLVM-GCC and other frontends. As noted in other messages on the
list, the LLVM-FPC compiler would be heavily dependent on LLVM and, in turn,
would require newer operating system support for the compiler to run on MacOSX
10.4, for example, (primarily because of the linker and debugger situation on
the earlier models' XCode versions) since that's the earliest that LLVM
supports. I have a 10.3.9-based PowerMac G4 that we could test the resultant
code on, but I'm not holding my breath to think that it will work.
I think the runtime library and frontend parser would be needed more than the
rest of the FPC compiler itself. Most of the backend and intermediate code in
the FPC optimizer would be redundant with LLVM. The reason I'm not afraid to
redo most of the internals of FPC is that I am involved in a compiler project
already and would need to reuse the code for that project also. Before I
noticed that there was an LLVM backend already started for FPC
I was going to take the parser description from the documentation and
start from scratch anyway.
I'm looking forward to the challenges of this project. I hope I haven't scared
you all with my brashness (and yes I am a little crazy also). I'll talk to you
more later.
--Sam Crow
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
