1879: Everything is a Job
Analytical Engines are the clockwork mainframes of the game world, but what does that actually mean? What is a mainframe, other than a thumping great computer that takes up the whole room? Unless you’ve a background in information technology from before the days of server farms, meaning you’re a fossil like yours truly the line developer, you’ve probably never logged into a TSO session, and probably don’t even know what one is or why you’d want to do that. Byrons, though, and their white-hat cousins the Lovelaces, spend their days and/or nights working with just these things precisely. If you’re playing a Byron, you may just be making the occasional Engine Programming Test to pop your code in and get the bank’s Engine to move a few thousand quid into your dummy account, then wire it off to a collection point in a country with no extradition treaty with the Empire. But would you like to know what is actually going on in there? Let’s take a look at the game world version of the Analytical Engine, based off a mish-mosh of Babbage’s design, the logical extrapolations for version 2, and some concepts drawn from MVS, a real world mainframe operating system created by IBM.
Image shamelessly borrowed from Sydney Padua’s website 2D Goggles, and specifically from her treatise on the Marvellous Analytical Engine – How It Really Works. Do go visit it. Sydney’s work is of such a calibre as to be considered a primary reference.
The larger part of the Engine is the Store, which is roughly equivalent to what today we call RAM or memory, and what used to be called core. This is where the data lives, in row after row of spindles, each fitted with dozens of tiny cogs with ten teeth each, numbered zero to nine. Today’s computers work in binary, based on the idea of an electrical signal, which is either on or off, one or zero. The Engine, being mechanical, isn’t restricted to just two states, and so it works in base ten numbers just like humans do. Each spindle is effectively a memory location, a place where a number of many digits can be kept. Now, the Byron could, and sometimes does, use direct memory addressing, specifying exactly which spindle and possibly even which cog is to be set or read, but why bother with that when you can refer to the location by a pointer, a variable that holds the location of the data you need? All you require then is the name of that variable, which can be determined from the code that is currently running.
Ah, but how does code run on the Engine? That happens in the Mill. In the original design, Babbage specified three sets of punchcards, one to hold the data, one to hold the variables (being only the Store pointers) and one for the operation codes (opcodes), also known as the program. Today’s modern Engine uses two sets of cards, one with the opcodes and one with the data set, with the variables embedded in the opcodes. The Mill contains a good deal more than just the mechanisms for carrying out the opcodes. There’s a smaller version of the Store built into the Mill, for holding the complete opcode set and the current working data. As well, there’s a set of mechanisms with separate internal storage for queuing up the jobs and making sure that everything gets processed in order.
And here, the Byron finds the part of the system that they most want to ingratiate themselves to. Like the receptionist, or the secretary, or the floor steward at the factory, the job entry system controls access to the rest of the Mill, and can let the Byron in, or shut them out entirely, simply by denying them an initiator. Everything, to an Engine, is a job. It processes sequentially, one batch of data at a time, none of your fancy parallel multithreading here. The Mill, like a tireless factory worker, sets itself to the job put before it, and completes that job, and sends it on its merry way, then asks the job entry system for the next piece of work needing done. The job entry system, having queued up the waiting work by hanging each piece on an initiator like a carcass hung on a hook in a meat processing plant, slides the next cow into the Mill for disassembly and packaging. Convince the job entry system that you’ve got pukka business with the Mill, and it will grant you an initiator, allowing you to create a job and send it into the Mill. Annoy the job entry system, perhaps by not having the right budget code for your processing time (oh yes, processor cycles cost money, every turn of the Mill puts wear and tear on all those moving precision-machined and oh so expensive parts), and your job gets sent down the priority queue to the end of the line, and maybe it gets done tomorrow. Cozy up and offer a bouquet of priority authorisation codes, and your job is the next one up for processing.
Those lovely stacks of cards that hold the opcodes for the fancy accounting software might not be so easy to nobble. You’d have to get round the checksums, numbers derived from the count of cards and values of the opcodes as alphanumeric characters, that are read in usually as the first card of the data set, in order to prevent you slipping in a couple of extra cards with opcodes of your own, or replacing a card in the middle of the set with your own instructions. If your Byron can once again convince the job entry system, in this case that a patch or upgrade or maintenance code needs to be applied, and supply the proper authorisation for the same, then the next set of cards in the hopper gets read in, substitutions are made in the opcode residing in the Mill’s working storage, and Bob’s your uncle.
If you want to know more about Babbage’s work, and find a wealth of material for deep geekery in playing a Byron, I strongly recommend visiting the Analytical Engine site at Fourmilab. You can also visit Sydney Padua’s list of primary documents, and of course you will want to purchase her book, The Thrilling Adventures of Lovelace and Babbage.
Tally Ho!