Apr 10, 2009 at 3:15 PM
I'm posting this to the the discussions so we can continue doing just that.
Actively attending the meeting last night was grover, techguy, tgiphil, rootnode, and myself.
We discussed, as milestone goals:
From my best estimations, it looks like we then spent a whole hour (the meeting totalling to 2), debating/exploring runtime and icall implementation issues. While personally I learned a few things, I don't think we established anything new or non-obvious about
what is possible. I believe for simplicity the apparent overall consensus (with myself dissenting) for the corlib icall issue is how grover has been pushing (with some details now explained, or expounded upon by the group as a whole):
- Milestone 0.1
- Documenting critical parts of the code
- Everyone seems willing to contribute to this
- Register Allocator
- We clarified this is needed because right now we literally are not insuring that there won't be clashes. (HelloWorld kernel and test cases work from sheer luck.)
- Grover is the one predominantly doing this, during his spare time, but still has a ways to go - and rootnode has offered assistance
- As part of this all instructions will need to implement some sort of new contract specifying their side effects
- Milestone 0.2
- Instruction Side Effects
- Rework the instruction set to be immutable and rely on lateral type contracts combined with generic constraints
- Bug-Fix: Running Our Unit Tests On Mono
- The unit test framework we are using (mbunit + Gallio) does not work on Mono/*nix . I've volunteered to look into refactoring the unit test system to possibly using a more cross-platform unit testing framework that will still offer us the same functionality.
The apparent group consensus (again, with my dissent) to *not* use plugging for the time being because of:
- Spend time refactoring icalls and pinvokes in Mono's corlib out into partial classes
- Use a diffing tool to establish a clear path to this state of the corlib
- Implement the methods
- Csc/Mcs the corlib with our changes, and then run the MOSA compiler (as currently designed) against it, as we would with any other assembly, with maybe an exception for System.Object
- As Mono makes new releases, we generate new partial-classed corlib and automate the insertion of our previous manual code changes into it
I am of the opinion that we ruled out (or can rule out) the possibility of the plugging approach requiring runtime table indirection because we can add the constraint that plug implementations have to be AOT-able, even if surrounding code bits aren't. But it
is irrelevant as it seems we will be using the partial-class methodology.
- Invisible MOSA compiler magic
- MOSA compiler magic increasing compile time
- Lack of benefit from validation using the C# compiler that the partial-class approach gives
Things I suggest we consider for some discussions (here on the "discussions") that I wish we had gotten to last night:
- Milestone goals: I feel like this is documented somewhere but I can't find anything so it might not be, (or not be anymore.) If I'm wrong, correct me.
- What else for 0.1 ?
- What else for 0.2 ?
- What else for 0.3 ?
- ...which would include when the corlib conversation becomes relevant. Because it seems we don't want to go the SharpOS route and temporarilly support advanced constructs with duct tape, structs, and pointers in our C# code, we will want to do this sooner
rather than later, on account of the runtime and metadata
- Project Hosting. Phil has been arranging for us some alternatives. I think CodePlex is driving everyone up the walls, between TFS and these horrible "Discussions". Where do we stand?
- "ObjectManager". Grover brought this concept up in an RFC sometime back, but the details of the ObjectManager contract itself have not been fleshed out. (BTW, can we call it something cooler? Like "KernelProxy" or "HostProxy"
- The emulator stuff may be able to already benefit from getting this abstraction off of the ground
- We need to have this abstraction in place in order to do the corlib, and by extension, the runtime. (Since the corlib and runtime are fairly inter-dependent.)
- Publicity/Transparency: I know people around here have blogged about what they are doing with MOSA. Is this still done, with me just missing out? Should we consolidate this so that we can represent the project as a whole, from one blog location?
Apr 10, 2009 at 6:31 PM
thanks for sharing the meeting notes. I'd like to add or clarify a couple of things:
1. On our old redmine website I did document the goals for milestones 0.1-0.4, which were basically as follows:
- Get all basic data types working, mainly I1/U1, I2/U2, I4/U4, R4, R8, bool, char, pointers. I8/U8 was optional
- Get all basic instructions working, except those requiring services from the runtime or object support. I actually wrote a list of instructions there, which gave us approximately 50% coverage on the IL instructions.
- Make a basic system bootable
- Refactoring of 0.1 without new features
- Better Code coverage
- More tests
- Full IL instruction set for x86
- Object and value type support
- Exception support
- Support for mscorlib
- Maybe an additional port to an alternative platform (ARM comes to mind)
- Like 0.2, Refactoring, Code Coverage and Tests
Basically this is a compiler only roadmap and I think we should broaden it to include our runtime/kernel features. We should move this to a seperate discussion though.
2. Project Hosting/Tooling/Blogging
I have been using some new tools at work lately, specifically TeamCity, StyleCop, FxCop, ReSharper, Gallio 3.0.6 and have been trying out NDepend, NCover and other things. Since project hosting is apparently again up for discussion, I'd like to discuss extending
our use of tooling further -
especially TeamCity has been really worth and greatly improved my work.
For your blogging point: I have previously said that I don't want a central blog for all of us, but rather a blog aggregator, which pulls the content from our personal blogs using full text RSS (category) feeds. This works like a charm for other projects, so
I don't see a reason why it shouldn't for us.
3. Missed points in the meeting
rootnode had two more items on the list to discuss during the meeting, which we didn't get to. Specifically a who does what and the OSNews article. I think we should discuss this with the other things raised in another meeting (soon.)
4. Plugs (again)
illuminus, please pursue your path. I don't think my idea of partial classes is the only one perfect solution. I do see benefits to your runtime redirection mechanism, especially for application compatibility scenarios. I think even if it turns out we won't
use it for mscorlib, we will definitely use it in the long run - your pluggen tool could be extended to be an Application Compatibility Advisor for developers, maintainers and porters to appropriately plug assemblies. I think this would work great in combination
with app.config switches read by the runtime to do the pluging at assembly load time. I hate to drag your interests just because my opinion is different for a specific case (corlib.) And no there wasn't group consensus, as tgiphil and sbalmos both didn't decide
for a direction. And rootnode was in bed at the time.
And yes I'm against the hacks, duck tape and ptr mess SharpOS got entangled with because it means you need to rewrite a whole bunch of things once the compiler/runtime matures a bit more. There's a lot of (low-level) things to do, which are far more important
to get right than to attract potential developers, which loose interest too quickly because things are a mess.
I don't care what the name is. I personally like the Grand Central theme Apple is using for its new OS X scheduler and OpenCL implementation - please make up something cool because it isn't a kernel proxy or host proxy. And I do really think we should try out
this concept in our emulator. Phil, I can help you with the interfaces if you need me.
Apr 11, 2009 at 5:35 PM
Publicity/Transparency: I'm still blogging about it (http://think-in-co.de), grover used to do it too, but as he's apparently busy, blogging is not so important at the moment ^^
I don't know if anyone else is blogging.
We could represent the project as a whole, sure. Drupal for example has a very good aggregation functionality. We could also use it for the project mainpage.
Further we could use the design I'm currently using on my blog along with the logo. Colors just matched perfectly, hehe.