It looks like a neat experiment (definitely cool though), but I imagine you could (eventually?) implement a scripting language like lua in it, and register your program's external commands the scripting language needs access to.
I haven't decided on audio. It might be a set of sys calls that manipulate oscillators. The graphics interface is quite literally just manipulating the program memory. You can see the registers in the lower left corner of the video I linked.
I've wanted to make a language where the memory and the graphics output were interlinked. Meaning your memory was always visible and you had to balance memory usage and graphics usage. For some reason it took me too long to realize I needed to make a VM to make that a reality. Because of that goal, I decided to design the VM around a simplistic goal of having all program memory in one block. While this isn't realistic (a real machine wouldn't have its registers stored in the same memory as stored memory), I decided I didn't care.
So in the end, there was one core idea I wanted to play with, but I also wanted to teach myself more about ISA design and explore that area more.
I still dont understand why it requires a VM. What do you mean by 'interlinked' and 'always visible'. What does C lack that means this would not be possible? Does 'balance memory usage and graphics usage' refer to designing for very small systems with only a few megabytes?
Alright.
Even though its not really needed, and complicates things more, I was oddly attracted to the variable length instructions. I realize this would be a bit less attractive if it wasn't _my_ project, but I wanted to anyways. My basic design was one byte for the instruction (could be divided into two nibbles, one for the type, one for the actual instruction), and one byte for the registers. This allowed me 255 instructions max, and max 16 registers.
I then just started listing off the registers I needed. I could try to make up my own method of keeping track of the stack, base and instruction pointers, but I didn't really care enough. I also liked the _cdecl method of function calling in assembly, so I kept with that design as well. This meant a return register. The rest were split between caller and callee save registers, and I tried to give them a decently easy to remember mnemonic. Compare that to x86! I also realized I needed a null register which would indicate no register was used for operations (ie a `mov *(0x0), %ret` where there is no register for the first argument). I think I'll enforce this convention to make %null a little more useful. Unless the user tries really hard, I'll prevent anything from changing the contents of null from 0, making it useful for comparisons, and popping unwanted data.
It reminds the Moxie processor:
http://moxielogic.org/blog/
https://github.com/atgreen/moxiedev
The author even wrote a backend for GCC.
Your demo from Twitter should compile to JS with emscripten.