[fpc-devel] LLVM Backend?

[Matej Spiller-Muys]

> You also get breaking backwards compatibility with a lot of existing
Delphi code for free. I repeat: you really cannot underestimate the amount
of
> implementation details that existing Delphi code depends on, and people
already complain about FPC's incompatibility with those implementation
details.
Just so we are clear, what implementation details are you talking about
(that you would loose with C++ ABI)? C++ Builder and Delphi have the same
ABI and they work quite nicely together. There are even C++ libraries being
used inside delphi (like xerces and xalan). Even Delphi VCL is used inside
C++ (Builder). Btw how does the wxForms for Delphi (port of wxWidgets) on
Delphi work? It is commercial so I don't know how they have resolved the C++
linking problems because they also claim FPC compatibility. Another possible
option is to create a Objective C LLVM wrapper, since FPC already claims to
support it.

> So what is holding you back? Really, trying to convince other people to do
something that you would like to see done (or even worse: to work on it in
the
> way that you would prefer them to do it) in general just doesn't work. The
only way to achieve your projects is to start working on them yourself, and
hope
> that other people join in.
Currently I am still working into getting more complete COM support into FPC
(0014919) and a lot is already in SVN. What is holding me back is crashing
of applications using FPC DLLs (0014861 and 0014807). I could help LLVM
efforts, but couldn't really lead a LLVM port, due to lack of time. But
nevertheless debating how each developer see the benefits of each solution
is still good IMHO (no matter what direction the development will actually
take). Maybe i'll start next on more complete support for C++. Because I
need xerces/xalan and it uses only virtual functions inside C++ (so it
should be simple to port). Or just create OO for libxml/libxslt or start
effort to implement native FPC xslt.

> No, the question is what do people submit patches for.
True, but more readable code helps :) I tried to resolve above bugs myself
by studying FPC compiler a bit, even working on cleaner FPCDoc parser
(0011240), but fpc compiler is just too complex and confusing (for the
available time that I currently have :) ).

> I have no idea. All I know that's slightly related is the alioth computer
language benchmark game (with the stress on "game"), where you have at least
both
> FPC and GCC results.
Yup, the FPC factor is 2x-10x slower.
http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=fpascal&lang2=gpp&box=1
LLVM that is currently 30% slower than GCC and could speed FPC quite a bit
:).

Matej Spiller-Muys
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20091117/2d88a365/attachment.html>