WetDesertRock

Oh interesting, I'll look more into that.

Yeah, it should compile to JS, I'll probably look into doing that at a later point in time.

Yeah, an idea like this would work well for console development!

Yeah, you could do it in C. I just didn't want to. The other part was that I wanted to make a language. I didn't want to piggyback off of something else. I mean interlinked is that your memory that you have to use for your application is also the memory that gets treated as a pixel buffer. So when you want to draw, you write directly to your pixel buffer. When I mean balancing memory usage and graphics usage I mean if you use too much memory, too much screens real-estate would be used.

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.

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.

Oh, and I forgot to answer your question.

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.

Yeah, I used my limited knowledge of x86 and some research into other ISA's (such as MIPS) to give me some ideas.

Ah, yeah. Its super hard to name anything anymore!

I think I'm okay with this name collision, but if there are any confusions I frequently refer to mine as YarnVM.

Yeah, I have some specific goals to it. One is making it into a game platform. See a video of the start of that project: https://twitter.com/WetDesertRock/status/703300191512715264