Hi,

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? Same for another OS?

Maybe some of the experienced folks can give a short sketch in a few sentences of the process of porting.

TIA,
Marc

Porting fpc to another processor dependents on the processor. It is difficult to give an exact idea. The sparc was started as third port, but in the meanwhile the arm and amd64 are already finished. Things like instructionset, alignment and calling conventions are the main parts of the porting work. This is all using linux as the OS, since that includes the less effort to port the RTL to another CPU.

To give a little indication of the time needed, porting the codegenerator part will take about 2 months of work when you already know how the compiler internals. This is only filling the already existing framework and not needing any fundamental changes.

Example from the sparc is that it also needs fundamental changes to fix alignment issues and support the calling conventions better. Then everything takes a lot more time.

Porting fpc to another OS ask marco or olle. They did the last OS portings.

As a basic estimation you can take the code size of the processor dependend directories in fpc/compiler. A simply port to another processor is between 5k and 10k lines of code.

Porting fpc to another OS ask marco or olle. They did the last OS portings.

Porting to a different OS can be very easy or quite hard. It depends how close the new OS is to existing ones. E.g. Classic MacOS is very hard because it's very different to existing OSes. MacOS X was pretty easy because MacOSX is a BSD unix.

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.

04-09-03 10.22, skrev Marco van de Voort följande:

I did also need to adopt the compiler, since Mac OS access global variables different than Darwin.

Also since the used asm (PPCAsm on MPW) has a different syntax than gnu asm, the assembler generator in the compiler had to be adopted.

You also need time:

* To learn FPC.

* To do investigations and tests how things, which are not documented, actually works (reverse engineering). And even if things are properly documented, there are subtle details you have to find out yourself.

* For correspondence with the core team or other mailing lists about different issues.

Olle

Hi again,

I want to thank you all for the elaborate answers.

Besides the typo in the subject there's not much left to say, this thread gives a good overview and some hints on the mostly underestimated extra tasks pointed out by Olle.

Where would one go to look for information besides the sources themselves, is there any further documentation or templates available?

Many thanks,
Marc

Compiler or RTL? For compiler, there is a start of docs linked from the wiki ("comparch").

I made two small docs, one about building the compiler, one about some of the reasons why the Unix rtl was changed from 1.0 to 1.1/1.9 and one about building the compiler

http://www.stack.nl/~marcov/buildfaq.pdf

http://www.stack.nl/~marcov/unixrtl.pdf