TeeEmCee wrote:Writing the rtlib in anything other than C seems like a pain, needing to translate the system headers for every flavour of Unix.
Unix is less of a problem, you only need about 100 calls, and some more for threading support (pthreads). The windows headers are a bigger problem, but users need access to them anyway, and large parts can be semi automatically translated.
So FP is written purely in FP? How does it do that? Does it call into libc for Unix system calls, or use syscalls?
Well, there can be assembler in FPC RTL sources, this is of course minimized to some base functions (think floating points and primitives like copying bytes, searching in memory (ptr+distance) for a byte, word, dword etc, primitives for exception handling)
Some platforms have a small fragment of assembler for the startup code (equivalent to crt0.o on *nix). Usually this is modified decompiled GCC code or assembler, whatever the target provides. Linux has an all pascal startup on most targets. FreeBSD not, partially because weak symbols on FPC level were not yet working when I lasted tried.
The Unix RTL can be built to interface to libc (from Pascal code) and to syscalls. Both FreeBSD and Linux default to syscalls, Mac OS X defaults to libc. Basically maintainers preference, but the Linux and BSD ports were done much earlier (1995 and 1998) than Mac OS X (2004-6), the targets were much less coherent then and syscall binaries are better copyable between Linux distributions.
On *nix targets ld (though not necessary GNU) is used, and GAS on the more odd ball targets. On Windows and non windows (Amiga, Dos etc) it is native. The number of non binutils targets has steadily increased since 2005.
Yes, FB is very very heavily inspired by C and C++. I always describe FB as a superset of C and subset of C++ with BASIC syntax, better strings, and a graphics library. Features of C/C++ have been methodically copied verbatim into FB over the years. I do question whether this was a wise design.
I also think the copying was too easy. That said it is difficult, features copying happens everywhere, also in FB. (and not just C/C++, but also VB(COM!), C#/Java etc, even if only because Delphi does).
Also, some people want to do high level app development, some want to basically use it as a system compiler, and there is constant friction between all those requirements.
It has gotten to the strange level where most new Delphi functions are by default wrapped in a struct to make it look a namespace, because customers demand it because qualifying and grouping the functions is more "high level" and "OOP" like (even if there is no state to instantiate). I'm not against OOP, on the contrary, but it must be functional, this is madness. It sometimes makes you doubt keeping compatibility.
However I think FB losing an own philosophy is worse than some feature creep at the edges. If you don't set boundaries, all new up and coming devels will do is copy-and-paste the quickest and dirtiest way.
However, personally I'm quite happy with it, because I link lots of C, C++ and FB code together, and it makes interoperability easy. So I'm reliant on a C++ compiler anyway.
So do I with FPC, and objective C too if needed. (There is a native interface to objective C, and you can define objective C compatible classes in Pascal to some degree).
You don't need a C backend for that, and unless FB suddenly magically started to understand C/C++ headers(which would be frontend matter), the backend doesn't really add much there, except that it is mandatory to be GCC compatible instead of voluntary.
But you're mistaken in arguing that FB supporting features of C is because FB compiles to C or uses library written in C. FB has all these features of C because they've been reimplemented from scratch, not because it relies on a C compiler.
Or just because the mindset turned C, nobody bothered to look any further or to a bigger picture anymore.
Of course, if you dig you will find semantics of the C runtime or ncurses libraries that bubble through to FB (e.g. the effect of LANG environmental variable on 8bit -> wstring conversions)
Yup. Basically there is no windows port. There is only a port to the *nix emulation engine on Windows. Of course that is gradual difference (from cygwin to one end to very simple things that could be said out of multiplatform concerns). But if you place *nix and gcc and its libs central, you might as well use cygwin.