[fpc-devel] LLVM Backend?

[Jonas Maebe]

On 11 Nov 2009, at 21:35, Samuel Crow wrote:

>> It's not entirely clear to me yet how you see the result: an FPC  
>> frontend added
>> to the LLVM project, or an LLVM backend added to the FPC project. I  
>> favour the
>> latter, but a lot of what you talk about seems to be about the  
>> former. Or am I
>> misunderstanding things?
>
> I think you are understanding things well.  I'm looking to FPC as a  
> means to an end where having a team member on the Mattathias BASIC  
> team is creating some libraries in Delphi that I want ported to  
> LLVM.  The reason I haven't thought through the Pascal-specific  
> portions of the task is that I am a C++ programmer.
>
> The last time I programmed in Turbo Pascal, Delphi didn't even  
> exist.  My first C programming class in college back in 1994 was on  
> Turbo C++.  I've since gone on to do a lot of stuff in C and a  
> little stuff in C++.  I still have my Turbo Pascal textbook but it's  
> so out-of-date with regards to OOP that it is useless to me.  I am  
> unable to parse half the stuff I see when I look at modern FPC source.

Delphi-style OOP is really quite similar to Java OOP at the heart  
(single inheritance, interfaces, exceptions), with some extra things  
such as properties (http://en.wikipedia.org/wiki/Property_ 
(programming) ) thrown in.

> Perhaps rather than discuss what code we will use from which  
> project, FPC or LLVM, we should be talking about who wants to do  
> what.  If I am to do most of the work, then the packed array of  
> booleans will be implemented with an LLVM bitvector template class  
> on a thin Pascal frontend accessing most of its code through C  
> wrappers of C++.

I think there's a misunderstanding here: I did not mean that the  
compiler uses bitpacked arrays of boolean (I don't think it does), but  
that to-be-compiled Pascal code may contain them. Or do you really  
mean that you would compile such code down to a call to a C routine  
that calls LLVM classes? (so you'd include LLVM-compiler code in the  
compiled binary -- or is LLVM's bitvector code is some support library  
that's always usable for including in compiled client programs?)

> If you do it, we'll be using a Pascal array of packed booleans  
> properly in Pascal and I wouldn't know what difference it would  
> make.  If packed arrays apply to non-boolean types, and I'd be none- 
> the-wiser as to how it worked apart from my 1994-vintage Turbo  
> Pascal programming knowledge and my knowledge of programming in  
> 68020 Assembly.

Bitpacked arrays can indeed be of any ordinal or enumerated type. In  
terms of memory layout and accessing, they're basically identical to  
bitpacked records, just that all fields are exactly the same size.

> As far as code-maintenance is concerned, I favor LLVM code over FPC  
> code because as long as I watch the mailing list and rewrite  
> portions of the code, it will be an out-of-sync version of Pascal  
> that would do what I needed it to do in much the same way as FPC is  
> out-of-sync with my old Amiga computer's backend.  I don't plan on  
> bringing the Amiga backend up-to-date but I do plan on writing a  
> backend for the 680x0 series processors on LLVM for use with  
> Mattathias BASIC.
>
> In summary, herein lies the source of our disagreement:  I want to  
> work in C++ because it is what I know.  You want to work in Pascal  
> because it is what you know.  We need to divide out the work so that  
> we each know what is expected of us.
>
> Does that answer your questions?

Yes, it does, thanks. The main problem I see is that my approach would  
require a lot of initial work from my part (creating the "high level  
code generator" that could call through to LLVM libraries), so
a) you'd be pretty much blocked until that work were finished if you'd  
go with that approach
b) I honestly have no idea how soon I could finish that (or even how  
soon I could seriously get going in doing that)

I'm not sure what you'd need from me to create a complete C++-based  
LLVM code generator for FPC though. The entire parse tree is built  
from Pascal class instances, which have a different internal format to  
C++ class instances. Code generation normally happens via the  
pass_generate_code method of one instance calling that same method of  
its children in the correct order, finally followed by generating the  
code for itself. Simply replacing the body of the various  
pass_generate_code methods with calls to your C wrappers for C++ code  
would not make sense, since these C++ routines would be unable to call  
the relevant Pascal methods to traverse the tree further (i.o.w.,  
you'd have to implement the tree traversal in C++ anyway, so there's  
no use in providing methods that would be used in case the tree were  
traversed via Pascal code).

The only option I immediately see is that you'd need some kind of  
serialised parse tree (and symbol table, and type definitions), which  
you'd de-serialise in your C++ code and then process as you like.  
That's not really a task that gets me jumping up and down with  
excitement though, because I don't see it as something that would be  
really useful in the longer term as far as the FPC project is  
concerned (not to mention that writing serialiser code is simply  
boring work -- there's no full rtti available that could be used to  
automate this).


Jonas