Am 24.02.2014 14:22, schrieb Michael Schnell:
On 02/24/2014 01:42 PM, Sven Barth wrote:
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.
Thanks for all these useful hints.
As the heap needs to be shared between the C functions and the Pascal
functions I suppose I should just implement the SysOSAlloc and
SysOSFree functions i a new "embedded" RTL and call the appropriate C
RTL functions there. And yes, I do multithreading. The C RTL heap
handling functions already are thread save, so no problem here. I
suppose the string handling needs additional thread awareness, but as
- at least at this point in planning - the use of Pascal is restricted
to a single thread, this should not be a problem.
As long as the Pascal code is restricted to one thread you won't have a
problem, otherwise the reference counting needs to be threadsafe (it
uses InterlockedIncrement/-Decrement which currently is implemented as a
simple inc/dec).
That's good. That's the same ABI that Linux uses.
This is what I expected. I forgot to mention that the result of a
function is returned in D0. But I a positive that this is the same in
Linux as well.
Yes, result in D0 is fine as well ^^
What do you mean with the "binutil API"?
Am I wrong to assume that "binutil" also provides some library
functions to include in the to-be-compiled project (e.g. "prototypes"
for calling stuff in glibc) ?
Yes, you are wrong here...
In fact I do not really understand why I need to have binutils just
for creating a .o file that is to be linked into a C project.
... as the binutils are merely assembler and linker. And without the
former you won't get a .o file and without the later not a program ;)
Yes, currently FPC can not generate m68k PIC code, so something like
that will be necessary.
I did assume this ;-) .
I'll need to check how Linux does PIC on m68k and also learn how to
implement PIC in FPC. :)
Regards,
Sven
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
