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

commit dd2e1ff8d3ab3d9dab3d2e0244f7c7e01ea5a6c6
parent 590d4da9489ea752bc0b8bc31e65be3811fcd1fd
Author: Virgil Dupras <hsoft@hardcoded.net>
Date:   Thu, 20 Oct 2022 12:22:36 -0400

doc: add design/port

MREADME.md | 13++++++++++---
Afs/doc/design/port.txt | 29+++++++++++++++++++++++++++++
2 files changed, 39 insertions(+), 3 deletions(-)

diff --git a/README.md b/README.md @@ -8,6 +8,11 @@ computers anymore but that there's still many modern computers still around. It does so by aggressively prioritizing [simplicity][simplicity] at the cost of [unorthodox constraints][limits]. +Dusk OS innovates (well, *will* innovate) by having an ["almost C" +compiler][duskcc] allowing it to piggy-back on UNIX C code, through a modest +[porting effort][port], to reach its goals and stay true to its design +constraints with a minimal effort. + ## Why build this OS? Most modern operating systems can do all whatever we want to do. Why do we need @@ -112,7 +117,7 @@ The high level roadmap for Dusk OS is: capable of compiling a nice subset of C. For example, it can compile Collapse OS C VM. You can see the kind of code that Dusk is capable of compiling and executing at [fs/tests/cc/test.c][5] and you can read about its - [technical details][6]. + [technical details][duskcc]. * It can run bare metal on some PCs (and QEMU, of course). It has drivers (in various state of sophistication) for: * VGA in text mode @@ -141,7 +146,7 @@ So, there's a fair chunk of work left, but there's also a lot that's already done. It's also important to note that, by design, this C compiler departs from ANSI -standard in some ways, described in its [technical details][6]. +standard in some ways, described in its [technical details][duskcc]. Development happens on [sourcehut][3]. @@ -228,9 +233,11 @@ BIOS" mode. [purpose]: fs/doc/design/purpose.txt [simplicity]: fs/doc/design/simple.txt [limits]: fs/doc/design/limits.txt +[port]: fs/doc/design/port.txt [usage]: fs/doc/usage.txt [dict]: fs/doc/dict.txt +[duskcc]: fs/doc/cc.txt [3]: https://sr.ht/~vdupras/duskos [4]: https://sr.ht/~vdupras/duskos/lists [5]: fs/tests/cc/test.c -[6]: fs/doc/cc.txt +[duskcc]: fs/doc/cc.txt diff --git a/fs/doc/design/port.txt b/fs/doc/design/port.txt @@ -0,0 +1,29 @@ +# Porting UNIX code to Dusk + +Some of Dusk's goals, such as being able to visualize PDFs, implies a big chunk +of code has to be written for it. The Forth ecosystem have a few chunks of logic +here and there, but Forth being Forth, nothing is standardized and, more +importantly, it's nowhere near the UNIX ecosystem in terms of completeness. + +We don't want, however, to embark on an endless journey of reimplementing this +logic. We want, instead, to be able to piggy-back on the exiting code as much as +possible. + +Therein lies a problem: that code is written on top of a UNIX platform, a +platform which we reject because of its complexity (see doc/design/limits). How +to reconcile these conflicting goals? + +First, by counting on the fact that most of the tricky logic we want to +piggy-back on is "pure" logic and doesn't actually depend on the UNIX platform. + +Second, by counting on the fact that the most important pieces of logic out +there are written in C. + +Third, by creating an "almost C" compiler that tries to strike a good balance +between two conflicting goals: one the one side, stay true to Dusk OS design +goals and on the other hand, minimize the amount of work that has to be poured +on a particular piece of UNIX C code before it can be compiled and ran by Dusk. + +Dusk' big bet is that with that compiler, it will be possible, with a minimal +effort, to piggy-back on exiting UNIX code to provide the same logic in a much +simpler environment.