[fpc-devel] M68k: important milestone reached

[Sven Barth]

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