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.
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. :) > 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. > > 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. 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. This ensures an easy separation of code into an embeddable JIT engine, with the AOT system simply being a file-feeder shell. 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. That way we know the basic compiler works and implements all CIL opcodes. Optimizations such as SSA, dead code elimination, loop unwinding, etc can all be implemented as transforms on top of the base IR code stream. 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. But I'm liable to get my head chopped off by Chriss for the above. :) > 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 ------------------------------------------------------------------------- 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
