commit cf8c0eb6e24de492bb680bfffa4e818b6ef5dfb4
parent 445c39361bdd1037913c675bf40228c3c58e48cf
Author: Virgil Dupras <hsoft@hardcoded.net>
Date: Thu, 20 Oct 2022 17:53:28 -0400
Add ROADMAP.md
Diffstat:
| 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.
-
-### Argspecs
-
-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.
-
-## Accelerators
-
-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.
-## Roadmap
-
-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.
-4. Self-host.
-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.
-
## Status
* 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
-consider complete:
-
-* union
-* switch
-* enum
-* goto
-* float
-* 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
-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][duskcc].
+What's next? See the [roadmap][roadmap]!
Development happens on [sourcehut][3].
@@ -237,6 +208,7 @@ BIOS" mode.
[usage]: fs/doc/usage.txt
[dict]: fs/doc/dict.txt
[duskcc]: fs/doc/cc.txt
+[roadmap]: ROADMAP.md
[3]: https://sr.ht/~vdupras/duskos
[4]: https://sr.ht/~vdupras/duskos/lists
[5]: fs/tests/cc/test.c
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
+roadmap!
+
+## Complete DuskCC
+
+In a general way, here's the list of things missing from Dusk C for it to be
+consider complete:
+
+* union
+* switch
+* enum
+* goto
+* float
+* 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
+done.
+
+## Text editor
+
+TODO: description
+
+## Memory explorer
+
+TODO: description
+
+## Begin porting UNIX apps
+
+I was thinking of beginning with something like [GNU diffutils][diffutils].
+
+## uxn
+
+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.
+
+## Accelerators
+
+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
+configuration.
+
+## 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.
+
+[diffutils]: https://www.gnu.org/software/diffutils/
