Well, I've finally gotten a copy of the Mono runtime, and I found where they
keep their MS Visual C++ project file, which has made it alot easier for me
to navigate around in the code. (Versus what I was doing before, browsing
around in web-based anonsvn.)
As I was guessing, on Mono's runtime end of things, even for the method
stubs, they obviously use struct-based constructs to represent the in-memory
managed objects. We will have to do the same, and we will have to be 100%
binary compatible with Mono, or at least with how our JIT will compile
Mono's corlib. Its not really a big deal, it just means we have to keep our
field sizes, structures, and positions, the same.
I will have to flesh out our Runtime equivalents better before we can do
anything with the stubs, so I'm putting them on hold.
Something I noted, that is rather interesting, is that MonoArray, (you
guessed it, the runtime version of arrays), depends on C's ability to pass
types as parameters into C macros that they use to compute array indexes
with. Since this is not something C# can do, (at least, not in our current
context, we can't), it won't be a straight-up-the-same implementation.
One thing we could do, is create MonoArray based structs, such as
MonoArray_AppDomain, MonoArray_Byte, etc, that work the same way as
MonoArray does in Mono under C. However, this would be frightening to
maintain. (We'd probably need at least 15 or 20 just to support our EDC
layer).
Speaking of which, I've run into a more pressing need for the GC, which I
should have seen coming.
Observe: (taken from object.h)
typedef struct {
> MonoObject obj;
> /* bounds is NULL for szarrays */
> MonoArrayBounds *bounds;
> /* total number of elements of the array */
> guint32 max_length;
> /* we use double to ensure proper alignment on platforms that need it */
> double vector [MONO_ZERO_LEN_ARRAY];
> } MonoArray;
>
...
#define mono_array_addr(array,type,index) ((type*)(gpointer)
> mono_array_addr_with_size (array, sizeof (type), index))
> #define mono_array_addr_with_size(array,size,index) (
> ((char*)(array)->vector) + (size) * (index) )
> #define mono_array_get(array,type,index) ( *(type*)mono_array_addr
> ((array), type, (index)) )
> #define mono_array_set(array,type,index,value) \
> do { \
> type *__p = (type *) mono_array_addr ((array), type, (index)); \
> *__p = (value); \
> } while (0)
> #define mono_array_setref(array,index,value) \
> do { \
> gpointer *__p = (gpointer *) mono_array_addr ((array), gpointer, (index));
> \
> mono_gc_wbarrier_set_arrayref ((array), __p, (MonoObject*)(value)); \
> /* *__p = (value);*/ \
> } while (0)
> #define mono_array_memcpy_refs(dest,destidx,src,srcidx,count) \
> do { \
> gpointer *__p = (gpointer *) mono_array_addr ((dest), gpointer,
> (destidx)); \
> mono_gc_wbarrier_arrayref_copy ((dest), __p, (count)); \
> memmove (__p, mono_array_addr ((src), gpointer, (srcidx)), (count) *
> sizeof (gpointer)); \
> } while (0)
>
If you notice, these wonderful macros, (call each other), and also call out
to some other functions in the Mono runtime, like
mono_gc_wbarrier_arrayref_copy(). Which reminded me - we can't create
pointers to a "managed" object, without tracking what is going on, for GC
purposes. For now, we can just hack around with SharpOS and not use the GC,
but RAM fills up fast, I would imagine. ;-)
Any thoughts?
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
SharpOS-Developers mailing list
SharpOS-Developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sharpos-developers
