(I had debate whether to put this here or in the journal, but I am looking for peoples thoughts on some of this...)
well, here is the how this got going:
for a while, I wanted a VM which could allow extending the reach of C to targets where C is normally unavailable or overly inconvenient (namely web-browsers and Android).
while there is Emscripten for browsers, my initial tests had shown that the size of the output code expands considerably (*), bringing doubts to its realistic viability for moderate/large codebases, more so as I am running a personal-run server and don't exactly have massive upload speeds (they give like 30 Mbps down but 2 Mbps up, but a person could get 25 down / 5 up for "only" $179/month on a 3 year contract... cough...).
while the NDK is available for Android, it has some serious drawbacks, making it not really a great option (which version of ARM does the device run? what if it runs x86? ...). things are nicer if Java/Dalvik can be used here.
*: (EDIT: Removed. Issue turns out to be "not so simple".).
also, recently, I have put my game project on hold, for sake of basically reaching a stage where I have run out of ideas for new functionality and burnt out about dealing always with the same basic issues.
so, decided recently (~ several weeks ago) to start working on a new VM, consisting of several major components:
a C compiler front-end, which compiles C source into the bytecode format;
* based on a pre-existing C compiler frontend of mine, which originally targeted a different IL.
** it also had partial support for C++, so a C++ subset may be possible (will probably lack templates).
** it has spent recent years mostly just being used as a code-processing / glue-code generation tool.
* IR is statically-typed and register based, vaguely Dalvik-like
an interpreter backend, which will be rewritten in the form as needed for each target.
* current (still incomplete/untested) backend is written in Java, but C and Dart or JS backends are planned.
* the plan for the JS backend would be to dynamically compile the bytecode into JS on the client.
** main roadblock: dealing with JS, not sure the best approach to go about debugging in JS.
** Java via Google Web Toolkit is a more likely initial target for browsers ATM.
* it uses a design intended mostly to allow a (relatively) simple interpreter to generate efficient code.
** this basically means a Register-IR
** while stack-machines are simpler overall, a simple stack interpreter will give lackluster performance.
*** getting more speed out of a stack machine means a lot of additional complexity.
** also don't confuse simplicity with smallness
*** N*M cases may make code bulkier, but don't add much to overall implementation complexity.
* bytecode images are likely to be Deflate or maybe LZMA compressed.
the VM design in question here is much lower-level than some of my other VMs, and makes the compiler logic a fair bit more complicated, so this is still the main hold-up at present (can't finish/test the backend without being able to produce code to be able to run on it).
the design is intended to be high-level enough to gloss over ABI differences, and allow some implementation freedom, but this is mostly about all it really does (it otherwise that far above machine-code in a level-of-abstraction sense).
note that, unlike, say, Flash, this will not require any browser plugins or similar, rather the plan is that the VM will itself be sent over to the browser, and then used to transform the code client-side.
this does carry the assumption that the VM will be smaller than the code which runs on it.
this is worrying as, as-is, it means lots of code I have as-of-yet been unable to verify, but I would need to write a bytecode assembler and disassembler to test the backend more directly. will probably need these eventually though.
for those interested, here is a recent-ish working-spec for the bytecode:
still to be seen if I will be able to get all this to usably complete levels anytime soon.