4

Forgive me if this is a silly question, but I'm wondering if/how LLVM could be used to obtain a higher performance Z-Machine VM for interactive fiction. (If it could be used, I'm just looking for some high-level ideas or suggestions, not a detailed solution.)

It might seem odd to desire higher performance for a circa-1978 technology, but apparently Z-Machine games produced by the modern Inform 7 IDE can have performance issues due to the huge number of rules that need to be evaluated with each turn.

Thanks!

FYI: The Z-machine architecture was reverse-engineered by Graham Nelson and is documented at http://www.inform-fiction.org/zmachine/standards/z1point0/overview.html

bcat
  • 8,833
  • 3
  • 35
  • 41
user319411
  • 41
  • 1
  • 1
    "Apparently"? It either has performance issues or it doesn't, Trying to achieve better performance without first being able to pinpoint the current performance bottlenecks isn't likely to gain you anything. – jalf Apr 17 '10 at 21:37

2 Answers2

2

Yes, it could be. A naïve port of the interpreter to the a compiler could be done relatively easily.

That said, it wouldn't be a big performance win. The problem with any compiler for ZCode or Glulx is that they're both relatively low-level. For instance, Glulx supports indirect jumps and self-modifying code. There's no way to statically compile that into efficient native code. Making it truly fast would require a trace compilation or something similar.

Resistor
  • 508
  • 3
  • 7
  • Note that self modifying code will be restricted to the RAM section of the Glulx memory space, and in practice is almost never used. I haven't heard of a single Glulx file that uses it, I'm not even sure if the Glulx unit tests do. So an interpreter could just decide to throw an error instead of handling it, or it could bundle a JIT. Indirect jumps can be handled through a relooper (like Emscripten's). – curiousdannii Jul 29 '20 at 06:02
1

It would certainly be possible (but difficult) to use LLVM as a kind of JIT for Z-machine code, but wouldn't it be easier to simply compile the Inform source directly to a faster language? Eg, C for maximum speed, or .NET or Java if you prefer portability. I would suspect this route would be a lot easier, and better performing, than just jerry-rigging a JIT onto the side of the interpreter.

bdonlan
  • 224,562
  • 31
  • 268
  • 324
  • That should be quite possible, at least with other byte codes. Inform can already target Glulx (a newer VM somewhat similar to the Z-machine), so I don't see how targeting the JVM or CLR would be that much of a stretch. As for compiling to a high-level language like C, I suppose that should be doable as well. – bcat Apr 26 '10 at 05:53
  • 1
    Unconditional jumps would make it difficult to compile to a high-level language. Also, while I have never seen it, it's possible to alter routines during runtime. – mdm Jun 06 '11 at 22:07
  • @mdm, self-modifying code would indeed be a problem, but you could solve jump issues by just compiling it to a huge single function with gotos for flow control – bdonlan Jun 07 '11 at 20:27