The original System/38 processor hardware had a 16-bit data path and a 16-bit adder for computation. The idea behind the 32/16 view of the address was to keep the 16-bit offset portion of the address in this data path because it is updated very frequently. We decided to keep the 32-bit SID outside of the processor data path in a separate set of SID registers. These SID registers could be accessed by the processor, but they could not be updated in place.

The programmers responsible for the operating system software beneath MI, originally called the VMC, did not agree with the 32/16 view of the address. They felt the 64K segment size was too small. An initial thought was that they would create segment groups, each containing one or more of these 64K segments. In the end, however, they decided the segment group should always have 256 of the 64K segments. Whenever a new segment was assigned as part of a newly created object, the segment size was always 16 MB (256 × 64K = 16 MB). In effect, the VMC programmers created a second segment size of 16 MB. From that point on, we talked about 64K and 16 MB segments, although sometimes we would call this latter size a segment group. This ambiguity in the definition of a segment and a segment group would continue until we introduced the PowerPC processors with SLIC. If you want to get out your calculator or your powers-of-2 table, you will see that with the 16 MB segment size, the VMC programmers began to look at the 48-bit address as having a 24-bit SID and a 24-bit offset, since 2²⁴ = 16 MB.

This 24/24 view of the address used by the VMC did not match the 32/16 view used by the hardware. This was a problem because of the way an overflow out of the offset portion of the address was handled. From our previous look at objects, we know they are made from one or more noncontiguous segments, and no segment can contain parts of more than one object. It should be clear that we do not want to have an address offset incremented beyond the end of one segment into the next segment. That next segment may be part of a different object. For example, we do not want to have the address in a space pointer incremented beyond the end of the associated space in an object. The way to detect this address overflow is to watch the offset portion of the address whenever it is incremented to see whether there is a carry out of the offset into the SID. Such a carry would indicate that we are trying to address something in the next segment.

Hardware is very good at detecting and reporting these overflows. The mechanism used to report such an occurrence in the hardware is an exception. We discuss exceptions in Chapter 9, but one is of interest to us now: the effective address overflow (EAO) exception. This exception was defined for the System/38 to report whenever an overflow occurred out of the 16-bit offset. When this EAO exception occurred, the hardware did not increment the 32-bit SID portion of address. Instead, it reported the exception to the VMC.

The VMC had to look at every EAO exception to see whether it was a problem. Because the VMC considered the segment to be 16 MB long, made up of 256 of the smaller hardware segments, an overflow out of a 64K segment in the middle of the 16 MB segment was not a problem. With its 24/24 view of the address, the VMC recognized an overflow only out of the low 24 bits into the high 24 bits. For each EAO exception, the VMC had to increment the 32-bit hardware SID, check to see whether there was an overflow into the high 24 bits, and if not, pass control back to the hardware. The VMC software had to constantly deal with this 32/16 versus 24/24 mismatch.

As time went on and the processor data path width grew from the original 16 bits to 32 bits and then to 48 bits, the separation of the SID and offset registers in the hardware became less important. For the AS/400, instructions were added to the IMPI to support the 24/24 view of the address, so the AS/400 did not have to handle this in the software. For compatibility with the original VMC, however, the 32/16 view had to be retained at the IMPI.

The original VMC had another problem with addresses. It had to support the 64-bit address in the MI pointer with a 48-bit hardware address. We could have tried to treat the 64-bit address as a larger virtual address, which somehow got mapped into a smaller 48-bit virtual address, but we chose not to do this. Instead, we decided to treat the high-order 16 bits of the 64-bit address as a separate value. We called this 16-bit field the SID extender. For the value in the SID extender, we chose the IPL number. Every time the system was IPLed, we incremented the IPL number by one. This gave us a new 48-bit address space at each IPL. Figure 8.2 shows the fields that make up the 64-bit address in the original MI pointer.

Figure 8.2  Original Format of an MI Pointer Address

Originally, the segment header described back in Chapter 5 had another field that contained the 16-bit SID extender for the segment. When an MI program attempted to use a pointer in the System/38 and the early AS/400 models, a special IMPI instruction was used to check the tag bits and to load the 48-bit address into a processor register. This instruction was called Load and Verify Tags (lvt). The lvt instruction was analogous to the lq instruction in the RISC processors, but the lvt instruction had an additional responsibility. It had to compare the high-order 16 bits of the address in the pointer to the SID extender field in the segment header. This compare would guarantee that the high bits in the pointer address matched the address of the segment. After that first access, only the 48-bit address was used to access the segment.

Every time we incremented the IPL number, we got a new address space for temporary objects. Temporary objects are destroyed at IPL time — not so for permanent objects. Permanent objects exist across IPLs. Because the hardware used only 48 bits, the same 48-bit address could not be used for two permanent objects. The 48-bit address can be reused only if the permanent object that previously had the address was explicitly destroyed in an earlier IPL. Only the headers are kept when a permanent object is destroyed. The headers were found when the full 64-bit address (which has the IPL number in the first 16 bits) in the pointer was first used. There is no conflict with reusing the 48-bit address as long as only the headers exist for the previous permanent object and the IPL numbers are different. Note that only headers for destroyed permanent objects are kept — nothing is kept when a temporary object is destroyed.