[Mono-devel-list] malloc and free on CLI
Jeyasankar Kottalam
mono at jey.kottalam.net
Sat Jul 16 17:01:10 EDT 2005
Quoting Kornél Pál <kornelpal at hotmail.com>:
> I think the libc should be written in C and compiled into a fully managed
> assembly that could be part of Mono Class Library and could be installed to
> the GAC. You were talking about C# in your previous message. I think it's
> much easier and pretty to write it in C. Of course this will need a C
> compiler but I think it's worth to wait until the compiler will be at least
> partially complete. And it's much easier to port an existing libc to managed
> C than to C#.
Yes, I agree. However, I still need a mechanism to implement a heap. Even if
porting an existing libc, that libc will need *some* mechanism to get memory
from the runtime. What is the recommended way of doing that?
I only referenced C# as a possible candidate to implement the malloc() and
free() in because it's easy to interface with the Mono Class Libraries using
C#. Then we could use whatever mechanisms are available in the Mono Class
Libraries to implement the heap. Otherwise I would need to implement the
mechanism to interface with CLI classes from C/C++ before I could even have a
functioning heap.
The backend is complete enough to start wondering about these things.
It has not
been fully tested and has a number of known bugs, but it mostly works.
> The compiler and C runtime library are two different things and I think you
> shouldn't be forced to forge a libc just to can compile an application that
> uses libc. I think in the early stage the Mono Class Library should be used
> instead of a libc. And of course implementing a libc is just as much work as
> implementing a C compiler.
I agree, I won't be implementing an entire libc. I'm only interested in
implementing a subset of the libc for my own use. The heap is the only thing
really troubling me. I could simply use a statically allocated array as a pool
and do allocations from that for now... but that doesn't scale enough to try
any interesting applications.
When I have the time, I'll look into porting one of the small libc
implementations (e.g. newlib, uclibc) to Mono.
> So I think your implementation should not require libc and should link libc
> as a managed assembly using metadata references to be platform independent.
If by "not require libc" you mean "not require the native libc", that's what I
have in mind. Otherwise I would have used P/Invoke to make calls to the native
library. (and the heap problem would be a non-issue)
-Jey Kottalam
More information about the Mono-devel-list
mailing list