The Z-machine opcodes for pushing and pulling values from the stack are @push and @pull, used like this: +
+ @push x; + @pull x; ++However for Glulx the opcode syntax is different: instead the @copy opcode is used: +
+ @copy x sp; + @copy sp x; ++The compiler now supports the @push and @pull syntax under Glulx as an alias for @copy, allowing +the same code to be used for both the Z-machine and Glulx. [C63104] +
Custom Glulx opcodes (such as opcodes that post-date the compiler) can now be specified with the custom opcode syntax. +The format of this syntax is +
@"FlagsCount:Code" ++Flags (which are optional) can include "S" for store, "SS" for two stores, "B" for branch format, +or "R" if execution never continues after the opcode. Count is the number of arguments (currently limited to 0-9), +and Code is a decimal integer representing the opcode number.
+For example, @"S3:123" is the syntax for a three-argument opcode (load, load, store) whose opcode number in decimal +is 123, and @"2:234" is the syntax for a two-argument opcode (load, load) whose number is 234. [C63107] +
When compiling to Glulx, the Glulx format version number of the resulting story file is usually determined by which Glulx opcodes +are used in the source code. This version number can now be over-ridden by providing a -v command line argument after the +-G switch to select Glulx mode. For example, the arguments +-G -v3.1.0 set the Glulx version number to “3.1.0”. [C63108] +
The Unicode related opcode added to the Glulx 3.0.0 specification, @streamunichar, is now supported. +
When compiling to Glulx, characters outside of the ISO 8859-1 range can now be used in strings. The maximum number of such +characters allowed is determined by a new memory setting, $MAX_UNICODE_CHARS. +
When compiling to Glulx, the syntax +
print (char) value;+now works for values greater than 255, printing the appropriate Unicode character. (For such values @streamunichar is used; +for those less than or equal to 255, @streamchar is used as before. +
The memory heap related opcodes added to the Glulx 3.1.0 specification (that is, +@mzero, @mcopy, @malloc and @mfree) are now supported. +
The acceleration related opcodes added to the Glulx 3.1.1 specification (that is, +@accelfunc and @accelparam) are now supported. There is also a new syntax to get the address of a global variable +var, with the expression “#g$var”: this is provided so that such addresses can be provided +to the @accelparam opcode. +
The floating point related opcodes added to the Glulx 3.1.2 specification (that is, +@numtof, @ftonumz, @ftonumn, @ceil, @floor, @fadd, @fsub, @fmul, +@fdiv, @fmod, @sqrt, @exp, @log, @pow, @sin, @cos, @tan, +@asin, @acos, @atan, @atan2, @jfeq, @jfne, @jflt, @jfle, +@jfgt, @jfge, @jisnan and @jisinf) are now supported. +
Floating point constants can be used in the Inform source code. Thes constants are expressed in the form “$+1.0e+1”: +that is, a dollar sign, followed by a plus or minus sign, followed by a floating point number, and then optionally a positive or negative +integer exponent. Inform does not attempt anything other than converting these constants to their 32-bit integer representation: there is +no constant folding as there is with integers, so the expression “$+1.0 + $+1.0” is not meaningful, and does not +produce the floating point value “2.0”.
+As an example of the use of these constants, the following adds together 100 and 123.45: +
@fadd $+100 $+1.2345e+2 result;+The compiler also defines the constants “FLOAT_INFINITY”, “FLOAT_NINFINITY” +and “FLOAT_NAN” for positive infinity, negative infinity and “not a number”, respectively. +
Glulx has a simple memory extension feature, where the game's header declares the memory space to be larger than the game file. +The extra space is filled out with zeroes when the game starts. This is now supported by a new option $MEMORY_MAP_EXTENSION. +This defaults to 0: if it is redefined to a larger value then the size of the game's memory space is extended by that amount. +
The number of verbs allowed by the compiler when compiling to Glulx is no longer limited to fewer than 256. As part of producing +the game file, the compiler creates a dictionary table that contains verb numbers. However, despite in Glulx there being space for a verb +number between 0 and 65535 in this table, only one byte of it (that is, values between 0 and 255) was used. This has been fixed.
+However, this also requires library changes to be useful, as the library makes use of this dictionary table. The library used by Inform 7 +has been adjusted to take advantage of this, but the Inform 6/11 library has not. +
The dictionary of Glulx games can now contain characters outside of ISO 8859-1. There is a new +memory setting, $DICT_CHAR_SIZE: by default this is 1, but setting it to 4 causes the compiler to create a dictionary containing +32-bit Unicode characters.
+However, this also requires library changes to be useful, as the library makes use of this dictionary table. +
Strict mode is no longer enabled by default when generating V3 and V4 Z-code files, as strict mode +makes use of opcodes that are V5+ only. [C63007] +
The base unit of Inform's internal memory allocation for various structures (for example the buffer used +to hold the generated code) is no longer fixed: it is now controlled by a setting $ALLOC_CHUNK_SIZE. +This allows, for example, the maximum Glulx code size to be greater than 640Kb. [C63102] +
When compiling to Glulx, the stack size of the resulting story file is no longer fixed at 4096: it can be changed +by the setting $MAX_STACK_SIZE. [C63108] +
The compiler could crash if the size of the grammar table exceeded the size of the Z-machine readable memory: this +is now fixed. [C63110] +
Creating a Z-code game file with precisely 64Kb of readable memory produced an invalid file. This is now prevented, +so that the largest readable memory size is 64Kb minus 2 bytes. [C63112] +
Previously, under Glulx the print_to_array() function could be called with either two arguments, specifying both +the array to print to and its length, or just one argument, the later matching what is allowed when compiling to Z-code. This +one argument form has now been withdrawn under Glulx as a security hole, and a source to problems with writing beyond the end +of the array: now the array length must be specified. (See also Features available only in Glulx.) +
Veneer routines are no longer excluded from Inform's assembly output (which is accessed with the -a +command line switch). +
For Linux and other Unix variants the default memory settings have been increased, which should remove the need +to change the compiler settings when building large projects on these platforms. +
For Mac OS X, the maximum length of a file path is now 8192 characters, which should prevent any further problems with +long paths on this platform. +
The Zcharacter directive causes the compilation error “Glulx Inform does not handle Unicode -yet”. The message, though true, is misleading; the real issue is that Glulx does not use the ZSCII -character set, which can in part be configured by various forms of Zcharacter. Your best approach -is to bypass the directive when compiling for Glulx: +
The Zcharacter directive causes a compilation error, since Glulx does not use the ZSCII character set. +Your best approach is to bypass the directive when compiling for Glulx:
#Ifdef TARGET_ZCODE; Zcharacter ... ; @@ -726,26 +822,25 @@Statements
settings which your game expects.Character handling
Unlike the Z-machine, which internally uses the ZSCII character set (see the Inform Designer’s -Manual Table 2 on p. 519), Glulx sticks to the ISO 8859-1 (Latin-1) encoding. This eight-bit scheme -is the same as ZSCII for character values 0-127, but different for character values 128-255. Note that -Glulx is built on the Glk I/O library, which currently does not handle Unicode characters (except -insofar as code points $0000 through $00FF are identical to ISO 8859). The impact is as follows: +Manual Table 2 on p. 519), Glulx uses strings consisting of either 8-bit characters in the ISO +8859-1 (Latin-1) encoding (which is the same as ZSCII for character values 0-127, but different for +character values 128-255), or 32-bit Unicode characters. In general you don't need to worry about +which string representation is used: the compiler will figure it out for you. The impact is as follows:
@escape_sequence: Escape sequences such as @:a and @LL -(for “ä” and “£” respectively) are -accepted identically by both VMs (except that Glulx does not handle @oe and @OE, because the -“œ” and “Œ” ligatures are outside the range of ISO 8859-1). +(for “ä” and “£” respectively) are accepted identically by both VMs.
@@decnum: The number is the character’s internal decimal value, so @@65 is “A” in both VMs, but @@165 is “ï” in the Z-machine and “¥” in Glulx.
@{hexnum}: The number is the character’s Unicode value, so @{41} is “A” and @{EF} is “ï” in both VMs. However, @{A5} is “¥” in Glulx, -but causes a Z-machine compilation error because “¥” isn’t a ZSCII character, and @{152} is -“Œ” in the Z-machine but causes a Glulx compilation error because that ligature is outside the range of ISO 8859-1. +but causes a Z-machine compilation error because “¥” isn’t a ZSCII character.
-Cn: The compiler switches -C1 through -C9 specify that the source file uses the character set defined by ISO 8859-1 through 8859-9 respectively. In the Z-machine, the switch also initialises the higher ZSCII character set to appropriate values; this later feature is irrelevant when compiling for Glulx. +
Dictionaries in Glulx Inform 6 games have to consist of only ISO 8859-1 characters at present. This is +being worked on, and the necessary compiler changes have been made, but further library work is still needed.
There is an extended form of print_to_array: +
For Glulx, print_to_array function requires two arguments, the first being the array to print to, +and the second the length of that array:
len = mystr.print_to_array(mybuf, 80);This example writes no more than 76 characters into the array. If mybuf is an 80-byte array, you can be sure it will not be overrun. (Do not try this with the second argument less than 4.)
@@ -991,17 +1087,17 @@
Class CompassDirection and its objects have been extensively revised. +
Routine LanguageVerb() has been reworked. +
Routines LanguageVerbIsDebugging(), LanguageVerbLikesAdverb() and LanguageVerbMayBeName() have been added to isolate language-specific tests previously embedded in parserm.h. -
Constants YOU__TX and COMMA__TX have been added. +
Routine LanguageLM() has been sorted alphabetically. +
In that routine, CommandsOff, CommandsOn and CommandsRead have been added. +
Also in that routine, Exit, Inv, Look, Miscellany, Places, Pronouns and Score have been extended, and Go has been modified. -
Constant LIBRARY_ENGLISH has been added. We suggest that translated versions instead define LIBRARY_DUTCH, LIBRARY_FRENCH, LIBRARY_GERMAN, LIBRARY_ITALIAN, LIBRARY_SPANISH, LIBRARY_SWEDISH etc, in case it becomes useful at some time to determine which language is in force. @@ -1010,19 +1106,12 @@
The grammars have been sorted alphabetically. +
Verb definitions 'recording' and 'replay' are no longer conditional on DEBUG. +
Verb definitions 'showobj', 'ask', 'exit', 'look' and 'tell' have been extended. +
Verb definition 'pry' 'prise' etc has been added. +
Constant LIBRARY_GRAMMAR has been added.