[fpc-devel] M68k: important milestone reached
pascaldragon at googlemail.com
Mon Feb 24 13:42:29 CET 2014
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.
> 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
Yes, currently FPC can not generate m68k PIC code, so something like
that will be necessary.
More information about the fpc-devel