Advent
Advent copied to clipboard
Which version of Inform
I have cloned this repository, ran the build-vbcc.sh script and then changed to the ODWY0350, typed make and eventually obtained
$ make 2>&1 | head
cd z-machine ; inform -v8 -ew~S~X~D \$MAX_ARRAYS=700 \$MAX_ZCODE_SIZE=38000 \$MAX_STATIC_DATA=48000 Main.inf ../advent.z8
Inform 6.35 for Linux (22nd May 2021)
"advent.s", line 15: Error: Expected variable name or 'sp' but found (
> @loadw xp (0) -> (
"advent.s", line 15: Error: Store '->' destination not 'sp' or a variable: "("
> @loadw xp (0) -> (
"advent.s", line 15: Error: Expected expression but found )
> @loadw xp (0) -> (null)
"advent.s", line 15: Error: Assembly mistake: syntax is "loadw <operand1> <operand2> -> <result-variable>"
> @loadw xp (0) -> (null);
$ make 2>&1 | head -n20
cd z-machine ; inform -v8 -ew~S~X~D \$MAX_ARRAYS=700 \$MAX_ZCODE_SIZE=38000 \$MAX_STATIC_DATA=48000 Main.inf ../advent.z8
Inform 6.35 for Linux (22nd May 2021)
"advent.s", line 15: Error: Expected variable name or 'sp' but found (
> @loadw xp (0) -> (
"advent.s", line 15: Error: Store '->' destination not 'sp' or a variable: "("
> @loadw xp (0) -> (
"advent.s", line 15: Error: Expected expression but found )
> @loadw xp (0) -> (null)
"advent.s", line 15: Error: Assembly mistake: syntax is "loadw <operand1> <operand2> -> <result-variable>"
> @loadw xp (0) -> (null);
"advent.s", line 39: Error: Expected variable name or 'sp' but found (
> @loadw xp (1) -> (
"advent.s", line 39: Error: Store '->' destination not 'sp' or a variable: "("
> @loadw xp (1) -> (
"advent.s", line 39: Error: Expected expression but found )
> @loadw xp (1) -> (null)
"advent.s", line 39: Error: Assembly mistake: syntax is "loadw <operand1> <operand2> -> <result-variable>"
> @loadw xp (1) -> (null);
"advent.s", line 41: Error: Expected variable name or 'sp' but found (
> @loadw xp (0) -> (
It would appear the assembler output produced by vbccz is incompatible with the version of Inform I've installed, which is the current 6.35 release.
What version of Inform works? Is it easy to patch vbccz to generate output compatible with new versions of Inform 6?
Here's what I get (on Mac OSX):
$ make
gcc -std=c99 -O3 -pedantic -W -Wall -Wextra \
-Wno-switch -Wno-unused-result \
advent.c -o advent
../vbcc/bin/vc +z -c99 -O1 -DZ_MACHINE -DSAVE_AND_RESTORE -Iz-machine/include -c z-machine/cstubs.c -o z-machine/cstubs.s -module-name=libc
../vbcc/bin/vc +z -c99 -O1 -DZ_MACHINE -DSAVE_AND_RESTORE -Iz-machine/include -c advent.c -o z-machine/advent.s -module-name=advent
cd z-machine ; inform -v8 -ew~S~X~D \$MAX_ARRAYS=700 \$MAX_ZCODE_SIZE=38000 \$MAX_STATIC_DATA=48000 Main.inf ../advent.z8
Inform 6.34 for Unix (21st May 2020)
Compiled with 126 suppressed warnings
I suspect that this isn't a 6.34/6.35 difference; I suspect something's gone wrong with the way you create advent.s. For me, the first function in advent.s is:
[ _pct xp
r0
r1
r2
r3
r4
r5
;
@sub xp (4) -> xp;
@push r0;
@storew xp (0) sp;
@add (100) (0) -> r0;
@random r0 -> r0;
@sub r0 0+1 -> r0;
@loadw xp (0) -> sp;
@jl r0 sp ?L3;
@add (0) (0) -> r1;
jump L4;
.L3;
@add (1) (0) -> r1;
.L4;
r0 = r1;
@ret r0;
]
Notice that my line 15 is @loadw xp (0) -> sp;, whereas for you, it seems to be @loadw xp (0) -> (null);. Usually when a C program prints (null), that's because it's printf'ing a null pointer. This line of assembly is probably printed by line 1154 of z/machine.c:
fprintf(fp, "\t@loadw xp 0%+ld -> %s;\n",
offset >> 1, regnames[reg]);
This could very well be a latent bug deep inside vbccz. Maybe you could gdb it and figure out whether reg is holding garbage instead of 0 at that point (and then — the harder question — figure out why).
Fantastic! Your hint about working on Macintosh helped me solve the problem. Here is what I know:
- gcc version 10.2.1 on x86 Linux miscompiles vbccz. The resulting binary immediately segfaults.
- gcc vesion 8.3.0 on 32-bit ARM miscompiles vbccz. The resulting binary produces assembler output with (null) in it.
- clang version 12.0.0 on x86 Linux works!
Woohoo! I now have a working toolchain and a z8 file which plays adventure. Thanks for putting this archive up.
Interesting/scary. It would be nice to find out more about why it's being miscompiled by GCC.
FWIW, I would not be terribly surprised by miscompilation on 32-bit platforms and/or big-endian platforms. (Although I'd try to fix it if you could identify a specific line as the culprit.)
Also FWIW, "it works on my machine," on OSX, even with GCC:
$ gcc-10 --version
gcc-10 (Homebrew GCC 10.2.0_4) 10.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.