Good. Thank you.
This is the feature that interests me the most. Has the code been written in a way that would allow additional target languages to be added?
Yes, the new Inform7 code produces a “neutral”/abstract intermediate representation (IR) called Inter that can be compiled into or interpreted by many different frontends. See Using Inter for details.
Whose is the same frontend/backend technique used by the GCC compiler suite.
Inter can open new crosscompiling possibilities between IF languages and story file formats, for example, generating a glulx story file from TADS 3 or Alan 3 source, or generating TADS2/3 story file from Hugo or even Inform 6/7; of course, one can write front-end for general-purpose languages, esp. FORTRAN…
Best regards from Italy,
I did wonder whether it would also be possible to pass other IF languages through Inter, but I would imagine that they have less in common with each other than general programming languages do.
From what little I have read about the new Inform system, there are five stages of compilation before Inter, which would need to be rewritten for whatever other IF language was used.
Most of those five stages are specific to Inform, though. I6 only requires a single fairly-straightforward translation stage (called “assimilation”) to turn it into Inter.
Something like TADS or Dialog would of course take more, because Inter is specifically designed to be closely compatible with I6 (look at its list of primitives). But probably less than the full five needed for I7.
And as a side effect, since Inter is pretty close to I6 in choice of primitives and I6 is pretty close to the Z-machine in that same choice, it shouldn’t be too difficult for anything that currently compiles to the Z-machine (Dialog, ZILF) to compile to Inter instead, and then to Glulx or C or whatever. Inter does have some higher-level control constructs (like loops) but also supports labels and branches, so you could absolutely use it as an elaborate syntax for Z-machine assembly.
(Which does make me wonder about the feasibility of a Z-machine-to-Inter decompiler. Certainly easier than Z-machine-to-I6; I’d have to look at the standards again to figure out if any particular features would pose a problem.)
For the adventurous (and the impatient) among you, the latest state of the Windows Inform 7 IDE can be successfully built from source as described on GitHub. It’s pretty straightforward to integrate with the compiler too. My thanks to David Kinder for his help getting this to work.
I don’t think there’d be too much difference really.
The biggest complexity with decompiling Z-Code is the same one I tried to tackle in Glulxtoc - turning branches and jumps into loops and if/else/switch statements. Or you just don’t try, and output spaghetti code instead. In both cases Inter and I6 look roughly comparable to me.
The one difference would maybe be for laying out memory? I6 wants to fill the RAM with its own stuff, so you’d have to patch addresses to work around that. Maybe with Inter it’s able to have more control over the RAM, so you could just copy it more directly?
I think inter might make a viable interchange format for other Z-machine or Glulx tools, yes. One advantage of that might be that any inter code produced by Dialog or ZILF could then be linked with kits written in Inform 6 syntax and compiled with the inter tool - so one could then have code written in Dialog calling a function written in I6, for example.
I just wanted to thank you for all the hard work that you (and others) have put into rewriting Inform and releasing it as open source.
I was able to build the Windows IDE, but can’t figure out how to integrate the new compiler. Trying to run a project just results in the IDE trying to use a nonexistent exe in the Build/Compilers folder. Copying in the inform7.exe from a build of it just results in it failing to find other files it’s expecting to have near it. What did you do to get this working?
See the following issue on GitHub for a full description.
Thanks, I have it working now!
I have not followed the whole thread here, but just saw this flutter by in the regular forum update emails. But, in any case I felt I wanted to chip in my two cents in support of this view.
I come back to IF irregularly, and after every 5 years or so, the tools have moved forward. Nothing odd there, or bad at all. But, I feel one of the excellent qualities of how it used to work way back in the days, is less of a concern these days. I’m talking about portability and platform agnostic solutions to play the games. One of the wonders of the Z-machine was that I could play my games on any kind of device imaginable. I’m afraid the community is loosing touch with that quality. Not everyone has a fancy Pear shaped computer of the latest model.
I would argue that you can still make an interesting piece of IF on the z3 platform, definitely on the z5 one and if you can not on the z8 you are not trying hard enough!
It’s not just about loosing touch with history, but also usability.
Now you can all go forward and advance into the platform of the future and ignore me, but I had to put that out there.
Whilst on the subject of producing games for multiple platforms, does anyone know if the C code produced by Inter would work with SDCC or similar compilers for retro machines?
Inform’s C output wants wchar_t to be 32 bits. So far as I know, 8-bit or 16-bit architectures are non-starters.
I thought Inter C output was supposed to follow the C99 standard, which is from 1999? That’s only a year after Windows 98 was released, which was definitely not 32-bit.
SDCC does support long (32-bit, 4 byte) and long long (64-bit, 8 byte) according to their home page. I don’t remember enough about C to know if they could be used instead.
Windows 98 was most definitely 32 bit - but we are getting off-topic.
On topic, the wchar_t size is implementation defined, which means the compiler can use what is appropriate. Typically it is 16 or 32 bit on modern systems. A quick search points to SDCC using a 32 bit wchar_t, at least in some targets: https://github.com/svn2github/sdcc/blob/master/sdcc/device/include/stdlib.h#L42-L45
That sounds promising.
Inform would be much less appealing to me if it didn’t continue to support 8-bit machines in some way.
It does… by compiling to z-code.