[fpc-devel] M68k: important milestone reached

[Michael Schnell]

On 02/24/2014 11:54 AM, Sven Barth wrote:
> We don't have an embedded target yet and for the two OS you mentioned 
> the RTL would need to be ported (or at least mostly stubbed). 

Of course.

At first, for a proof of concept,  I would just try to use some simple 
pascal functions and call them by a gcc function and have the pascal 
project call some gcc functions.

For useful work in my project, I would need strings and with that of 
course heap.

I suppose I can (and need to) create the appropriate RTL functions for 
providing a heap to the user code by forwarding the call to malloc/free 
and friends in  the C RTL (which I of course have).

> As you use GNU C then the calling convention used should hopefully be 
> the same as for Linux though you might want to check whether it's 
> using A6 or A5 as stack frame register.

The calling convention with C is (as well for gcc, as for the old MRI 
compiler I used before, as well for 68K-"CPU32" as for FIDO:

A7 = Stack
A6 = call frame (handle by LINK / UNLNK instructions
D0, D1, A0, A1 can be modified by the called function
D2, D3, D4, D5, D6, D7, A2, A3, A4, A5 need to be restored by the called 
function
all parameters are pushed to stack as 32 Bit values (some compilers 
might allow for word parameters to be pushed as 16 Bit value, but I 
don't use this), normal C-Call pushing order
The stack is cleared up by the caller after the call

>
> If you want to play with it nevertheless, the necessary parameters 
> should be -O- -Cp68000 (or maybe also 68020) and you'll need the 
> binutils for that target. You could for example compile a simple unit 
> that just contains functions/procedures (without managed types, no RTL 
> usage!) for m68k-linux (with the above mentioned parameters) 
That is exactly what I am up to right now. (AFAIK, "CPU32" and FIDO in 
fact provide most ASM features of 68020 - but no MMU - , so maybe 
"68020" might be appropriate. But I can't provide the "binutil" API to 
the pascal project, but just some dedicated RTL features I would be able 
to do myself)
> and then link the resulting .o file from a C program for the fido that 
> calls the functions (keep name mangling in mind or use "[public, 
> alias: 'SomeName']" on the Pascal procedures/functions).
Yep.

> I know that sounds rather complex and restricted at the same time, but 
> for now that would be the only possibility if there is no port yet.
I did not expect anything simpler :-)

In the end I supposedly will want to create a mechanism of "loading" a 
Pascal "program" using the running C project as a kind of "boot loader", 
e.g. doing the necessary recalculation of non-relative addresses.

For this the Pascal project would need to be linked to something similar 
to a Linux program (elf or whatever file) and my "loader" would need to 
handle same.

Thanks again,
-Michael