commit f6de9c233e94c5de6510c1ea2dc76904c9729fbe
parent b9bc71009d66c1a2225d3c2bc5c607970656ac6a
Author: Virgil Dupras <hsoft@hardcoded.net>
Date: Thu, 2 Jun 2022 10:17:00 -0400
Update README
Diffstat:
| M | README.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
