dusk os fork
git clone git://git.alexwennerberg.com/duskos
Log | Files | Refs | README | LICENSE

commit f6de9c233e94c5de6510c1ea2dc76904c9729fbe
parent b9bc71009d66c1a2225d3c2bc5c607970656ac6a
Author: Virgil Dupras <hsoft@hardcoded.net>
Date:   Thu,  2 Jun 2022 10:17:00 -0400


MREADME.md | 44+++++++++++++++++++++++++-------------------
1 file changed, 25 insertions(+), 19 deletions(-)

diff --git a/README.md b/README.md @@ -51,28 +51,30 @@ possible to elegantly marry it with languages that like complexity better. This mix, we believe, could provide a creative user with computing powers rarely seen with other approaches. We've got to try it. -## Design considerations +## A whole OS built from source on boot -### Build from source on the fly +One thing that makes Dusk OS special is that it boots from a very tiny core +(less than 600 lines of x86 assembly as well as less than 100 lines of +pseudo-Forth code). From this tiny core, on boot, it builds its way up to a +system that has a functional C compiler, which then allows it to bootstrap +itself some more. -With Dusk OS, I'd like to try having a system that starts from a smaller kernel -than Collapse OS and that kernel would compile its way up to a usable system -on boot. +With regards to "source bootstrapping", it's even more extreme than Collapse OS +because modern machines allows this process to run very fast and the whole +process is not much slower than a regular Linux boot. On Collapse OS target +machines, this process would be prohibitive, so a bigger part of the OS is +cross-compiled into the kernel. -For Collapse OS, this option is impractical because compiling takes a long -time on 8-bit machines. It's much better to cross-compile the kernel up to -something that is usable as is. The drawback of this is that -cross-compilation tooling has to be more complex. +This peculiarity of Dusk OS has interesting properties. The nicest one, in my +humble opinion, is that this allows us to sidestep the *entire* problems of +binary compatibility and relocation and only deal with source compatibility. +So, no ELF, not binutils, only code that is designed to run from where it was +written in the first place. This is so much simpler! -Modern machines compile forth code much, much, much faster. Because Dusk OS -will have a much "wider" system at boot and that cross-compiling this wider -system can get complicated quickly, it seems simpler to me to initialize from -source at boot time. So I'll try that. +Object files? Global symbols? Nah. C functions that don't have a static storage +type are simple Forth words. -This principle could extend to words written in C throughout the system. We -could have a system where all compilation takes place on-the-fly through some -lazy-loading mechanism only when the word is used the first time. That might be -fun... +(note: this isn't actually done yet. See Status below. But it's well underway.) ## Roadmap @@ -89,8 +91,11 @@ Here's the plan so far: ## Status -We have a functional Forth prompt and currently working on step 2 of the roadmap -above. Development happens on [sourcehut][3]. +Currently working on step 2 of the roadmap. There are functional tokenization, +AST parsing and assembler generation phases, but implementation is (very very) +partial. You can see an example with "./dusk < testcc.fs". + +Development happens on [sourcehut][3]. Unlike Collapse OS which is a personal effort and doesn't lend itself well to collaboration, Dusk OS' wider scope makes it fitting for a collaborative effort. @@ -114,6 +119,7 @@ and echoed twice. To avoid that, you can invoke it like this: (stty -icanon -echo; ./dusk; stty icanon echo) +`make run` does this for you. [1]: http://collapseos.org [2]: http://collapseos.org/why.html