Well, like I said several e-mails back in this thread - MOSA needs to start
talking about standards. Adding another compiler to the list, (whether call
it a MOSA compiler or not, and whether we think it will be less confusing to
maintain or not), doesn't solve any lasting problems.
I was working on a multi-blog aggregator this morning (with hopes to pitch
it in MOSA's direction eventually), using LINQ and Microsoft's
ASP.NETRssToolkit, and found myself reading Cosmos' (Chad's) entry
about "X#" <http://www.gocosmos.org/Blog/20080428.en.aspx>. Its definitely a
more natural feeling way to express assembly instructions in C# code - and I
think MOSA needs to address these types of issues.
What MOSA needs, I think to start with, is a standard reference library of
stubs to support something like "X#", (or for the sake of example, stubs
that look like SharpOS' AOT X86 stubs) - and then begin working standards
around it. Standards that say "If you want an official MOSA compiler to emit
X86 for you, this is what you have to use." Granted, thats specific to the
C# subset of MOSA - but it gets us moving into a spirit of standardization.
All in all, I don't care too horribly much about how the stubs work. The
point is nearly moot considering no matter how you do it, you are going to
have to do analysis of the code graph to figure out what literal x86 (or
other machine language) the user wants you to emit. My point is that we need
a starting point. From there, we can talk about how we want to handle the
placement of the runtime ("in the kernel, or in the compiler" seems to be a
big issue) - and we can also talk about standards for how the VES works.
(For example, how we want to "plug" parts of corelib.)
Notice, these are all issues that each of our projects have addressed - and
in rather differing ways. But if we can't agree on standards, the idea of a
"MOSA" compiler for them is going to be useless. (I mean, the MOSA compiler
could use some sort of pluggable architecture so it can handle different
paradigms, but that would be impossible to maintain, and it wouldn't be very
performant.)
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
SharpOS-Developers mailing list
SharpOS-Developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sharpos-developers
