Incorporating the Mono Class Libraries in MOSA – Part I

by Phil 9. May 2009 20:42

The first challenge to incorporating the Mono Class Libraries into MOSA is how to replace the external method calls in the class libraries with our own custom implementation. There are two basic approaches to this challenge. In part one of this blog series, we will explore the one used by other managed open source projects and its unique challenges.

The most common approach is to replace the call to the external methods with a call to the another custom method instead. This approach seems to be the simplest and most elegant solution – as you only have to supply the CIL code for the custom method and then have the compiler call the replacement method.

Ideally the replacement method would be implemented similar to this:

   1: namespace InternalSystem
   2: {
   3:     [TargetNamespace("System")]
   4:     public class SomeMonoClass
   5:     {
   6:         public int NewMethod()
   7:         {
   8:             return this.X * this.Y;
   9:         }
  10:     }
  11: }
 
Of course, this method will not compile because the member variables X and Y do not exist to the C# compiler. One possible solution is to create stubs for these member variables so they will exist while the code is compiled to CIL. Here we add those two member variables:
 
   1: namespace InternalSystem
   2: {
   3:     [TargetNamespace("System")]
   4:     public class SomeMonoClass
   5:     {
   6:         int X;
   7:         int Y;
   8:  
   9:         public int NewMethod()
  10:         {
  11:             return this.X * this.Y;
  12:         }
  13:     }
  14: }
 
Now the code compiles. And given some special CIL to native compiler, the external method call will be redirected to this other method instead. Creating stubs to expose these “hidden” member methods and variables seems like a fair compromise. But look at this example:
 
   1: namespace InternalSystem
   2: {
   3:     [TargetNamespace("System")]
   4:     public class SomeMonoClass
   5:     {
   6:         int x;
   7:         int y;
   8:  
   9:         public ClassC NewMethod(ClassA b, ClassB b)
  10:         {
  11:             return new ClassC(z, b.X, c.Y);
  12:         }
  13:     }
  14: }
 
Now additional stubs are required to represent the ClassA, ClassB, and ClassC classes, and stubs for each of their member methods and variables before this code will compile. Do you see where this is going? Given a rich framework with many dependencies between classes, like the .NET framework, this approach can results in the creation hundreds of stubs!
 
MOSA will approach this problem in another way, which I will be blogging about next.

Tags: ,

Code | MOSA

Comments are closed

Powered by BlogEngine.NET 1.6.0.0
Theme by Mads Kristensen | Modified by Mooglegiant

Projects

Software Stack

Recent Comments

Comment RSS

Badges

Enhanced with Snapshots