Thanks! You certainly could - did you try running the example I attached to my post? It’s not an interpreter, but it is a compiler…
(To @Dannii’s reply: for the example I just implemented stdio.h using Glk, so that I didn’t have to modify the original program. The hard part isn’t the actual I/O, but rather printf and its cousins, which I cheerfully grabbed from uClibc-ng.)
@jfmherokiller: if you want to plug in some ASCII-art renderer…
Glk’s graphics functions would let you port the full graphics of Doom, but the framerate might suffer. We won’t know how bad though until someone tries! I think it might be playable.
tbh I thought of using it more for like BigInt purposes.
I actually wrote an arbitrary-precision integer arithmetic library in I6 but never got around to writing proper documentation for it to be released. It allows up to 508 bytes of precision and supports all the basic operations, plus modular exponentiation and Montgomery arithmetic. I optimized it for Quixe and it’s decently fast, though for serious cryptography it’s hard to be as quick as one would like in pure Glulx (I ended up writing another extension to run such tasks in the background while waiting for user input…). Anyway, if it would be useful I can put it up somewhere.
Something I do wish which could be fun to pair up with this tool is a decompiler/disassembler for i6. I did find GitHub - wertercatt/mrifk: A decompiler and disassembler for the Glulx virtual machine. but it seems to have been forgotten.
The tool was also discussed here but that topic seems to have also dried up Reverse Engineering the Source Code from .gblorb - #23 by aschultz
I published the first version of my Glulxtoc decompiler earlier this year: if-decompiler/glulxtoc at master · curiousdannii/if-decompiler · GitHub
thanks I must havent seen that while going over the forum
Btw how did you handle more complex opcodes like simd or such?
ascii doom aside, back in the 8 bit age, there was text/character graphics adventures, esp. for the commodore line of 8b computers.
Thinking along this line, will be rather interesting (and useful…) an ANSI library for glulx.
(I’m wrong, or this was already done for the magnetics interpreter, a version being capable of render the art of Pawn/Guild/Jinxter in ANSI with nice results ?)
Best regards from Italy,
dott. Piergiorgio.
oh question: is the output of the compilation able to be “shunted” into a prexisting story?
Basicly can one compile “hello.c” and then import that into an inform7 project called “world”
Not conveniently, no, since the output is Glulx assembly code that expects to be a standalone program. You can put raw Glulx assembly into an I6 inclusion within an I7 project, but my backend uses glasm’s syntax, which is different from what I6 expects. You could modify the backend to use I6’s syntax, but it would be a nontrivial amount of work: for example global variables would need to be emitted as I6 arrays.
btw i saw this line " I’ll try to keep updated binaries for Intel Macs on the GitHub page; others are welcome to produce and distribute binaries for other platforms" on the github why not setup a production “pipeline” using something like appveyor, etc.
For the simple reason that I don’t know how to do it. If it’s easy to set up (i.e. I don’t need to do anything other than provide the CMake command) and you can send me a pointer to instructions, I’ll try it out.
If you want to render pictures on the console, you could use libaa, libsixel and the like.
Or have a look at this site here: Character representation of grey scale images
It explains how you can give users the illusion of greyscales by using ASCII characters that have gradually more pixels, called a “ramp”. This is the easiest way to render pictures on a console.
My personal ramp is this one: " .,-=oxOX@$" (note that it starts with a space)
I am rn seeing if i can setup some kind of basic setup
I got pretty close as seen here AppVeyor using this config file glulx-llvm/appveyor.yml at main · jfm535/glulx-llvm · GitHub
Thanks for putting this together! It looks like you’re hitting a 60-minute time limit that AppVeyor imposes, which isn’t surprising - I’ll ask them whether they can raise it for me.
another way besides raising the limit could be building it in parts eg each static lib which is then cached and sent to the next job.
Btw I will admit the moment I saw you basically only providing binaries for osx It spurred me into motion to attempt to fix that “issue”.
does the compiler have support of “va_start” and “va_end”?
Edit:
side note: since we don’t exactly have c++ support it may be possible to use this GitHub - JuliaComputingOSS/llvm-cbe: resurrected LLVM "C Backend", with improvements to convert c++ to c first.