4 ms·

ZIL is sometimes still used; there is a new implementation called ZILF. Also, I wrote a document called "The Tricky Document" which describes many new tricks fo

ZIL is sometimes still used; there is a new implementation called ZILF. Also, I wrote a document called "The Tricky Document" which describes many new tricks for Z-machine, most of which nobody has ever used as far as I know, which can allow even more efficiency than Inform and ZIL. I also wrote my own implementations of Z-machine, and other people who want to try, can also try to do so.

derefr 7y ago
Random awful thought: it wouldn't be that hard to write a Z-machine LLVM backend.
- crooked-v 7y ago
  From there it's only a short hop to compiling to WASM, too.
- zzo38computer 7y ago
  I thought of to have a LLVM backend to target Glulx. Some things are done easily enough; the ! operator of C corresponds to "ushiftr 1,$,$" in Glulx (this is using Glasm syntax). Calling conventions are simple. The Glk functions can be converted directly to Glulx code, with a few exceptions; the Glk type "S" means a different thing in C and in Glulx, although for most of them you can instead use ones that take an array and length, making the function to calculate the length before calling Glk. The C strlen() function becomes "linearsearch 0,1,$,1,-1,0,4,$" in Glulx. However, one thing with both Z-machine and Glulx is that there is no alloca(). However, you might be able to emulate it with a "shadow stack", I thought. (If programming in assembly language, this is not a problem since you can take advantage of those specific virtual machines instead.) Also, does LLVM support targeting 16-bit computers so well? (I don't know how to write a LLVM backend.) For Z-machine, one thing I thought might work better to compile into a Z-machine code might be a variant of BASIC instead. But when programming in Z-machine or Glulx, I just use assembly language; you can then run those programs on other computers anyways, so it wouldn't be as much problem. (Many of the tricks in "Tricky Document" assume the use of assembly language, although some could be implemented by optimizers.)

derefr 7y ago

Random awful thought: it wouldn't be that hard to write a Z-machine LLVM backend.

crooked-v 7y ago
From there it's only a short hop to compiling to WASM, too.
zzo38computer 7y ago
I thought of to have a LLVM backend to target Glulx. Some things are done easily enough; the ! operator of C corresponds to "ushiftr 1,$,$" in Glulx (this is using Glasm syntax). Calling conventions are simple. The Glk functions can be converted directly to Glulx code, with a few exceptions; the Glk type "S" means a different thing in C and in Glulx, although for most of them you can instead use ones that take an array and length, making the function to calculate the length before calling Glk. The C strlen() function becomes "linearsearch 0,1,$,1,-1,0,4,$" in Glulx. However, one thing with both Z-machine and Glulx is that there is no alloca(). However, you might be able to emulate it with a "shadow stack", I thought. (If programming in assembly language, this is not a problem since you can take advantage of those specific virtual machines instead.) Also, does LLVM support targeting 16-bit computers so well? (I don't know how to write a LLVM backend.) For Z-machine, one thing I thought might work better to compile into a Z-machine code might be a variant of BASIC instead. But when programming in Z-machine or Glulx, I just use assembly language; you can then run those programs on other computers anyways, so it wouldn't be as much problem. (Many of the tricks in "Tricky Document" assume the use of assembly language, although some could be implemented by optimizers.)