coderJeff wrote:Hi marcov, I meant the poke with the utmost respect. I think we have had some friendly worthwhile discussions from time to time about FPC's development and fbc's short-comings. I feel you have me at disadvantage as I think I am certain you likely know a lot more about fbc than I will know about FPC.
I get a bit of allergic when people put C on a pedestal. Usually the statements are very broad and suggests so much more (like seamlessly working while in reality you usually have to have create external headers) than it actually implements/does. Left unchecked people get the idea that a language is optimal for working with C, while they have to translate headers like everybody else.
At the very least it should be made clear what aspect of C compatibility is meant, if it is about backend, external linking, source and principles similarities etc. And if it is generic C or some specific implementation. In the case of GCC it is worse since it still has the tendency to emulate *nix on Windows, requiring import libraries generated with some external tool to simply link.
I am honest with myself: FreeBASIC is not taking over the world. Based on downloads and some other metrics I have a feeling that the project is important to some people. And that makes it interesting and fun for me to work on. And if there are some others that want to do the same, that's all good with me.
Neither is FPC. At best we are one of the larger ones in the pond with small fish.
I think probably more precise is to say gcc compatibility and following same ABI on whichever target it runs.
Doesn't gcc C++ have multiple ABIs on Windows (SJ and SEH etc?) :-)
Anyway we roughly do the same, but we diverge occasionally for targets where gcc is not the dominant compiler. That mostly are retro targets though, and to a lesser degree, Windows.
Maybe some users are trying other compilers? We are not making a generic optimizing assembler + linker. I'm not sure we will ever have enough resources for such work.
The internal assembler (based on NASM tables) and linker were for a couple of reasons mostly to do with compilation speed and smartlinking (removing procedures that are in a .o/.a but not used) on Windows, and minor reasons in general going beyond what binutils supports.
The fact that binutils for windows 64-bit took so long also didn't help.
But some users are willing to let fbc target gcc to get their fbc program to run on their system. So gcc is the fallback and the way forward on to other targets. Maybe if the LLVM backend gets going again it could be that instead /or also.
LLVM or Clang? Iow linking to LLVM to create a backend, or generating C customized for CLang? As for the former, I'm not hearing happy sounds in that camp. Anyway, long term you will have to, since BSDs and Apple targets are moving away from GCC>
True, fbc's preprocessor is C-like. However, I would say "preprocessor" is a misnomer. It's actually part of the lexer/parser, so variable types, sizes and constant values are evaluated as the source compiles. But also true, like C, can get really hairy if used for large template/generic code as there is no type safety in macros.
Yes. But as said my main gripe is that the preprocessor state of a module, say A bleeds into the declaration part (header/.h/.bi) of module B that A #includes. That is really bad behaviour because the same (.bi/.h) file can mean different things when two modules #include it. As said, C++20 contains a new modular approach to mitigate that and increase compilation speed and reduce such unexpected side effects.
I had a quick look around fp.org and looks great. I think it's been a while since I gave it a serious look. Well organized, looks like lots of contributors. You have many same packages that we translate headers for plus others. It was interesting to read through FPC's planned features and bug reports and see the some similarities with fbc. Overall looks like a great project to be involved with.
To really get a feel for it, you need to check lazarus.freepascal.org and the galleries in the wiki.
One of the great advantages is having a nearly complete toolchain in-house, at least on some targets. In the next release we debut an own resource compiler, but the big one (debugger) will take a bit longer and is already 10 years in on/off development.
As always, in projects like FB/FPC, the limitation is manpower.