Author: Virgil Dupras <firstname.lastname@example.org>
Date: Thu, 20 Oct 2022 17:53:28 -0400
|D||NEXTSTEPS.md|| | ||30||------------------------------|
|M||README.md|| | ||34||+++-------------------------------|
|A||ROADMAP.md|| | ||79||+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++|
3 files changed, 82 insertions(+), 61 deletions(-)
diff --git a/NEXTSTEPS.md b/NEXTSTEPS.md
@@ -1,30 +0,0 @@
-# Next steps
-Right now, my focus is on the C compiler, but here's some ideas of things to
-improve in periphery of that main effort.
-## Word annotations
-I'd like documentation about words to be in-system and this could be done with
-an annotation system. The annotation system is already there, we would need to
-populate those annotations.
-Then, it's a matter of developing a nice interactive application to navigate
-words and see their associated documentation.
-Right now, only one type of annotation is there, the docstring. However, another
-type of annotation would be useful, argspecs. To have comments like ( a b -- n )
-be in a separate structure is not only for better doc formatting, it's also that
-it will eventually be essential for C code to call Forth words. Because the C
-compiler has to know the signature of a word to properly call it, we'll need
-that argpec annotation to have a "machine-readable" structure.
-It would be fun if assemblers were leveraged early in the boot process to
-accelerate some core words. For example, it could override the "+" word into an
-immediate that emits `eax [ebp] mov, ebp 4 i32 add, [ebp] eax add,`, or even
-better, that detects if the last compiled word was a literal and replace that
-literal with `[ebp] (replaced literal) i32 add,`.
diff --git a/README.md b/README.md
@@ -96,19 +96,6 @@ and some of those pieces might be useful debugging tools which will be
difficult to retrofit because they need a wider system. You'll also need a
higher cognitive space to fit BSD/Linux wider abstractions in your mind.
-The high level roadmap for Dusk OS is:
-1. Have a 32-bit Forth written in x86 run on top of of a Linux system.
-2. Create a pseudo C compiler that is partly written in Forth and has the
- peculiarity of bootstrapping itself from it. No binary except Dusk's core.
-3. Target a machine (probably legacy PC) and have it run bare metal on it.
-5. Steal drivers from Linux and/or BSD kernels to widen hardware support.
-6. Port exiting POSIX applications so that Dusk OS fulfills its stated goals.
-7. Add support for more machines.
* Has a VM written in C, buildable from a POSIX environment, which allows Dusk
@@ -124,29 +111,13 @@ The high level roadmap for Dusk OS is:
* PS/2 keyboard
* PCI controllers
* ATA controllers
+ * AHCI controllers
* PC COM ports
* Can read, write and boot from FAT12/FAT16 (no FAT32 for now) volumes.
* Can create new FAT12 volumes.
* It completely self-hosts on all its target (only PC for now) machines.
-In a general way, here's the list of things missing from Dusk C for it to be
-* a few little ops here and there
-* the check phase (anything that is currently understood by the parser is
- compiled no matter how nonsensical).
-* probably countless bugs
-So, there's a fair chunk of work left, but there's also a lot that's already
-It's also important to note that, by design, this C compiler departs from ANSI
-standard in some ways, described in its [technical details][duskcc].
+What's next? See the [roadmap][roadmap]!
Development happens on [sourcehut].
@@ -237,6 +208,7 @@ BIOS" mode.
diff --git a/ROADMAP.md b/ROADMAP.md
@@ -0,0 +1,79 @@
+# Dusk OS Roadmap
+The biggest task is always to iron out the bugs, which are in ample numbers at
+this stage of development, but there's otherwise many exciting features on the
+## Complete DuskCC
+In a general way, here's the list of things missing from Dusk C for it to be
+* a few little ops here and there
+* the check phase (anything that is currently understood by the parser is
+ compiled no matter how nonsensical).
+* probably countless bugs
+So, there's a fair chunk of work left, but there's also a lot that's already
+## Text editor
+## Memory explorer
+## Begin porting UNIX apps
+I was thinking of beginning with something like [GNU diffutils][diffutils].
+I was thinking of not only porting the C uxn VM, but also making uxn a first
+class citizen of Dusk, with the possibility of creating adhoc uxn words. I think
+it would open interesting doors.
+## Word annotations
+I'd like documentation about words to be in-system and this could be done with
+an annotation system. The annotation system is already there, we would need to
+populate those annotations.
+Then, it's a matter of developing a nice interactive application to navigate
+words and see their associated documentation.
+It would be fun if assemblers were leveraged early in the boot process to
+accelerate some core words. For example, it could override the "+" word into an
+immediate that emits `eax [ebp] mov, ebp 4 i32 add, [ebp] eax add,`, or even
+better, that detects if the last compiled word was a literal and replace that
+literal with `[ebp] (replaced literal) i32 add,`.
+## Hardware configuration system and guide
+Right now, init scripts are a bit hackish and a structured configuration system
+would help a lot in facilitating the run of Dusk on a multitude of hardware
+## Graphical system
+Being able to push pixels to screen will eventually allow for PDF viewing and
+will also allow varvara-based uxn roms to run on Dusk.
+## New architectures
+What about the Raspberry pi?
+## USB drivers
+Especially to access mass storage through it.