2003.03.13 ~04 Triseism - standalone Q3VM interpreter http://www.icculus.org/triseism/ Standalone Q3VM interpreter. Most of the workings of a stack-based machine became clearer when I brushed up on Forth. And Forth didn't make much sense until after I learned Lisp. After learning lisp, the idiosyncrancies of python became understandable. Q3VM sets aside 64KB total for stack. Forth uses two stacks. If Q3VM's stack is split in two (which I'm not absolutely certain on, but makes sense), to mirror the two Forth stacks, this gives a limit of 32KB for a stack frame. This limit is enforced by q3lcc at compile time, and I've always wondered why 32KB in particular. Looks like the run-time stack is involved. Some of the emulation techniques I borrowed from my experience on PHFC, the CUSP emulator. And from hacking on q3asm, the opcodes were fairly transparent. I created and compiled many very simple programs to see the translations of C source into Q3VM asm. The Q3VM syscalls are a bit of a zinger. For one, I can't possibly implement ALL the syscalls -- this would basically lead to rewriting Q3. The other problem is that Q3 has three sets of syscalls, one each for game (server-side), cgame (client-side), and ui (client-side menus). I'm thinking of using a dlopen() system to optionally load one set of syscalls over another. Splitting off the syscalls package would also be helpful in utilizing triseism as a general-purpose sandboxed VM. The other problem I'm having is the mysterious two words allocated on the (return) stack upon entering a procedure. Local storage starts after these two words, so the two words are likely involved with the return process. I'm thinking of distilling triseism into a library. One of my motivations for finishing this was an acquaintance's desire for being able to load a .qvm in another app, as one would open a dll. In other possibilities, since the opcodes of the Q3VM are now very clear, it should be possible to compile Lisp directly to qvm bytecode, bypassing any C translations or C compilation, i.e. foo.l -> foo.qvm. Also, I'm certain gcc and the gnu toolchains to can be hacked to compile directly to .qvm. Implementing a dll system within Q3VM is doable, but would probably need changes to the .qvm format. The current .qvm format discards the symbol table, precluding any dynamic symbol resolution. Since triseism is developed independently of Q3 proper, triseism isn't bug-for-bug compatible with idsoftware's Q3VM. This means triseism may not mimick every tiny detail of Q3VM down to the fiddling of bits. Triseism may help in tracing an execution path through a Q3 mod, but without debugging symbols, there isn't a simple way to link an instruction location with its matching line of C source.