realkc / reqvm Goto Github PK

In commit 8b189c2 I gave up on working on the assembler. This is something I still need to write and this issue stands to remind me of that.

In order to make sure no regressions happen, a test suite should be added to the assemblers.

Currently reqvm simply loads all of the binary in memory at once, this is simple but does not scale. I should consider adding a way for the VM to choose between loading all of the binary in memory or not. Possible "backends":

• memory backed - loads all of the binary into memory. (like what we currently do)
• file backed - does not load the binary in memory but rather stores a file object, jumping is a seek operation
• memory mapped file - maybe, will have to do some research about this stuff.
  • handle errors.
  • wrap the low level APIs

This is a low priority issue that should wait until higher priority things are done(e.g. the assembler).

Currently reqvm programs cannot allocate programs on the heap. This should be rectified.

Models that I will likely add:

• C-like manual memory allocation and deallocation
• a GC (or more)

Design questions:

• do we want manual memory allocation to be mutually exclusive with the GC?
• should there be a way to force one model over the other anyway if the answer to the above is "no"?
• how do we treat pointers?
• should our instruction set be expanded to allow instructions to work directly on pointers?

I'd like to have an interactive debugger as part of the VM.

Requirements:

• is a TUI
• can show bytecode in bytecode format and disassembled
• allows patching bytecode at runtime(this however should not modify the existing binary, at most it should create a patched binary)
• allows inspecting the state of registers, the stack, and (when added) the heap
• allows intercepting VM panics.

Related feature(s):

• make the assembler emit debug info (mostly a address -> label mapping)

Adding support for working with floating point would be nice.

Changes needed:

• add the instructions and registers to the specification.
• figure out how to make the floating point and stack interactions work
• add opcode and registers definitions to common/opcodes.hpp and common/registers.hpp
• make the VM aware of the new opcodes and registers
• make the assembler be able to emit bytecode making use of these new registers and opcodes.

Design questions:

• Should the VM only support extend to 64-bit floating-point numbers(i.e. double in C++), or 32-bit floating-point numbers(i.e. float in C++) as well?
• How many registers should be added?