Hi Bruce,
Actually everything you said is my personal belief. And everything you wrote
is already in the design of the compiler. Native operations are handled by
marking properties, fields or methods with an Intrinsic attribute, that
tells the compiler here's special code to emit. I've read Chad's entry about
X#, but sadly think this appears nice at first, but causes a lot of
headaches afterwards.
You're right with the standardization needed. And I believe that this will
get going. I will personally try to drive it, once I've got more time to do
that.
Mike
P.S.: Here's an example:
/// <summary>
/// Provides stub methods for selected x86 native assembly instructions.
/// </summary>
public static class Native
{
// ...
/// <summary>
/// Wraps the x86 ldit instruction to load the interrupt descriptor
table.
/// </summary>
/// <param name="idt">A pointer to the interrupt descriptor
table.</param>
[Intrinsic(typeof(Architecture), typeof(LditInstruction))]
public static void Ldit(IntPtr idt) { ThrowPlatformNotSupported(); }
// ...
}
Using it is as simple as Native.Ldit(ldit) - the compiler knows not to emit
a method call, if he's running on x86 architectures. The other ones will
fail with a PlatformNotSupportedException. This is live code from MOSA.
> -----Ursprüngliche Nachricht-----
> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Im
> Auftrag von Bruce Markham
> Gesendet: Dienstag, 5. August 2008 16:22
> An: sharpos-developers@lists.sourceforge.net
> Betreff: Re: [SharpOS Developers] MOSA / AOT
>
> 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.NET RssToolkit, 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
