~vdupras/duskos

duskos/ROADMAP.md -rw-r--r-- 3.6 KiB
c515797bVirgil Dupras comp/c/vm/i386: fix integer promotion bug in logical ops 3 hours ago

#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
  • enum
  • goto
  • float
  • macro expansion in #define
  • #if/#else/#endif
  • 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, hex editor

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.

Same thing for a hex editor.

#Begin porting UNIX apps

I was thinking of beginning with something like GNU diffutils. I've also been hinted at 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

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? An ARM port is in progress.

#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

Especially to access mass storage through it.