(footnote on 32-bit VMs)

As mentioned in the footnote on binary and hex, a bit is a binary digit: 0 or 1. A 32-bit number would therefore be one with 32 binary digits, somewhere between 0 and decimal 4,294,967,295. And virtual machines have already been discussed. But simply knowing what "32-bit" and "virtual machine" mean doesn't necessarily shed much light on what a "32-bit virtual machine" might be. With any luck, this footnote will.

Every computer has a certain amount of memory. Memory is where the computer stores information. Physically, this is in silicon chips, each chip containing many minuscule pieces of machinery that can flip between two configurations, one representing 0, the other representing 1: that is, a bit. Most computers have memory chips that group these bits into clusters of eight; each group of eight bits is called a byte, and can hold any value from 00000000 to 11111111, or 0 to 255. In addition to its value, every bit has an address. So when the CPU gets an instruction like "store the number 73 in location 12", it starts at the beginning of its memory and counts, "There's location 0, there's location 1, there's location 2..." and eventually gets to, "Ah ha, there's location 12." Then it sets the bits there to 01001001 (decimal 73).

When you run a virtual machine on your computer, the VM asks the computer to allocate some memory for the VM to use as its own. The VM calls each location in memory by its own name. The VM's name and the actual computer's name might not match; the interpreter takes care of the translation. So the VM command "store the number 73 in virtual location 12" gets translated into the OS command "store the number 73 in real memory location 12345" (or whatever the real equivalent of virtual location 12 is) and the virtual machine doesn't have to worry about the actual hardware being used -- it can just use its own names and let the OS handle the details.

VM instructions consist of opcodes (the thing to do) and operands (the thing or things to do it to). You might have a VM with the opcode "@add", for instance, that takes two operands: a virtual location, and a number to be added to the number in that location. So "@add(10101001,00010111)" would mean "go to location 10101001 (decimal 169, hex A9) and add 00010111 (decimal 23, hex 17) to whatever's there". Now, the Z-machine is a 16-bit VM, meaning that its opcodes are designed to take operands that are 16 bits long. This means that no location can have an address bigger than 1111111111111111, or decimal 65535 (hex FFFF). Even if your computer has many more available locations in its memory, the Z-machine can't use them because its opcodes can't name them.

An analogy: in the US, phone numbers in any given area code have the format XXX-XXXX. This means that there are, at most, ten million possible phone numbers in an area code: 000-0000 to 999-9999. (In practice there are even less, since some numbers are reserved.) Now let's say all the numbers in a certain area have already been assigned. You can still build a house in that area. You can still buy a phone and put it in that house. But you can't call that phone, because every number that you could give it has already been taken by some other phone. The only solution is to change the very format that phone numbers take in that phone system, so that there are more digits.

This is what a 32-bit VM like Glulx does. Glulx's opcodes take operands that are 32 bits long, and thus games using Glulx are able to claim, name and use not just 65536 locations in memory, but over four billion locations, with names ranging from hex 00000000 to hex FFFFFFFF. Thus, much bigger games can be created for Glulx than for the Z-machine.