[fpc-devel] M68k: important milestone reached

[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.

> 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.

>> FPC itself does not need to care for MMU or no-MMU. ;) 
Great. So the FIDO will be compatible with 68020 (e.g. can do 32 Bit 
offset with BCC)
>> 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) ?

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.

> Yes, currently FPC can not generate m68k PIC code, so something like 
> that will be necessary.
I did assume this ;-) .

-Michael