[fpc-devel] M68k: important milestone reached

[Sven Barth]

Am 24.02.2014 12:37, schrieb 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.
Yes.
>
> For useful work in my project, I would need strings and with that of 
> course heap.
Here you'll basically need the initalization from the system unit. For 
Linux for example the entry point is located in 
$fpc/rtl/linux/m68k/prt0.as which calls PASCALMAIN (that's the main code 
of the program file). At first that initializes all units (including 
system) by calling fpc_initializeunits. In the system unit 
initialization the heap is then initialized and that should normally be 
sufficient for using strings (though the atomic functions will need to 
be implemented as well if you want to use multi threading ;) )
>
> 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).
You could either write a custom heap manager (similar to cmem which 
simply calls malloc/free from the C library), but you'd still need to 
keep the initial heap usage for initialization of the system unit in 
mind (except you replace the default heap manager functions inside the 
system unit). Otherwise you'd need to implement the SysOSAlloc and 
SysOSFree functions usually located in $fpc/rtl/OS/sysheap.inc (for 
Linux the location is $fpc/rtl/unix/sysheap.inc) to get the heap to use 
your C library functions.
>
>
>> 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
That's good. That's the same ABI that Linux uses.
>
>>
>> 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)
FPC itself does not need to care for MMU or no-MMU. ;) What do you mean 
with the "binutil API"?
> 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.
Yes, currently FPC can not generate m68k PIC code, so something like 
that will be necessary.

Regards,
Sven