Mental Models

To start the course the concept of a Mental Model was introduced. A number of educators believe that all of us interact with our world through internal conceptualizations, or models, of how the systems around us function. From this point of view it is thus important that students be made aware of the mental models they hold about the topics they are learning, and it is important for instructors to help students hone these mental models so that they become increasingly more detailed and accurate.

A Riddle

A simple riddle was presented to illustrate the idea of a mental model:

A man sets out on a walk. He walks south 100 meters, east 100 meters, and north 100 meters. At that point he notices footprints that match those of his own boots and realizes that he is back at his starting point. Simultaneously he hears a noise and looks up to see a bear approaching him. What color is the bear?

This riddle is relatively easy to answer if one has a functional model of the earth that lets one recognize that there is only one place on earth where such a walk could be taken. Without a functional mental model of the earth, the riddle would be hard to unravel.

One of the key points about any mental model is this:

A mental model does not need to be detailed or completely accurate as long as it is functional.

Mental Model of a Computer

For example, a mental model of a computer need not be very detailed or accurate to suffice at the freshman level. Students can get along pretty well at that level with the simple concept of a computer as a device that carries out the instructions of a program. On the other hand, in order to understand operating system design, one must have a much more detailed understanding of how a computer works. Even at this level, though, it is not important to understand how some particular processor architecture works but rather to have a basic understanding of how a processor could work in order to make it possible to design an operating system. If one is ever called upon to write an operating system for a particular processor, though, one would then need to know just about every detail of the processor for which the operating system is to be written.

Computer Structure

In trying to answer this question the class arrived at a model of a computer that included:

• a processor
• a system address bus to which the processor and all peripherals are attached (the address on the bus refers to individual items connected to the bus as well as all RAM addresses)
• a system data bus for transferring values to and from the various components attached to the address bus
• a system interrupt bus that allows interrupts to be sent and received by the various components connected to the address bus

Processor Structure

To understand the issues involved in operating system control over all other programs that run on a computer, the processor must be examined. The mental model of a processor we arrived at included:

• a program counter (PC) register that holds the RAM address of the NEXT (not current) instruction to be executed
• an instruction register (IR) that holds the CURRENT instruction to be executed (each instruction must be fetched from RAM and placed in the IR, because the IR is connected to a complex circuit that decodes the binary contents of the IR and triggers the proper circuits in the processor to execute the instruction in the IR)
• general purpose registers that hold data values
• an arithmetic and logic circuit that can carry out the desired operations on the values in the general purpose registers (e.g., arithmetic on two registers).
• an instruction fetch and execute circuit that repeatedly fetches the next intruction from RAM, places it into the IR, and decodes and executes that instruction.

The Instruction Fetch and Execute Circuit

In order to understand operating system design we need a better model of processor instruction execution than we have developed to date. In particular we need to understand how the instruction fetch and execute (IFE) cycle of a computer works to make it possible to write a multi-user, multi-programming operating system. Until now, the following mental model of the IFE cycle has been sufficient to understand how a program is executed by a computer:

That is, until now, our mental model of a computer as a device that simply carries out the instructions of our programs one after another is not sufficient to understand the topic of this course: operating systems.

Operating Systems and the Processor of a Computer

An operating system is just a program.  A complex, clever program, but just a program after all.  The problem with the above mental model of the IFE cycle when learning about operating systems is that it allows no way for the operating system program to regain control and begin executing again once a user program is allowed to run by the operating system.  That is, if a user program goes into an infinite loop, for example, the instructions of that user program would continue to be fetched and executed with no end. 

Hardware Features that Support Operating Systems

The only solution is to have some features built into the hardware IFE circuit that ensure that the operating system will start running again after certain time interals.  That is, close cooperation is required between computer processor designers (computer engineers) and operating system designers (software engineers) to ensure that a computer is designed to run an operating system program properly. Indeed over the many years of processor development, a number of new hardware features have been built in to processors just to make it possible to design and implement operating systems that function as desired. The class engaged in a discussion at this point of how the IFE cycle could be designed to accommodate an operating system. The discussion was based around this question:

How is it possible for a large number of students sitting at terminals in a lab who are all using the same central computer to all be able to work as if they were the only ones using the computer. In particular, if one of the students is running a program with an infinite loop in it, how is it that the other students don't even know?

Interrupts and an Interval Timer with Interrupt Capability

We came up with an upgraded IFE circuit that always checks the interrupt lines at the end of each instruction fetch and execute cycle. If the circuit detects an interrupt, it:

• stores the current PC value so that the currently running program (which is about to get interrupted) can be restarted where it left off later
• puts a new address into the PC (presumably the address of the first instruction in the operating system of the interrupt handling routine)
  

This will allow the operating system to regain control, handle the interrupt, and decide what to do with the program that got interrupted. Thus, our IFE cycle model is now changed to look as follows.

So, an answer to our question about how the operating system can regain control from a user program can be answered this way: The computer engineers can build a clock, or countdown timer, into the processor that the operating system can set each time it starts or resumes a user program. When that timer reaches zero, it can set a bit that indicates that the timer interrupt has occurred. That interrupt is noticed in the IFE cycle as shown above, and control is returned to the operating system by virtue of the new address stored in the PC register.