In a dusty bookshelf at work I found an ancient tome of wisdom, long abandoned by its previous owner. I was pointed to it by a fellow explorer of the dark arts of computer system design as something that you really should read. The book was “Fortress Rochester”, written by Frank Soltis, and published in 2001.
The book describes the state of the IBM iSeries machines as they were around the year 2000. I wrote a blog post a few years ago that outlines some of the impressive aspects of the “IBM i” as it is now known. “Fortress Rochester” gave much more insight into just how different a system the iSeries is compared to “conventional” system design. And I am still impressed by it.
The goal of the book is to describe just how the system actually works – with evident pride, the author describes how and why the iSeries looks like it does. It is not written as a historical expose, even though it does provide some insights into the past and design decisions from time to time. The author’s pride in the system makes some of the chapters a bit too boastful for my taste, but the details and information in the book makes it worthwhile to persist despite this. I honestly must say I understand where the author comes from on this, having written a book myself about a product I care deeply about.
The description of the evolution of the early Power and PowerPC architecture offered in the book was a real throwback to the late 1990s for me – the talk about “brainiacs” and “speed demons” (see for example this classic piece from ArsTechnica from 2001), and the advantage of the branch unit in the early PowerPC processors. It was relevant back then – but today, I guess we have only “fast brainiacs” left in processor land. I am old enough to get nostalgic about those old times when processors could still be understood.
There is a lot of material in the book, and I will highlight what I found was the most interesting.
It was great to gain more insight into the famed hardware-independence of the user-level program code in the iSeries. The fact that the Machine Interface (MI or TIMI) is backed by an ahead-of-time compiler from the machine-independent format to the actual host has made it possible to change the processor architecture used in the machines several times with no impact at all on the users. The change from the old S/38 processor to the PowerPC-based processor in the AS/400 was the only one I knew about – but it is in many ways even cooler that they changed the opcode mapping of the old S/38 processor between two generations in order to increase performance. That meant that they could use experience and data collected from the system to design a better instruction set – and deploy to existing customers without them noticing it. That is just so cool compared to how incredibly stuck we are with the legacy of encoding for the Intel, Power, ARM, and other traditional processor architectures. While ARM has launched a series of encodings over time and implemented various subsets in various particular cores, the true renovation of the mainstream ARM instruction set had to leverage the move to 64-bit to force their ecosystem to come along. In the iSeries, such an updated could have happened at any point in time, and users would not have noticed. Impressive.
However, at times even the iSeries MI is mortal – it is possible to delete the MI form of a program from a system entirely, making it necessary to recompile from source. This operation was apparently introduced to allow the much more limited S/36 systems to save disk space. Today, it is probably no longer needed as program size is not a problem on a modern system.
The naming of the software components of the S/38 and AS/400 system was a bit unusual, and for legal rather than technical reasons. If you look at the design of the system, the code that runs underneath the MI layer is quite similar to the kernel in a regular system. However, “OS/400” only really referred to the code that was above the MI layer. The code underneath was called “microcode” or “system licensed internal code” (SLIC). The reason for this was the 1960s legal decision to force IBM to unbundle their operating systems from their machines, which allowed the clone computer companies to build IBM-compatible hardware and still run the IBM-provided operating system software. For the much more integrated OS/400, this was a no-no. Thus, the core of the operating system was called “microcode”, to make it legally part of the hardware rather than the software stack. Sad to see legal issues make technical descriptions less logical than they should be – even though in this case the naming workaround ensured a uniquely designed system could still be built and sold in the way the designers intended.
The “single-level store” is the most interesting property of the iSeries. User-level programs only see a vast uniform address space, and use pointers to objects to manage code and data. Disks and RAM are handled by the OS completely transparently. Pointers are also global, and any program can share data with any other program in a very efficient way. Data protection is handled by objects, which means that there is no need for traditional MMU-based data protection. Which in turns makes task switching amazingly quick – the book claims that iSeries code typically switches between tasks after some 1400 instructions. In a regular OS, this would mean the OS would only be switching tasks – but the iSeries behaves more like a traditional single-memory-space real-time OS (RTOS) like VxWorks 5. There are known performance and efficiency benefits from having a single memory space, and the iSeries manages to provide that while still being entirely secure and enforcing protection around all data and code. The reason is that protection is part of the system object model, and supported by the hardware with a little bit of extra functionality not found in any other system.
The management of user-space pointers is really amazing. With a little bit of hardware support, the system actually notices if a user-level instruction (in native mode on the processor, obviously, following the MI compilation) changes a pointer. Using a special set of tag bits that associate one bit with each 16 bytes of memory, the OS underneath the MI layer will know if the user has tampered with a pointer. And refuse to use it if this is the case. This creates a situation where a user-level program really cannot do any harm – it cannot address outside of the objects it has access to, and it has no way to forge a pointer as the OS has a way to detect that! The iSeries design really shows how to build a secure by construction system, where all other OSes seem to try to patch security on as an afterthought. Still – the entire OS kernel beneath the MI layer is a trusted code base that has to be done right. Note that today when the iSeries is a software stack for Power Architecture-based IBM servers, the hardware support is part of the extensions to the Power Architecture that is used to support the iSeries.
The use of persistent never-reused object addresses for permanent objects in the system was really surprising – but it does solve many security problems and robustness problems in a neat way. Still, I should mean that shadows of every permanent object ever created will have to be kept around indefinitely in the file system. I really wonder how common such objects are, but with a 64-bit address space to fill, you have some 2 to the power of 40 possible addresses, which is quite a few indeed. It was also interesting to see that objects could be marked as “damaged”, in case the storage that they reside on developed physical faults. Another way to report “file could not be read”, but one that feels more civilized in a way.
Overall, the sense you get from reading the book and exploring the S/38, AS/400, iSeries and IBM i architecture is one of a very unique and uniquely well-designed computer system. The title “Fortress Rochester” is explained by Frank Soltis as referring to the special culture and relative isolation of the Rochester-based design team at IBM that built the S/38 and its successors. A team that does not necessarily take up whatever ideas are currently popular in the outside world, but rather started from customer needs and built a system to solve them. At the time the S/38 was designed, this meant not going for a UNIX-style system, but building something much more sophisticated and fundamentally different.
The IBM i is a beacon of hope –there is room for truly different designs in a computing world that far too often tend to simply borrow the standard concepts from existing designs. I suspect that something as radical as the S/38 would not have been possible to design today – there is too much anxiety about being truly different and not using standards. Fundamentally, it is fun with different solutions! A world where everything is just a variation on the same pattern is a boring world.