After discussions about the porting methods we'll use to bring the AOT to the ARM (and other) architectures, I wish to change my proposal so that there is another milestone between 4 and 5, where we integrate a set of scripts to generate the processor's instruction set. Chriss used a set of custom scripts to extract the instructions from HTML, we're looking at either an XML-based [iron]python script solution or one that uses the disops python project (or a combination of both). The milestone would be:
Milestone 5: A stable system to generate C# code necessary for multiple instruction sets, used in porting the AOT to other architectures On 7/28/07, William Lahti <[EMAIL PROTECTED]> wrote: > Wow no one has any comments then? :-P > > On 7/27/07, William Lahti <[EMAIL PROTECTED]> wrote: > > Our roadmap is lackluster in terms of providing a real sense of > > progress... our first milestone is trivial in comparison to our second > > milestone, and the massive size of it could be enough to stall > > development. While the completion of the AOT is one of our biggest > > priorities as it sets the course for completing our initial nanokernel > > and process system, there are many other steps between that must be > > completed before the AOT can actually produce managed code for the > > kernel. I think we should expand our roadmap with more, smaller, > > milestones that provide a clear and step-by-step plan to bring our > > first fully-functional kernel to release. I've been meaning to get > > feedback on this idea, so I figured a proposal would be a good way to > > incite some words on whether this is a good plan. So: my proposal > > follows: > > > > Milestone 1 stays unchanged > > This milestone is a good PR/attraction point because we'll be able to > > offer a download of SharpOS for OS enthusiasts to play with. It will > > be a good time for us to show the world how much we've cut the endless > > loop of the chicken/egg problem of running C# code (of any variety) > > without lower level support code written in a traditional language > > like C/C++. > > > > Milestone 2: a functional runtime and kernel testcase system > > The integration of our runtime code into the trunk kernel, preparing > > for subsequent AOT support for managed code. We will model the runtime > > in such a way that makes integration with the AOT's managed code > > support a no-brainer :). This milestone would also call for a new > > testcase system for the kernel internals-- while the > > SharpOS.Kernel.Tests code actually tests the functionality of the AOT, > > this testcase system would stress the real trunk kernel as we've > > written it. I don't have a solid direction on how we would do this... > > any ideas? > > > > Milestone 3: Korlib > > We will need to have a light, kernel-level mscorlib that we've > > tentatively called Korlib up to this point. We should strive to create > > a corlib codebase that can be used both for korlib and the userspace > > mscorlib (via C#/AOT conditional compilation). The korlib does not > > need to be complete, only functional enough to begin running managed > > code in the kernel. > > > > Milestone 4: Stable AOT support for managed code > > The AOT at this point should be able to generate managed code (aka > > EDC) with help from our kernel runtime. > > > > Milestone 5: Completion of a partially managed/unmanaged scheduler > > implementation supporting pluggable scheduler plugins (maybe even > > using more than one scheduler plugin at a time for different > > processes?) as well as a process subsystem for > > management/monitoring/destruction of managed processes (from code > > precompiled into the kernel) > > > > Milestone 6: Cyclic compilation of the AOT engine > > The AOT should now be capable of compiling itself into the kernel > > (as-is). Naturally it's use will be limited since it is not yet > > suitable for use as a JIT engine. > > > > Milestone 5: Stabilization and completion of version 1.0 of our AOT > > compiler > > This would be equivalent to our current milestone 2 > > > > Milestone 6: Refactor the AOT so it can be used as a suitable JIT > > engine for the kernel as well as the AOT engine used to compile the > > kernel. > > The title says it all on this one > > > > Milestone 7: Integrate the JIT and have support for loading/JITing IL > > assemblies at kernel runtime, using the process/scheduler code we've > > written. > > > > Milestone 8: An initial release of the SharpOS kernel. > > > > This is mostly off the top of my head, but it does quantify much of > > the work we need to do to in getting a real initial kernel out the > > door. If you have additions/changes i'd love to hear them-- I don't > > really know everything necessary to make a kernel or else I would've > > done it already!! > > > > -- > > fury > > > > long name: William Lahti > > handle :: fury > > freenode :: xfury > > blog :: http://xfurious.blogspot.com/ > > > > > -- > fury > > long name: William Lahti > handle :: fury > freenode :: xfury > blog :: http://xfurious.blogspot.com/ > -- fury long name: William Lahti handle :: fury freenode :: xfury blog :: http://xfurious.blogspot.com/ ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ SharpOS-Developers mailing list SharpOS-Developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sharpos-developers
