Hi Bruce, Answers inline.
> -----Ursprüngliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Im > Auftrag von Bruce Markham > Gesendet: Dienstag, 5. August 2008 17:22 > An: sharpos-developers@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 ------------------------------------------------------------------------- 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
