Hello,

How would one proceed to port Free Pascal to a new architecture? Any initial steps? I haven't found anything about this.

I am considering a MIPS port (to target linux-mips). But don't count on it, not sure at the moment if it will be successfull.

thanks,

Felipe Monteiro de Carvalho wrote

How would one proceed to port Free Pascal to a new architecture? Any initial steps? I haven't found anything about this.

Please take a look at the backlog of this mailing list. It has been discussed just recently in the "LLVM Backend?" thread and also was discussed several times some time ago. (You might try to search for "NIOS", see below.)

I am considering a MIPS port (to target linux-mips). But don't count on it, not sure at the moment if it will be successfull.

This is great news for me, as I am considering a NIOS2 Port and NIOS2 is very similar to MIPS32 so we might be able to work together on this and the resulting thingy would support both architectures.

-Michael

P.S.:
Here a quote from the "LLVM Backend?" thread:

-------------------------------------------------- As this processor, a load/store RISC with 32 non-dedicated 32 Bit registers, is very similar to MIPS and thus a bit similar to ARM (only that MIPS-alike it does not have a status register) I suppose I should use the well-tested ARM code generator and modify it appropriately. Once I am done, someone should be able to add some definitions to have the thing create MIPS-32 code.

I just need to find the spare time (and at that time, I do hope for appropriate tips from this list to get me started,)

-Michael
-----------------------------------------------------------

Felipe Monteiro de Carvalho wrote

How would one proceed to port Free Pascal to a new architecture? Any initial steps?

Start from an initial backend that is most similar to your cpu. E.g., probably ARM or SPARC in your case. Then modify the code.

I haven't found anything about this.

There is no documentation about this.

Jonas

Here another quote from the said thread:

-------------------------------------------
Florian Klaempfl wrote:

Another backend for FPC is 4k-5k lines (pascal, no need to learn C), just make it a bounty for say 2000 Eur and I'am sure, somebody will write you a backend for the desired processor. -------------------------------------------

So this seems to be doable dedicating a couple of fulltime- days rather than months.

Hopefully Florian jumps in pointing you to some viable information.

-Michael

Michael Schnell wrote

This is great news for me, as I am considering a NIOS2 Port and NIOS2 is very similar to MIPS32 so we might be able to work together on this and the resulting thingy would support both architectures.

I already have 2 news about this.

On the bad side, my potential financer probably won't be able to finance the project, so I am less commited now.

On the good site it seams that someone already ported FPC 2.0.0 to MIPS, but never contributed to the main development:

http://sourceforge.net/projects/fpc-mips/develop

Maybe this work could be ported to the latest trunk.

FPC 2.0.0 is too old for me because I would like to run the latest Lazarus.

Michael Schnell wrote

This is great news for me, as I am considering a NIOS2 Port and NIOS2 is very similar to MIPS32 so we might be able to work together on this and the resulting thingy would support both architectures.

What operating system will you be targetting?

I think that telling FPC which ASM instructions to use should be quite easy, the main problem should be getting a grip in the binutils, how to link libraries and all other stuff that comes with it.

Luckly linux-mipsel has standard GNU binutils, but I don't know about NIOS2

Felipe Monteiro de Carvalho wrote

http://sourceforge.net/projects/fpc-mips/develop

AFAIK, this only contains some initial steps that someone tool ages ago and did not proceed.

Maybe this work could be ported to the latest trunk.

I have no hope regarding this and suppose to do code for the actual version of FPC it might be advantageous to start with the most recent code for ARM.

-Michael

Felipe Monteiro de Carvalho wrote

What operating system will you be targetting?

Linux

I think that telling FPC which ASM instructions to use should be quite easy, the main problem should be getting a grip in the binutils, how to link libraries and all other stuff that comes with it.

Yep: the ABI of the architecture. This is defined with the C compiler. We of course would need take care of this.

Luckly linux-mipsel has standard GNU binutils, but I don't know about NIOS2

Of course NIOS/Linux uses the standard GNU binutils, as well. But even with the standard GNU binutils, the ABI perhaps is different between MIPS32 and NIOS. I could search for the complete appropriate paper if you are interested. Here some stuff I just remember:

R00 always is 0
R01 used by Assembler for optimization (don't use) R02 Function Return Value (least significant 32 Bits) (Not used by Compiler)
R03 Function Return Value (most significant 32 Bits) R04 Function Argument (First 32 Bits)
R05 Function Argument (Second 32 Bits)
R06 Function Argument (Third 32 Bits)
R07 Function Argument (Fourth 32 Bits)
R08..R15 Caller Saved General Purpose
R16..R22 Callee-Saved General Purpose
R23 Pointer to Thread Local Storage ("ThreadVar") R24 Exception Temporary (Not used by Compiler) R25 Break Temporary (Not used by Compiler)
R26 Global Pointer
R27 Stack Pointer
R28 Frame Pointer
R29 Exception Return Address (Not used by Compiler) R30 Break Return Address (Not used by Compiler) R31 Function Return Address

R01 used by Assembler for optimization (don't use) R02 Function Return Value (least significant 32 Bits) (Not used by Compiler)

Sorry, Typo: Of course R01 is the one that is not used by the compiler.

-Michael

Using the above code, a port should be rather easy.