[fpc-pascal]how much work is proting fpc

[Marco van de Voort]

> At first: Don't get me wrong and expect anything, I'm only curious.
> 
> That said:
> How much work would it be to port fpc to another processor?

Peter already did this.

> Same for another OS?

How easy depends on the OS. 

Yet another Unix should be pretty easy to do an initial port to (Jonas did the
basic Darwin port in 2 days afaik), since that is parameterising/checking
the current RTL. There is also a lot of experience with this in FPC core,
since nearly everybody in FPC core either ported to a new *nix, or
fixed/adapted the *nix port for some processor some time.

Still, like with the CPU thing, little gotcha's can be annoying, specially
if you want to do a full syscall level port. Startup code is also always an
issue.  However when porting to other BSDs, I often had the basic port
working in a night, and snapshot building-but-not-debugged (make all+ basic
linking to C working) in a week (working only a few hours every evening)

Typical sequence is 
- get rtl compiling
- get compiler compiling
- get compiler to work (read: startup code and debug rtl)
- implement OS dependant parts in the compiler ( conditionals to define,
	output formats, linker file creation. Pretty easy, and others
	can easily assist you)
- get fcl to compile and work (OOP helper stuff, RTL more stressed in general )
- get ncurses demo to work (basic c linking)
- get lazarus to work. (complex C linking) 

Lazarus now runs on Linux,Windows,FreeBSD (on x86), and also Mac OS X and
Linux (on powerpc). However getting NetBSD and/or OpenBSD to work would be
doable in a few weeks time probably. However it is hard to get a port
bug free and keep it up to date if you don't use it a lot, which is pretty
much why I abandoned NetBSD and OpenBSD for now.

A non *nix port is harder, and frankly, I don't have experience with that.
I dabbled so much in the original Linux port that it is now totally different,
but I never started something totally from scratch.

Typically one starts converting the OS API interface, and then try to get
bits and pieces from the most similar OS to convert and get working using
the own API. Startup (entry) code is also always a problem, and new non-unix
ports might also need additional compiler support for fileformats,
debug/object formats, calling conventions etc etc.

The hardest job by far is done by Olle (Classic Mac OS), since that is the
most peculiar OS ported to. (think emulation of standard concepts as emulating
stdin/out commandlines etc)

Amiga OS (done by Karoly) e.g. needed some compiler trick to quickly and
reliably implement the API, since it was basically an asm level API without
much system in it.