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
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
