On 10 Nov 2009, at 21:35, Samuel Crow wrote:
The current way to implement pointer arithmetic in LLVM is to use an
i64 for all instances of pointers
We can't do that at the high level, since then all pointer fields in
records etc would become 64 bit. And the low level currently assumes
that register sizes are the same as the pointer size. I have started
in the past at trying to break these assumptions, but it's not
straightforward.
and then bitcast them to and from the correct pointer type when they
are needed as actual pointers and then use the GetElementPointer
operation to do the pointer-specific addressing modes.
Somehow, we have to integrate the high level type information in the
assembler instructions though. For example when doing a function call,
you have no choice but to use the real high level function types,
otherwise LLVM can't know how to pass the parameters (e.g. record/
struct by value). This requires changes in all code generators for all
platforms if we want to keep using the same code generator abstraction
for everything (which I would very much prefer -- we currently
maintain 6 different code generators with maybe 3 or 4 people, and
that's only possible because so much is shared and generic).
If the 64-bit int is bigger than what is needed to hold a pointer
and all uses are bitcast to pointers, the LLVM optimizer figures
that out and down-converts it to 32-bits. It's messy but it works.
There is a proposal to make a new primitive type to represent the
pointer-sized integer being circulated on the LLVM-Developer mailing
list right now so we'll see if anything comes of it.
Yes, I saw that (although I'm 8000+ mails behind on the llvm-dev list :)
Considering that LLVM generates code according to the specified
alignment characteristics given on one of the first lines of the
LLVM Assembly source file, it might be worth the great pains it
takes to propogate types down the pipe a bit. It may soon be
possible to write a bitcode file that will compile down to all of
the platform-specific formats from the generic format like Java
or .NET does (except faster).
That would indeed be very nice!
LLVM supports custom calling conventions in the backend so I'd have
to write a patch to the x86 backend to get it to take Borland
fastcall convention. According to http://llvm.org/docs/LangRef.html#t_floating
the 80-bit x87 floating point type is supported but only on the
respective platforms.
That's fine, as the same goes for FPC.
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).
Would it be too soon to announce that FPC will use LLVM in the
future? Reason: If I can submit a patch directly to the LLVM
repository for Borland fastcode calling convention on x86, I may be
able to ask for help from the existing LLVM developers on their
mailing list.
I don't see any problem at all with announcing that people are working
on an LLVM code generation backend for FPC. I even already did so
myself a long time ago on llvm-dev (http://lists.cs.uiuc.edu/pipermail/llvmdev/2007-June/009282.html
-- it's quite annoying that the mailing list archive is blocked from
all search engines via a robots.txt file, not sure why that is).
Obviously, that work stalled at some point.
Jonas
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
