[SharpOS Developers] MOSA / AOT
Sander van Rossen
Is Mosa (going to be) a replacement for the AOT compiler?
I'm asking because we have several issues (also for the next
milestone) related to AOT.
If nobody's going to continue working on the AOT, and it's going to be
replaced,
then those issues would never be met and should be removed.
(for example: "AOT documentation issue" / "Support for floating-point
primitives and arithmetic issue" / "Add support for constructors of
arrays that are not 0 based.")
Also, there still seems to be one open issue on exception handling..
Anyone got any idea what the status is on that?
(same goes for "Some interrupts need to throw exceptions just like
DivideByZero" issue)
-------------------------------------------------------------------------
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-D...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sharpos-developers
grover
the forum & svn hosted by Scott Balmos (now Ensemble). My personal intention
is to make MOSA a shared effort by both SharpOS and Ensemble. The problem
both projects face are those of contributors/contributions and as we have
discussed more than a week ago about architecture. We have to more or less
live with the split efforts, however I think we can share the code we
develop.
My contributions to MOSA include:
- A compiler
- Beginnings of a VES with support for reflection and other things packed on
top
I hope we can extend this through shared efforts to include:
- A common kernel
- A common driver model and driver code
- A common port/adaptation of monos corlib
One additional goal is to make MOSA attractive for research.
I have a lot of ideas in this regard and especially my vacation week was
very productive to accomplish these goals.
My *personal* thinking of MOSA is that it acts as the core kernel and
SharpOS/Ensemble/... become distributions based on this kernel code in
different configurations including/excluding certain things. I know this
isn't easy for some of us and it isn't easy for Scott. However looking at
the active contributor lists and the overall progress this is the only way I
see both projects or either one can move forward. Either we work together or
we die together.
The AOT is working for us right now. I would like to keep it along as long
as possible. However there's no real maintenance there as I see it.
Mike
> -----Ursprüngliche Nachricht-----
> Von: sharpos-devel...@lists.sourceforge.net
> [mailto:sharpos-devel...@lists.sourceforge.net] Im
> Auftrag von Sander van Rossen
> Gesendet: Dienstag, 29. Juli 2008 13:36
> An: sharpos-d...@lists.sourceforge.net
> Betreff: [SharpOS Developers] MOSA / AOT
Phil Garcia
Bruce Markham
However, I am in also in agreement with Phil and Mike, in that, right now, there is no maintenance on it - I believe that unsaid sentiment is that it simply isn't maintainable. Everyone here wants to write kernel code. Or user level code. The AOT is the means to an end - and several people now (through grover's MOSA efforts, Ensemble, and Cosmos), have proven the basic ability to compile IL to x86 is not particularly difficult. (Time consuming to implement, sure. But there is more than enough documentation out there, and previous works, to make a basic functionality work.)
The problem is, no one can take it that step forward. We need reflection, we need dynamic runtime bindings, and we need it to be self-hosting. Whether or not an AOT is re-written, or the current one is re-purposed - we still face the issue of *how* to bind the kernel code to the AOT.
All of our efforts as a whole, need to address this issue first and foremost. The good news is, if we can agree - it doesn't matter whose AOT to work we decide to extend in that direction. Any single one could be the solution to getting us to the next step. Just like there are standards for how C compilers and C# compilers and such work - if we can define a standard on how we want the AOT to handle a kernel - and then all agree to step forward with that - we can benefit as a group.
And *then*, we can start talking about driver architectures and code sharing. *shudder*. (I think a "common kernel" is out of the question, because of licensing decisions as well as varying schools of thought around here. But at least a common API means we don't have to share core implementation code.)
Furthermore, I would like to assert that we not overlook JNode. MOSA right now may just have a couple C# OS projects in it - but JNode has us beat on the proof-of-concept managed operating system goal. With the proper allocation of design efforts, we can create a set of standards that does not preclude using IKVM, in combination with whatever AOT a C# OS project is using, in order to run JNode driver binaries. It bypasses alot of design and implementation work in order to get us all into common ground. Without common ground, we cannot refer to ourselves as seperate projects divergent from some mystical original ideal. C# is not an ideal. Its a tool. And the managed bit, well, its already been done. If we are looking to innovate, we need a jump-start. And then we can talk about re-writes and branches and optimizations down the road.
I don't think there has been any official talks between SharpOS and JNode. SharpOS + Ensemble + Cosmos relations are slippery at best. The C# crowd - all of us - need to get our acts and heads together, under MOSA, (not sure if Cosmos is still viable, much less, interested in MOSA, but still). With that done, collectively, we need to rise up to meet JNode, and extend a hand of friendship.
So, if someone could re-post the information on MOSA (wasn't there a discussion group or something somewhere?), I would be grateful. We need start some topics of conversation at a centralized, non-biased location. See if we can crack our skulls together to get an idea of where to proceed.
But I agree. We will either work together or die together. There are too few interested and available developers right now for it to be any other way. And if we allow ourselves to fizzle, we will pollute the water for future generations that get curious regarding this idea...
grover
The MOSA Forum is at mosa.ensemble-os.org, its SVN is at
svn.mosa.ensemble-os.org (thanks Scott!).
There are currently members from JNode, Cosmos, Ensemble and SharpOS
registered with the board. The discussions have flattened a bit there,
but I still think the effort is "live". Ensemble is pretty much
committed to using/working with MOSA as they're basically waiting for
the compiler. However Scott is reserved due to SharpOS/Ensemble
architecture differences, which I think can be resolved though. If we
define proper interfaces and make all operating system "algorithms"
pluggable, we'll get this done and we'll get another point: We're
getting interesting from a research perspective. (Hi Adam!) A lot of
progress JikesRVM has made the past years is due to research
contributions - we have to get there to stay alive.
I know compiler writing is viewed as black art, however a proper
design deals with a lot of things without black art. If you take a
look at my work you'll certainly find that it has a lot of pieces to
it, but they're cleanly seperated and easy to replace (research!) and
it will move us forward IMO.
Mike
Sander van Rossen
fantastic idea and we should definitely go with it.
But if we're not going to use the AOT, the next question is; how far
along is the MOSA compiler, and how long (roughly) will it take before
we can start to realistically use it?
Because there are a couple of show-stopper bugs/features missing in
the AOT (such as the interface problem that Phil emailed about
before), and until we can compile the kernel as it is, and beyond, the
whole kernel development comes to a stand-still.
And like Bruce mentioned, most people here want to develop at the
kernel or user level..
So how are we going to handle this situation?
sha...@michaelruck.de
Before I left for vacation the compiler started emitting its first machine code instructions. Since then I've continued my path of refactoring and enhancing to stay with a clean design. I don't want to speculate about completion dates, but its not a matter of weeks. There's a lot still pending and one of the goals I have is being able to compile SharpOS as it is right now - which it can't do yet for various reasons.
Anyways for user mode, there's a defined API: The .NET Framework (with Mono libs) - anybody should be able to work with those and develop their user-mode apps. For kernel mode the story is a bit different and I'd like for those who want to work there to sit down and discuss what they want to do and maybe really do a design-first, document-first, prototype-first, test-first style of development (which IMHO this project really really needs.)
I'm all for meeting up and discussing various aspects and like I said previously we should try to get at least Scott to the table. We definitely are able to specify interfaces and we are able to write device emulators to get us started, the compiler will catch up quickly. Btw. that is the path that Ensemble is taking and Phil is moving a lot of his work over to MOSA so both projects can benefit here.
The compiler will steadily improve, however in order for the improvements to be measurable we need to improve the testing situation. I've started a test system using mbUnit, which allows us to test the created code right on a Windows box* reducing the turn-around times. This has worked beatifully for the integer addition and could easily be extended to other basic operations on all integral and floating point types. I'm thinking of doing a compiler status page, where everyone can see the things supported/not supported and the progress can be monitored - this basically should clear up all the confusion if the compiler does support feature Y or not. I'd wish we could automate this with appropriate test cases and with the help of some continuous integration toolkit to automatically generate these reports for everyone to see them.
I'm planning on allowing the VES I'm developing as part of the compiler to be hosted inside the MS CLR, so we could even go as far as running code on Windows in our own runtime environment hosted inside the MS CLR. These efforts should dramatically improve development as booting up SharpOS (or any other kernel) in a VM is always a lengthy operation and I'd like to get to the point of being able to run/debug various services right on Windows/Linux as long as they don't touch real hardware. And this can work for lots of operating system services.
Mike
* I haven't started Linux support as monos gmcs compiler in version 1.9 lacks some features from the C# language I've been using, however the new 2.0 preview should compile and run the compiler fine. I'm not sure about mbUnit though and I'd need to rewrite the test suite due to manual executable memory allocations etc.
Sander van Rossen schrieb:
I'm absolutely for an initiative such as MOSA, and think it's a
fantastic idea and we should definitely go with it.
But if we're not going to use the AOT, the next question is; how far
along is the MOSA compiler, and how long (roughly) will it take before
we can start to realistically use it?
Because there are a couple of show-stopper bugs/features missing in
the AOT (such as the interface problem that Phil emailed about
before), and until we can compile the kernel as it is, and beyond, the
whole kernel development comes to a stand-still.
And like Bruce mentioned, most people here want to develop at the
kernel or user level..
So how are we going to handle this situation?
-------------------------------------------------------------------------
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=/
Zachary Gorden
Sander van Rossen
has some bugs, which prevent us in properly implementing some parts of
the kernel.
In a way, we're kinda stuck and can't go forward because of it.
So either we fix those bugs in the AOT, and implement those features
that we need (which would be hard because the person(s) that know the
most about the AOT are no longer active), or we wait until the new
MOSA compiler is mature and developed enough to continue with the
kernel.
Just to throw in another option:
Don't the other teams, or at least the Cosmos, have compilers as well?
Although they're not designed as well in the basis as the AOT, maybe
we could 'borrow' one of these compilers for the time being until the
MOSA compiler is finished?
-------------------------------------------------------------------------
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=/
grover
There's only two options available IMHO:
1. IL2CPU from Cosmos
Which could be used, but has its fair share of issues too. I'm certain that
we could get further with it than the AOT, but we still can't do an advanced
design AFAIK, as there's no support for Attributes, Reflection, ... However
we would have to ask Matthjis about this.
2. Bartok
We all know what that means ;)
Ensemble doesn't have one, but Scott is contributing to the MOSA compiler
and in total there's now 4-5 people working on it directly or indirectly. A
prioritized list of features would allow us to drive the compiler into a
specific direction, e.g. support certain things earlier than later. Ensemble
is in the same position as SharpOS with this respect, except they don't even
have an AOT to work with. Further speedups in the compiler are not possible
right now, as there's some blocking points that need to be resolved before
we go ahead and add more manpower to the compiler. I'm happy with those who
contribute their time, code and mind to it.
In fact I think we should use the time to redesign specific parts of the
kernel and refactor the existing code base. I know its hard without writing
a piece of new code, but I think this is the right time to document what we
have, where we want to go and how we want to get there.
Mike
> -----Ursprüngliche Nachricht-----
> Von: sharpos-devel...@lists.sourceforge.net
> [mailto:sharpos-devel...@lists.sourceforge.net] Im
> Auftrag von Sander van Rossen
> Gesendet: Dienstag, 5. August 2008 10:42
> An: sharpos-d...@lists.sourceforge.net
> Betreff: Re: [SharpOS Developers] MOSA / AOT
grover
Von: sharpos-devel...@lists.sourceforge.net [mailto:sharpos-devel...@lists.sourceforge.net] Im Auftrag von Zachary Gorden
Gesendet: Dienstag, 5. August 2008 09:45
Chad Z. Hower aka Kudzu
Yes, Cosmos has a full compiler.
> Although they're not designed as well in the basis as the AOT, maybe
> we could 'borrow' one of these compilers for the time being until the
> MOSA compiler is finished?
If you can live with our BSD license. :)
Chad Z. Hower aka Kudzu
> that
I think its much farther along than you think....
> design AFAIK, as there's no support for Attributes, Reflection, ...
They haven't been high on the list because we haven't needed them yet.
grover
Mike
> -----Ursprüngliche Nachricht-----
> Von: sharpos-devel...@lists.sourceforge.net
> [mailto:sharpos-devel...@lists.sourceforge.net] Im
> Auftrag von Chad Z. Hower aka Kudzu
> Gesendet: Dienstag, 5. August 2008 14:11
> An: sharpos-d...@lists.sourceforge.net
> Betreff: Re: [SharpOS Developers] MOSA / AOT
>
Jonathan Dickinson
of your code doesn't 'fit' into it. I don't think you would be able to
compile your stuff without a lot of work (shy of a total re-write).
--
Jonathan
Bruce Markham
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#". 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.)
grover
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: sharpos-devel...@lists.sourceforge.net
> [mailto:sharpos-devel...@lists.sourceforge.net] Im
> Auftrag von Bruce Markham
> Gesendet: Dienstag, 5. August 2008 16:22
> An: sharpos-d...@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
Chad Z. Hower aka Kudzu
> about
> X#, but sadly think this appears nice at first, but causes a lot of
> headaches afterwards.
Actually it has worked very well for us. It's a 1:1 mapping, its not a
compiler more of a Mnemonic system. There is no way I'd go back to what we
had before or even Intel Mnemonics, AT&T or otherwise.
Bruce Markham
My point is, MOSA needs to agree on how to handle (and how much to handle) differing paradigms. Grover, I'm glad you think you agree with me - but you didn't actually address the blunt of my point. The point being, the MOSA forums are almost as much of a ghost town as SharpOS is. It may be a compiler you are writing to contribute to MOSA, but MOSA as a whole (which in and of itself, is rather undefined), needs to have an infrastructure on agreeing on standards by which opinions or guidance can be generated in regards to *any* compiler, including this new one being written.
Calling it a MOSA compiler may not be accurate if it has to be branched four ways from Sunday in order to work with each project. And maybe - maybe *thats* exactly how "MOSA" wants to do it. But there just isn't a clear enough definition of what MOSA is right now, for any of us to know how to feel about each other's compilers. (After all, we are trying to eliminate the "mine is bigger than yours" crap so that we can get along.)
MOSA needs a domain. MOSA needs a mailing list. MOSA needs *people*. Then, I think, MOSA can sit down to create standards. There is so much to talk about, that I think we need some clear, defined space to do it in, so we can track what is going on.
When you guys first started talking about MOSA, I didn't think about code at all. But code is an understandable extension of agreed-upon specifications. Specifications that we need to take time, space, and conversation to figure out. The MOSA AOT is fascinating and exciting, but conversations about it are moot for now.
Phil Garcia
MOSA needs a domain. MOSA needs a mailing list. MOSA needs *people*. Then, I think, MOSA can sit down to create standards.
grover
Answers inline.
> -----Ursprüngliche Nachricht-----
> Von: sharpos-devel...@lists.sourceforge.net
> [mailto:sharpos-devel...@lists.sourceforge.net] Im
> Auftrag von Bruce Markham
> Gesendet: Dienstag, 5. August 2008 17:22
> An: sharpos-d...@lists.sourceforge.net
> Betreff: Re: [SharpOS Developers] MOSA / AOT
>
> Okay, before anyone starts marking their scents on the ground
> - (I'm stopping you so I can get mine in there first) - my
> point isn't what looks pretty or doesn't.
I understood you right. I'm glad you're contributing your scents ;)
> My point is, MOSA needs to agree on how to handle (and how
> much to handle) differing paradigms. Grover, I'm glad you
> think you agree with me - but you didn't actually address the
> blunt of my point. The point being, the MOSA forums are
> almost as much of a ghost town as SharpOS is. It may be a
> compiler you are writing to contribute to MOSA, but MOSA as a
> whole (which in and of itself, is rather undefined), needs to
> have an infrastructure on agreeing on standards by which
> opinions or guidance can be generated in regards to *any*
> compiler, including this new one being written.
The MOSA forums are not used much right now. I agree with you
there. You see I'm in a weird position - I'm contributing things
and trying to drive the effort my way. I've been primarily doing
things by communicating with those really interested directly in
person and have used the resources SharpOS and Ensemble have provided
me with. The infrastructure (like Phil said) is being worked on and
will appear sooner or later.
> Calling it a MOSA compiler may not be accurate if it has to
> be branched four ways from Sunday in order to work with each
> project.
No branches. The design and architecture of the jit compiler is
flexible enough to survive differing OS designs, calling conventions
etc. I don't want to call it a piece of art because its not there
yet everywhere, but it will eventually.
> And maybe - maybe *thats* exactly how "MOSA" wants
> to do it. But there just isn't a clear enough definition of
> what MOSA is right now, for any of us to know how to feel
> about each other's compilers. (After all, we are trying to
> eliminate the "mine is bigger than yours" crap so that we can
> get along.)
Right. I've expressed my opinion about what MOSA is in the past. I can
repeat that here: MOSA is an effort to provide at least a toolkit of
ready made, tested and well designed components for all .NET CIL based
operating system efforts. These components maybe specifications for
interoperability, source code or other services. My personal belief is
that MOSA can consist of standard ready-to-use implementations of several
operating system services, which if used together result in a nice kernel.
However the goal there is to make every part replacable (like they are in
the current compiler!) so that every project can decide to pick this, that
or roll its own if it doesn't see the ready-made things fit.
> MOSA needs a domain. MOSA needs a mailing list. MOSA needs
> *people*. Then, I think, MOSA can sit down to create
> standards. There is so much to talk about, that I think we
> need some clear, defined space to do it in, so we can track
> what is going on.
I fully agree with you here. Like Phil said, we're working on it. By we I'm
talking about Adam, Phil, Scott, rootnode and myself. (Sorry if I forgot
someone,
as always I'm on the run.) These are five people with differing interests
and
focus coming from various backgrounds that are actively contributing in
various
ways there. The space is being worked on, however what hasn't been discussed
yet
is where we'll start. More on this below.
> When you guys first started talking about MOSA, I didn't
> think about code at all. But code is an understandable
> extension of agreed-upon specifications. Specifications that
> we need to take time, space, and conversation to figure out.
> The MOSA AOT is fascinating and exciting, but conversations
> about it are moot for now.
This is the point where my opinion differs by far from yours. I consider a
compiler and runtime environment *the* two *key* pieces of any effort. If
your
compiler isn't capable of certain things, then you can't use them. Which
means
that you either start adapting your designs to a lacking compiler (like
SharpOS
is right now) or you freeze those efforts and define a specific set of
features you
need from the compiler in order to do a *good* design. The latter approach
is
IMO the right one and the one I'm pursuing. I have a design of a lot of
these things
in my mind and the compiler is the core puzzle pieces - the first one of a
larger
puzzle. The MOSA driver model Phil works on builds on a set of features none
of
the existing CIL-to-native compilers have - but it's design is very much
.NET. It
is using attributes, interfaces, abstract base classes etc. Things that make
.NET
pretty in contrast to the unmanaged world. And please stop talking about the
compiler as an AOT - in fact it is not. And one of my next contributions
will add
jit trampolines and dynamic compilation *on Windows*. It is a jit in the
disguise of
an AOT - and they will even differ a lot due to the use of different
compilation
pipelines.
I know you won't agree with me on some of these thoughts and this is really
ok.
Mike
Bruce Markham
The MOSA forums are not used much right now. I agree with you
there. You see I'm in a weird position - I'm contributing things
and trying to drive the effort my way. I've been primarily doing
things by communicating with those really interested directly in
person and have used the resources SharpOS and Ensemble have provided
me with. The infrastructure (like Phil said) is being worked on and
will appear sooner or later.
And don't think we weren't keeping that in mind when we put you on the SharpOS board. We are here for community, and we don't want to alienate anyone. (i.e., I wasn't trying to alienate anyone.) Just keep the communcation channels open. That is the key to us all uniting under a MOSA banner.
No branches. The design and architecture of the jit compiler is
> Calling it a MOSA compiler may not be accurate if it has to
> be branched four ways from Sunday in order to work with each
> project.
flexible enough to survive differing OS designs, calling conventions
etc. I don't want to call it a piece of art because its not there
yet everywhere, but it will eventually.
I hope you haven't bitten off more than you can chew. This is certainly something to look forward to!
> MOSA needs a domain. MOSA needs a mailing list. MOSA needsI fully agree with you here. Like Phil said, we're working on it. By we I'm
> *people*. Then, I think, MOSA can sit down to create
> standards. There is so much to talk about, that I think we
> need some clear, defined space to do it in, so we can track
> what is going on.
talking about Adam, Phil, Scott, rootnode and myself. (Sorry if I forgot
someone,
as always I'm on the run.) These are five people with differing interests
and
focus coming from various backgrounds that are actively contributing in
various
ways there. The space is being worked on, however what hasn't been discussed
yet
is where we'll start. More on this below.
I might have displayed more interest in MOSA from the start (I think I did sign up for a membership on those forums right when they were first created) if it had been a bit more organized, and I know Will was interested - but this isn't the first time we've talked about "getting along" with the other C# OS projects, and we still really haven't proven that it can be done on a meaningful level.
> When you guys first started talking about MOSA, I didn'tThis is the point where my opinion differs by far from yours. I consider a
> think about code at all. But code is an understandable
> extension of agreed-upon specifications. Specifications that
> we need to take time, space, and conversation to figure out.
> The MOSA AOT is fascinating and exciting, but conversations
> about it are moot for now.
compiler and runtime environment *the* two *key* pieces of any effort.
I'll stop you right there. At that point of my ramblings, I was more referring to my first impressions of what the idea meant. You've already shown me the light on this regard.
If
your
compiler isn't capable of certain things, then you can't use them. Which
means
that you either start adapting your designs to a lacking compiler (like
SharpOS
is right now) or you freeze those efforts and define a specific set of
features you
need from the compiler in order to do a *good* design. The latter approach
is
IMO the right one and the one I'm pursuing.
But as your compiler matures, people will start tinkering with it. And if it has limitations, chances are people will code around it. With no documented standards, we can't even write unit tests to help you out. I want to see this compiler soar - but its going to take some bearucratic processes to pave the way. Otherwise, it isn't any different than the path the SharpOS' AOT took. (A lone developer dropping a black box on hungry kernel-coders-to-be.)
And please stop talking about the
compiler as an AOT - in fact it is not.
Oh goodness. I didn't mean it as an insult - its just from habit. We all spent alot of time here with our AOT - and we've seen other projects try the "Its a magical box that compiles your code to anything" thing, and that project ended up re-prioritizing (for that time being.) Its no small feat - and I don't envy the tasks you have in front of you.
And one of my next contributions
will add
jit trampolines
I like trampolines. They make me happy!
I know you won't agree with me on some of these thoughts and this is really
ok.
I think we agree more than I let on. But since I don't have the time to help you code, (which I really wish I could do), I'm at least taking the time to suggest how this needs to be handled administratively.