Phil Hassey - game dev blog
Phil Hassey as Rambo
".. I've been there,
I know what it's like,
and I'll do it again if I have to."

64k tinypy – vm or no ..

Well, things continue to come along with tinypy. I’ve been experimenting with a lot of different things with this. Some things I’ve tried:

– Assumed all infix operations were for numbers – was able to get quite a bit of speed at the sacrifice of things being “obvious”. I’ve disabled this for now, since I figure if you really want speed, you’d be using C anyways, not “tinypy”.

– Tried switching from passing around 16 byte structures to pointers to those structures. This didn’t work so well, because given my simple implementation it meant that any time any operation happened, another 16 bytes had to be allocated to store my floats. Not so hot for rendering fractals 😉 This caused a 10x slow-down. I reverted that out, but I copied that stuff to a branch for reference.

– I learned more about how libgc works. Basically, you need to use the GC_MALLOC and GC_REALLOC functions instead of the libc ones. libgc takes care of the rest. Also, if you integrate with libsdl (or some such library), you’ll need to do the memory management for it. There is hope – gc.h includes a function called GC_REGISTER_FINALIZER which makes it possible to trigger finalizers when an object is about to be freed. I’ve added some code to do this to tp.c, but haven’t tested it yet. That’ll get more testing when I start using libsdl for a game.

At present I’m debating between two options — leaving tinypy as-is and just cleaning it up, thus using it as a C code generator. Or changing it into a bytecode generator and writing a simple VM to run the bytecode. Advantages and disadvantages as I see them:

C code generator:

  • Quite simple and reasonably fast. Optimizations and goodies come from the compiler.
  • Really swell “FFI” (all functions are accessed directly and available as functions in C. Really, this means, no notable FFI at all.)
  • No need to do much more than tweaking stuff, etc.
  • No “eval” unless I use tinycc. Even then, no “safety”.

Bytecode + VM:

  • I’d be able to implement exceptions and tracebacks and stuff
  • I’d be able to build a “safe” environment for running scripts “eval”
  • Things would be a bit slower, but not much
  • FFI would be more complex (but I could probably work around that by auto-generating some goodies for people)

I’ll have to think about it for a bit .. I might just try making a fun little game with tinypy as-is, and work to keep the FFI really clean. And if I feel like upgrading tinypy, try to do it in such a way as to not break my “clean” FFI.

If you care to take a peak: svn:// – ./run_julia to see the julia demo. Must have libsdl and libgc installed. It’s sort of slow, but if you want to see it “fast” set JIT_DISABLE = False at the top of

One Response to “64k tinypy – vm or no ..”

  1. Simon Says:

    One advantage of having a VM… is that there is more opportunity to skip the whole compile/link/execute step.