On 8/28/07, Scott Balmos <[EMAIL PROTECTED]> wrote: > Chad Z. Hower aka Kudzu wrote: > > I'd like to make a few proposals. > > > > 1) We establish a loose but workable team structure which includes conflict > > resolution. > > > > > Someone will probably say this already exists. I don't know. My major > recommendation right now is establishment of a build master, who owns > the trunk. All changes should be done in local repos. When something > should be promoted to the trunk, it is debated here, goes through a code > check, and the build master normalizes the code to a coding standard > before committing it to the trunk. Trying to get rid of William breaking > the kernel again (heh), or our infamous problems of things compiling > under Mono but not VStudio or vice versa.
To my defense, that topic change was voluntary! Honestly I should be developing on my own branch, but when I started there wasn't any other branches or development. They started popping up before I was done :). > Between that, and API / architecture docs before you start coding a > major piece. Everyone else can tell you how much I've grumbled lately > about not being able to get my VM code going because the trunk repo got > reworked, the base kernel's in flux, and the AOT is still buggy. :) API design by spec does not work, that I am certain of. I do think having a plan is good, and writing extensive docs for what we have is good, but outlining the entire API before we do it is rather pointless if we throw in one new use case, because that use case will change the API. I'm a strong believer in the feature freeze conventions. > > 2) We establish a highly documented, well debated kernel design doc. Then > > proceed to make the kernel rock solid before putting too much effort into > > anything beyond the command line. Now a design doc sounds good, but recall that we have not even fulfilled that command line milestone. We don't have a working shell. > I've been kicking for this for awhile. Currently it's more a code-first, > write-architecture-later. The largest part of the system, the compiler, > is AOT-only, and only one person knows its architecture. I've been very > vocal about that. Don't know if Chriss has gotten anywhere with > documenting the architecture. Architecture is completely different from "API docs". I agree entirely on outlining how the thing will work, just not too specifically. There's a sweet spot somewhere. > Personally, I would halt all current kernel-related development, go back > and tear back apart the compiler and get that completely rearchitected, > redocumented, and retested. Start with reading in the source bytecode at > a method level from multiple sources, whether it's a byte stream, file, > whatever. Now would be a good time, because Chriss is reworking the whole thing. But you cannot demand such things of one developer. He needs more help. Chriss has been calling for testcases the entire time, and only just recently have me and Bruce answered those calls, and we still require TONS more. He was having a hard time keeping the AOT stable throughout his reworking without enough testcases. Unfortunately that was right at the time I no longer had stable internet access. This is further complicated by the entry barriers of the AOT (which are very high). I've only just begun to gain a real extensive grasp on how it works. > This ensures an easy separation of code into an embeddable JIT > engine, with the AOT system simply being a file-feeder shell. It's already in the plans to refactor the AOT into a JIT with a more or less dumb AOT program that embeds it. Like I said, now is a good time. > Convert to > unoptimized IR code, then register transfer code. Spit out direct, > unoptimized machine code from there. Possibly hand-verify if necessary > the generated machine code. Chriss has just recently made some commits to make it more possible to disable the optimizations btw. > That way we know the basic compiler works > and implements all CIL opcodes. Hand verification isn't useful in this case, because we'll break stuff as we continue development. Testcases are the way to go, and we are doing that but by far not enough. > Optimizations such as SSA, dead code > elimination, loop unwinding, etc can all be implemented as transforms on > top of the base IR code stream. Agreed. One of the first projects I took on here was to make them all optional, but that wasn't possible because of the design (at the time). > From the testing I've seen, I can't tell > whether bugs are in simple bytecode conversion or various IR > optimization algorithms. They all seem to be intertwined currently. Yes, it's been a big issue. > > But I'm liable to get my head chopped off by Chriss for the above. :) He might. But if he doesn't, I at least nibbled at your ear :) > > 3) We establish a build process to produce ready to go VMWare images as well > > as easier to build source scripts. > > > Already exists, for both VMWare and Bochs Oh, and QEmu works, but it always does (no config files!) > > > ------------------------------------------------------------------------- > 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 > -- 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
