commit 253555cf3fd322432b8bc3ab9c27b56ea286742a
parent 980419242be4dca96884e06a37a083edc8791c9a
Author: Virgil Dupras <hsoft@hardcoded.net>
Date: Tue, 22 Nov 2022 14:38:06 -0500
Update roadmap
Diffstat:
3 files changed, 33 insertions(+), 13 deletions(-)
diff --git a/ROADMAP.md b/ROADMAP.md
@@ -24,17 +24,20 @@ consider complete:
So, there's a fair chunk of work left, but there's also a lot that's already
done.
-## Text editor
+## Text editor, hex editor
-TODO: description
+A naive first idea would be to port vi to Dusk, but I think we can do much
+better than this. The Grid is a much richer environment than a curses one and
+I think we can build a much more powerful vi-lookalike.
-## Memory explorer
-
-TODO: description
+Same thing for a hex editor.
## Begin porting UNIX apps
-I was thinking of beginning with something like [GNU diffutils][diffutils].
+I was thinking of beginning with something like [GNU diffutils][diffutils]. I've
+also been [hinted][hinted] at [mescc-tools-extra][mescc-tools-extra] which has
+versions of some important tools (ungz, etc.) in a dialect of C that is a better
+fit to more primitive compilers. Seems like a good fit.
## uxn
@@ -72,7 +75,20 @@ will also allow varvara-based uxn roms to run on Dusk.
## New architectures
-What about the Raspberry pi?
+What about the Raspberry pi? An [ARM port is in progress][arm-port].
+
+## Disassemblers, emulators
+
+Disassemblers and emulators are very useful tools to play around. We should have
+as many as possible.
+
+In the case of emulators, things can quickly get complex (I'm looking at you
+Intel), I think a good idea would be to have "partial" emulators, that is,
+emulators that are only good enough to run the kind of code that Dusk's
+supported programming languages generate (which is generally a smaller subset
+of all the opcodes in all modes that a CPU would support). This could help
+keeping complexity at bay while keeping all its usefulness. After all, the idea
+isn't to run Linux on it, but to use it as a development tool.
## USB drivers
@@ -80,3 +96,6 @@ Especially to access mass storage through it.
[diffutils]: https://www.gnu.org/software/diffutils/
[uxn]: https://100r.co/site/uxn.html
+[hinted]: https://lists.sr.ht/~vdupras/duskos-discuss/%3C69cfdb97-49d6-dccd-c7bb-df3b40eab7e6%40gmx.de%3E
+[mescc-tools-extra]: https://github.com/oriansj/mescc-tools-extra
+[arm-port]: https://lists.sr.ht/~vdupras/duskos-discuss/%3Cd5376d1b-1607-4f2e-bb7d-1da55f358de9%40app.fastmail.com%3E
diff --git a/fs/doc/design/limits.txt b/fs/doc/design/limits.txt
@@ -61,6 +61,8 @@ handle reasonable workloads of that program. The statically allocated sizes
are configurable system-wide when it makes sense and the effect of changing
those sizes is documented as well as possible.
+TODO: include arena allocators in this text
+
Semi-temporary data is managed through the use of statically allocated "rolling"
buffers that we call "scratchpads" (lib/scratch). They're used like a dynamic
allocation except you don't ever free them. Instead, you hold them for as short
diff --git a/fs/doc/design/simple.txt b/fs/doc/design/simple.txt
@@ -43,7 +43,7 @@ doesn't have a pre-processor, but it has a macro system that provide #define and
friends. This macro system isn't complete yet, but at this moment, it's about 60
lines of code. When it manages to be powerful enough to be considered an
adequate replacement to the C pre-processor, I don't think it will be over 300
-lines of code.
+lines of code. Tcc's pre-processor is 3900 lines.
Why this difference? While the two approaches are not functionally equivalent
(one is a textual macro processor and the other manipulates the C AST directly
@@ -51,8 +51,7 @@ and works within the regular C tokenizer and parser). However, the C
pre-processor forces us to reimplement a big part of tokenizing and parsing
rules, but in a slightly different manner. When you look at tccpp.c, you can see
the code is mostly about tokenizing and parsing. It's also striking to see the
-amount of boilerplate that you need when you're processing text and spitting
-text.
+amount of boilerplate that you need when you're processing and spitting text.
DuskCC sidesteps that complexity by piggy-backing on its existing tokenizer and
parser and manipulate the AST directly.
@@ -63,6 +62,6 @@ significant part of tcc assembler-related complexity. This contraint in UNIX is
inevitable because inter-process communication in UNIX generally has to be done
through streams, usually in text format for maximum compatibility. This implies
serialization and deserialization boilerplate at multiple levels. In Forth,
-memory is shared and no such constraint exists. We can thus afford to sidestep
-this complexity and use regular Forth words to assemble binaries, sidestepping
-this class of complexity.
+memory is shared and no such constraint exists. Words communicate through
+structured memory. We can thus afford to sidestep this complexity and use
+regular Forth words to assemble binaries.
