More importantly, even after going through all the files in libtvm/ , I still haven't managed to find the main instruction execution loop nor the decoding switch. Sorry, but I don't think "small and easy to understand" applies, and I've had experience with VMs and interpreters and the like for many years. Compare with this, for example:
A rule-of-thumb when investigating the source code of a project for the first time: if I have to go more than 2 directories deep to get to the "meat" of the code, my desire to explore further drops significantly.
for (; vm->prog->instr[*instr_idx] != -0x1; ++(*instr_idx))
 https://github.com/spc476/mc6809 
 Yes, it lacks a README. I know.
Because that's where the generated binary will go.
>lib/ is also empty
Presumably the same for any lib files?
>include/tvm is two levels but one is empty
That's as intended too, poor man's namespacing.
Why is even tracked, then? Surely putting it in .gitignore is a better way to go?
I’ve used the info you provided as the start, of course.
Have to agree with userbinator.
/* nop */ case 0x0
Rather than #define NOP 0x0? Namespacing? How about vm_NOP?
With zero explanation and code it's small experiment, but not really educational.
He has it precisely to make them linger. And what "no reason"? It's so subsequent scripts can put results there.
Being interested in wanting to write my own languages (though never finding the time with other pet projects) I always wanted to write something that would ultimately be usable with NekoVM as one of my side goals for a language. Neko also has a module for Apache.
For example, there's a C-like language for SUBLEQ machines: http://mazonka.com/subleq/hsq.html
Scanning the syntax, is there an operation for addressing memory? I see an operation for moving one value to another and that's it. I don't see any method of addressing a variable position in memory (or a variable position in an array if one wants to be more managed about it).
I suppose you could handle all operations from the stack.
But I think a lot of things require memory reads and writes, at least to do efficiently.
It's also very easy to crash the thing, either with a malformed input file or afl-fuzz. Are you sure C was the right choice here?
However, development seems to have slowed down drastically.