Yarn – A small embeddable VM with a custom instruction set | Hacker News Reader

Yarn – A small embeddable VM with a custom instruction set

github.com

55 pointsWetDesertRock20 comments

Open articleView on HN

Very cool and promising!

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.

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.

It's simple once the emscripten SDK is installed ("emcc main.c -o main.js/html").

https://kripken.github.io/emscripten-site/docs/tools_referen...

Nice ! Seems interesting to consider it for my diy game console (bitboxconsole.blogspot.com) and allowing on-console game dev !

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

I find this strangely fascinating, but have no idea what I could use it for. Is it intended to be useful, or just a neat experiment?

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.

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

But do you need the VM for something specific, is it part of some philosophical/aesthetic guideline, or is it just something fun to do?

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?

He might meen GPU programming, which has separate processors and memory from the CPU.

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.

What sort of graphics/audio interface do you expose to the program?

(The project is very cool! The instruction set reminds me a bit of the MIPS subset usually implemented in uni courses.)

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

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.

Pretty cool. I'd like to know more about the design decisions. Why registers? Why those specifically? And more.

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.

Fyi Yarn is also the name of the resource manager of Hadoop v2 => might be a bit confusing. http://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yar...

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.

Reply on news.ycombinator.com