Note that because the effective address contains only the identifier of an entry in the segment table and the offset portion of the address, the effective address can have fewer bits than the virtual address. This is exactly how a 32-bit processor with a 32-bit effective address can have a larger virtual address — the virtual address is not restricted to the size of the processor’s registers. Even in this case, the effective address still can reference only a subset of the virtual address space without having the operating system reload the segment registers. Also note that, even though the virtual address may be larger than 32 bits, any single operation can still use only the 32 bits of addressability the processor provides. This means the 4-GB limitation is still there, no matter how many bits are in the virtual address — which explains why even systems that claim large virtual addresses are moving from 32-bit to 64-bit processors.

Now let’s contrast the segment-relative addressing we have been discussing in the last several paragraphs with the single-level store in the AS/400. The single-level store and the virtual address exist below the MI and are not visible to the user. There is, therefore, no need to force addresses through another level of translation (effective-to-virtual) to protect them. The protection is accomplished through the pointers we introduced in Chapter 5. We need to protect the pointers (with the tag bits), but we don’t have to add the additional processing overhead to load and store the segment tables for every program.

In an AS/400, the single-level store is also divided into segments, as we saw in Chapter 5 when we looked at the structure of objects. A major difference is that with the single-level store the large address in the AS/400 (either 48 bits or 64 bits) lets a program below the MI address any segment in the entire virtual address space, not just a subset of the segments, as is the case with the segment-relative addressing model. A program can access the entire virtual memory, and all the virtual memory can be shared with no additional processing overhead.

Overview of Single-Level Store

Before we jump head-first into the single-level store implementation, we need to look at an overview of the concepts and components to see how they all fit into the big picture. Then we can get into a discussion about why single-level store is so important to the AS/400 and look at some of the low-level details on exactly how it works. To help us picture what is happening as we go through these sections, let’s define a simple example. Suppose we have a program doing a sequential read to an indexed database file (this could be an HLL READ or an SQL FETCH). For this example, we would need to assemble a few objects (program, index, cursor, data space, and possibly a space or two) — some would be found in memory and some not.

Let’s start with a brief review of how these or any other objects are addressed. No distinction is made between memory and disk storage (or other auxiliary storage) above the MI. OS/400 thinks only of objects, their names, and their public contents. MI sees its objects (which are decompositions of OS/400 objects) by their identifiers (pointers). Objects otherwise are not located at the MI level.

Programs, cursors, data spaces, and other objects can be found simply by specifying the object’s name. An executing program need know only an object’s name and type (recall that library is optional because the library list will be searched if the library is not specified) to use it as a resource. The name, however, is quickly mapped into a virtual address. The virtual address of each named object is stored in the library that contains it. This address is loaded into a pointer as part of the resolve operation we described in Chapter 5. A system pointer, therefore, contains the virtual address of the object header (which may in turn contain pointers to other parts of the OS/400 object or to other associated MI objects).

For the contents of an object to be changed or referenced, or for instructions in a program to execute, they must be brought into memory. In our sequential database read example, the portion of the program that contains the actual instructions to perform the database read would first have to be brought into memory from disk before the instructions can be executed. This movement between disk and memory occurs below the MI, because the MI does not distinguish between memory and disk.

You can picture this movement in two different ways. One view is that all objects appear to be in memory. That the physical memory is too small to hold all objects is a limitation of current hardware technology. When a part of an object is needed but not found in memory, the missing part is brought in and replaces some unused portion of memory. Another picture is that memory is a set of screens used to view the vast space that holds all objects. The process of bringing pages in and out of memory can be thought of as changing the view in one or more screens.

Figure 8.1 on the following page illustrates how the objects are mapped into the virtual address space below the MI. In this figure, two objects, a program and a space, are shown to illustrate where the various parts of the objects are physically located. Very small objects are shown to simplify the figure, but the concepts are the same for any size object. Also shown are the two primary components of the SLIC storage management: auxiliary storage management and main storage management. Briefly, auxiliary storage management assigns the disk space to the virtual addresses of the object, and main storage management handles the movement between disk memory and main memory.

Figure 8.1  Objects in the Single Level Store

In the figure, we can see that memory is composed of page frames (the screens in the preceding analogy), which on IMPI machines are 512 bytes, but are now 4K (4,096 bytes) on PowerPC machines. These screens are called page frames, because they hold pages. The object on disk is divided into pages. Pages on disk are the same size as page frames in memory. A virtual address of an object implies a page on disk. This virtual address can designate any byte in the object space, so it could point to the middle of a page. A large object can occupy many pages, and by design, a single page can never contain parts of more than one object.