Hello together!

Today I stumpled upon this
http://www.itwriting.com/blog/5966-embarcadero-adopts-open-source-clang-for-future-c-versions.html and maybe some of you will find this interesting.

Let's see who will be first with LLVM support: Embarcadero or we ;)

Regards,
Sven

Having LLVM as sole fpc backend would probably take 90% out of my fun of fpc development :(

 Having LLVM as sole fpc backend would probably take 90% out of my fun of

fpc development :(

Why is that? I think it should be easy to add, especially after the addition of high level code generator that works well for jvm target.

________________________________

I don't think it will ever be the sole FPC backend, for several reasons: a) I doubt LLVM will ever support all platforms we support (go32v2, OS/2, ...), and older platforms it does currently support (e.g. Mac OS X/ppc) will probably become unsupported in the future because of bitrot. Because it moves so fast and often breaks/redesigns internal APIs, it requires extremely dedicated platform maintainers to keep a platform tier 1 (which is another reason for not relying on LLVM as sole backend, unless we want to keep support for some old LLVM versions that did support that target around forever) b) our direct code generators will probably always be faster in terms of compilation speed, so they'll remain very useful even on supported platforms for debug/development builds c) some people (you :) are not really interested in working on LLVM support

And as far as interesting things to do are concerned: there will always be high level optimizations that we can do much better at the Pascal level (like the function devirtualization that's part of our WPO) than LLVM will ever be able to do, because we have much more semantic and high level information. Additionally, LLVM has several attributes you can add to annotate functions (has no globally visible side-effects, optimize for size), parameters (e.g. pointer passed as parameter is no longer valid after the function, such as shortstring value parameters of which we make a copy on the callee side), data locations (e.g. range metadata, for subrange types), etc. that you can tweak via FPC to make it generate the most optimal code.

Jonas

I never suggested to have it as the sole backend of FPC. FPC's backend is far to nice to throw it into the next recycle bin. ;) Also Jonas' points are of concern here regarding the more exoctic targets of FPC.

Regards,
Sven

And, I'd like to offer up my thanks for these quote old unquote systems. I still have (and use every day) a minimac with a ppc g4 processor in it, and having fpc supported on it has saved me many times. I for one appreciate the effort put into supporting these non-current platforms.

Travis Siegel wrote

And, I'd like to offer up my thanks for these quote old unquote systems. I still have (and use every day) a minimac with a ppc g4 processor in it, and having fpc supported on it has saved me many times. I for one appreciate the effort put into supporting these non-current platforms.

Fortunately, thanks to FPC's code generator design the effort is quite reasonable :) And as far as the RTL is concerned, pretty much all deprecations in Mac OS X are situated in the high level frameworks, which are barely used by the RTL/FCL (although they should probably use them a little more, for e.g. getting date/time formats etc).

Jonas