SLIC Roads Ahead
Question: What has more than 3 million lines of code, took 200 programmers to produce, and has a name that describes a Minnesota road in winter?
Answer: SLIC (pronounced “slick”). The internal code for the RISC-based systems is called System Licensed Internal Code (SLIC).2
2No doubt the developers who named this were thinking of the slang use of the word slick — which means wonderful, remarkable, first-rate — rather than a description of Minnesota roads in winter.
When Rochester began working on the RISC processor in 1991, many changes were required to the LIC below the MI. Some components had to be completely redesigned, while others were affected hardly at all. Much of the existing LIC also needed restructuring. This code had had frequent changes and upgrades through the many releases of the System/38 and the AS/400. Programmer productivity had declined, and maintenance had increased in this part of the system because of all the changes. Our programmers’ morale was also declining because of the need to continuously patch this old code.
We still had to deliver three major VLIC releases before the RISC processors arrived. There was no way we could stop work on the VLIC and switch all development to SLIC. So we decided to create a totally new organization in the lab to build the new operating system. The new organization would be free to pursue any development means it chose. Mike Tomashek, who headed this organization, met with his key developers to decide how to proceed.
The group considered two ways to approach the changes to the LIC. The first was to redesign and rewrite from scratch the low-level components affected by the processor change. The second was to attempt to move these affected low-level components to the RISC hardware with minimal changes. This type of migration without changing the program logic is often called porting. Any other components not affected by the processor change, such as the database, would be ported with as little modification as possible.
Mike and his team decided to redesign and rewrite the affected components from scratch. This was a difficult decision, because much of this low-level code was based on the original System/38 design, and it had been extensively tuned for performance over 15 releases of the system software. Many thought they could not accomplish the task of redesigning this low-level operating-system software in the short time they had. All the interfaces to the components being rewritten had to be preserved, while the internals were being completely changed. Changing interfaces would affect the ported components, which the team didn’t want to happen. To make matters worse, enhancements to all this software were still being made for planned AS/400 releases. They would be chasing a moving target.
Bill Berg, one of the members of the 10-person team that recommended PowerPC for the AS/400, was promoting object-oriented (OO) programming to improve the productivity of this effort. OO languages started to become popular in the late 1980s as a way to deliver programs quickly, and these languages had matured to the point they were usable for such a large project. Bill Armstrong and Dick Mustain were strong proponents of OO development, and they threw their support behind the effort. Paul Mattson joined the team and put together a plan to make it all happen. These technical leaders also argued this new programming technology would let us invest in our people and update their skills. And we would be able to recruit new people.
OO Concepts
Let’s briefly review the essential elements and terms related to OO programming. An object is a software entity that combines the data and the operations that can be performed on the data. The operation that an object can perform is sometimes called a method. The internal data structure and the methods of an object are hidden from the program. This is called encapsulation. The program can see only the interface to the object. OO programming is different from procedural programming because of this combining of operations and data into a single entity. Procedural programming keeps the operations and data separate.
OO programming is an approach that relies on software reuse; the primary mechanism for reuse is a class, which is a template that describes all objects that share the same operations and data elements. Thus, multiple objects can be created from one of these classes. This is often called an instance of an object.
New subclasses can be derived from an existing class through the use of inheritance. Inheritance allows programmers to create new subclasses that reuse the code and data in the base class without having to repeat them. Yet these new subclasses are customized to meet the specific needs of the application. Polymorphism is the ability of subclasses of the same class to respond to the same input message and produce different results. Polymorphism combines the concepts of inheritance and dynamic binding.
Sets of objects created from these classes and subclasses can be grouped together to provide the desired operating-system services. Once a fairly complete set of classes (called a class library) has been defined, programmers can use the classes to implement their component. There is no need to re-invent functions these classes provide.
For the team, however, there was a downside to using OO technology. The kernel of an operating system is very performance sensitive. Studies of AS/400 applications have shown that they tend to have long instruction-path lengths with a large percentage of that path length in the operating-system code. This means the performance of the code in the kernel of the operating system has a big impact on the overall system performance in an AS/400. Because OO technology involves reusing lots of small modules to accomplish a given function, the total path length tends to be longer than if the function had been written as a single entity. The team would have to include time in the development schedule to fine-tune these functions to ensure that the performance levels the old kernel functions had achieved through years of tuning was maintained.3
3Tuning the code in the SLIC would continue long after this RISC kernel was first shipped. With the delivery of V3R7, some customers saw as much as a 50 percent performance increase as a result of the tuning efforts. With V4R1, some system configurations saw another performance increase without requiring hardware changes. Tuning the kernel of any operating system is a never-ending process.