z/OS concepts
Previous topic | Next topic | Contents | Glossary | Contact z/OS | PDF


A brief history of virtual storage and 64-bit addressability

z/OS concepts

In 1970, IBM® introduced System/370™, the first of its architectures to use virtual storage and address spaces. Since that time, the operating system has changed in many ways. One key area of growth and change is addressability.

A program running in an address space can reference all of the storage associated with that address space. A program's ability to reference all of the storage associated with an address space is called addressability.

System/370 defined storage addresses as 24 bits in length, which meant that the highest accessible address was 16,777,215 bytes (or 224-1 bytes). The use of 24-bit addressability allowed MVS/370, the operating system at that time, to allot to each user an address space of 16 megabytes. Over the years, as MVS/370 gained more functions and was asked to handle more complex applications, even access to 16 megabytes of virtual storage fell short of user needs.

With the release of the System/370-XA architecture in 1983, IBM extended the addressability of the architecture to 31 bits. With 31-bit addressing, the operating system (now called MVS™ Extended Architecture or MVS/XA™) increased the addressability of virtual storage from 16 MB to 2 gigabytes (2 GB). In other words, MVS/XA provided an address space for users that was 128 times larger than the address space provided by MVS/370. The 16 MB address became the dividing point between the two architectures and is commonly called the line or boundary (see Figure 1).

Figure 1. 31-bit addressability allows for 2-gigabyte address spaces in MVS/XA

The new architecture did not require customers to change existing application programs. To maintain compatibility for existing programs, MVS/XA remained compatible for programs originally designed to run with 24-bit addressing on MVS/370, while allowing application developers to write new programs to exploit the 31-bit technology.

To preserve compatibility between the different addressing schemes, MVS/XA did not use the high-order bit of the address (Bit 0) for addressing. Instead, MVS/XA reserved this bit to indicate how many bits would be used to resolve an address: 31-bit addressing (Bit 0 on) or 24-bit addressing (Bit 0 off).

With the release of zSeries® mainframes in 2000, IBM further extended the addressability of the architecture to 64 bits. With 64-bit addressing, the potential size of a z/OS® address space expands to a size so vast we need new terms to describe it. Each address space, called a 64-bit address space, is 16 exabytes (EB) in size; an exabyte is slightly more than one billion gigabytes. The new address space has logically 264 addresses. It is 8 billion times the size of the former 2-gigabyte address space, or 18,446,744,073,709,600,000 bytes (Figure 2).

Figure 2. 64-bit addressability allows for 16 exabytes of addressable storage

We say that the potential size is 16 exabytes because z/OS, by default, continues to create address spaces with a size of 2 gigabytes. The address space exceeds this limit only if a program running in it allocates virtual storage above the 2-gigabyte address. If so, z/OS increases the storage available to the user from two gigabytes to 16 exabytes.

A program running on z/OS and the zSeries mainframe can run with 24-, 31-, or 64-bit addressing (and can switch among these if needed). To address the high virtual storage available with the 64-bit architecture, the program uses 64-bit-specific instructions. Although the architecture introduces unique 64-bit exploitation instructions, the program can use both 31-bit and 64-bit instructions, as needed.

For compatibility, the layout of the storage areas for an address space is the same below 2 gigabytes, providing an environment that can support both 24-bit and 31-bit addressing. The area that separates the virtual storage area below the 2-gigabyte address from the user private area is commonly called the bar or boundary, as shown in Figure 3. The user private area is allocated for application code rather than operating system code.

Figure 3. Storage map for a 64-bit address space
0 to 231
The layout is the same; see Figure 3.
231 to 232
From 2 GB to 4 GB is considered the bar. Below the bar can be addressed with a 31-bit address. Above the bar requires a 64-bit address.
232 - 241
The low non-shared area (user private area) starts at 4 GB and extends to 241 .
241 - 250
Shared area (for storage sharing) starts at 241 and extends to 250 or higher, if requested.
250 - 264
High non-shared area (user private area) starts at 250 or wherever the shared area ends, and goes to 264.

In a 16-exabyte address space with 64-bit virtual storage addressing, there are three additional levels of translation tables, called region tables: Region third table (R3T), region second table (R2T), and region first table (R1T). The region tables are 16 KB in length, and there are 2048 entries per table. Each region has 2 GB.

Segment tables and page table formats remain the same as for virtual addresses below the bar. When translating a 64-bit virtual address, once the system has identified the corresponding 2-GB region entry that points to the segment table, the process is the same as that described previously.





Copyright IBM Corporation 1990, 2010