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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
