Z/Architecture

IBM z/Architecture
Company type	Instruction set architecture
Industry	Computer architecture, Mainframe computing
Founded	2000; 26 years ago
Founder	IBM
Products	IBM z900, z800, z990, z890, System z9, System z10, zEnterprise 196, zEnterprise 114, zEC12, zBC12, z13, z14, z15, z16, z17
Website	www.ibm.com/it-infrastructure/z/architecture

z/Architecture, originally known as ESA Modal Extensions (ESAME), represents IBM's 64-bit complex instruction set computer (CISC) instruction set architecture designed for its mainframe systems. The inaugural z/Architecture platform, the z900, was introduced by IBM in 2000. This architecture has since been implemented in a series of models including the IBM z800, z990, z890, System z9, System z10, zEnterprise 196, zEnterprise 114, zEC12, zBC12, z13, z14, z15, z16, and z17.

The architecture ensures backward compatibility with earlier systems, supporting 32-bit data and 31-bit addressing from ESA/390, as well as legacy architectures dating back to the 32-bit data and 24-bit addressing of System/360. The IBM z13 marks the final model capable of running operating systems in ESA/390 mode. Despite this, all applications developed for the original ESA/390 24-bit and 31-bit environments continue to operate without disruption.

Features

Nearly all capabilities of ESA/390 are preserved within z/Architecture, with certain exceptions such as the asynchronous-pageout and vector functionalities, which were superseded beginning with the IBM z13. Notable features include:

Channel subsystem design derived from S/370-XA
Branch instructions utilizing 16-bit signed relative offsets
Long relative branch instructions with 32-bit signed offsets
Support for three addressing modes: 24-bit, 31-bit, and 64-bit
Sixteen 32-bit access registers (ARs) inherited from ESA/370
Sixteen general-purpose registers (GRs), each 64 bits wide
Sixteen control registers (CRs), expanded from their original 32-bit size in System/370 to 64 bits
Sixteen floating-point registers (FPRs), each 64 bits
Thirty-two vector registers (VRs) of 128 bits each, where VR0 through VR15 overlap with FPR0 through FPR15
A single 32-bit floating-point control register (FPC)
A program-status word (PSW) sized at 128 bits that includes a 64-bit instruction address
An 8-KiB prefix storage area (PSA)
Integrated cryptographic facilities
Instructions supporting IEEE binary and decimal floating-point operations

For comprehensive timelines on feature introductions, refer to the Principles of Operation documentation.

Extended-immediate facility

This facility incorporates instructions that accept immediate operands of both signed and unsigned 32-bit values. It includes operations such as Find Leftmost One and various load instructions like Load and Test.

General-instructions-extension facility

Adds around thirty new instructions encompassing compare-and-branch, compare-and-trap, load variants including Load and Test, as well as store operations.

High-word facility

Introduces instructions that operate specifically on the high-order word within a 64-bit general register.

Long-displacement facility

Enables instructions capable of handling a signed displacement extended to 20 bits; examples include LAY.

Miscellaneous-instruction-extensions Facility 1

Facility 1 enhances the instruction set by adding:

Compare logical and trap instructions (CLT and CLGT)
Rotate then insert selected bits operation (RISBGN)

Miscellaneous-instruction-extensions Facility 2

Facility 2 provides additional instructions including:

Branch indirect on condition (BIC)
New arithmetic instructions for addition, multiplication, and subtraction

Miscellaneous Instruction Extensions Facility 3

Facility 3 introduces the following capabilities:

And with complement operations (NCRK, NCGRK)
Move operations from right to left (MVCRL)
Not and operations (NNRK, NNGRK)
Not exclusive or operations (NXRK, NXGRK)
Not or operations (NORK, NOGRK)
Or with complement operations (OCRK, OCGRK)
Select instructions (SELR, SELGR)
Select high instructions (SELFHR)

Vector Facility

The z13 brought forth a 128-bit Packed SIMD "Vector Facility" starting with revision 15 of the z/Architecture ISA. It provides 32 vector registers, each 128 bits in width; these overlay the existing 16 floating-point registers. More than 150 new instructions accommodate integer, floating-point, and string data types. The z13 architecture incorporates two separate SIMD units dedicated to vector processing. This Vector Facility is distinct from the earlier IBM 3090 Vector Facility last documented in ISA version 11.

Neural Network Processing Assist Facility

The z16 introduced the Neural-network-processing-assist facility, which adds instructions tailored for model-specific data types—most notably the 16-bit NNP-Data-Type-1 format. These instructions facilitate tensor computations essential for AI and neural network tasks.

Registers

Each processor is equipped with several critical registers that play a key role in business computing efficiency:

Access registers
Breaking-event-address register (BEAR)
Control registers
Floating-point Control (FPC) register
Floating-point registers
General registers
Prefix register
Program status word (PSW)
Vector registers

Access Registers

Each CPU contains sixteen 32-bit access registers. In AR mode, when a program references registers 1 through 15 as base or operand registers containing addresses, the processor uses the corresponding access register to perform address translation.

Breaking-event-address Register (BEAR)

The BEAR is a 64-bit register that holds the address of the most recent instruction that interrupted normal sequential execution. During interrupts, the BEAR is saved at real address hexadecimal 272. Following an Execute of a branch instruction, the BEAR contains the execute address rather than that of the branch itself.

Control Registers

The set of sixteen 64-bit control registers oversees CPU control and status functions beyond what is contained in the PSW. These registers evolved from earlier ESA/390 and IBM S/390 designs. With z/Architecture, their size expanded from 32 to 64 bits, resulting in changes to bit numbering conventions.

Control Registers in z/Architecture Mode
CR	Bits	Description
0	8	Controls transactional execution
0	9	Overrides for transactional-execution program interruptions
0	10	Sign control for clock comparator
0	13	Controls cryptography counters
0	14	Processor activity instrumentation extension control
0	15	Authorization for measurement-counter extraction
0	30	Mask for warning-track subclass
0	32	TRACE time-of-day clock control
0	33	Suppression of system state management (SSM)
0	34	Time-of-day clock synchronization control
0	35	Low-address protection control
0	36	Control for extraction authority
0	37	Secondary-space management control
0	38	Override control for fetch protection
0	39	Override control for storage protection
0	40	Enables enhanced dynamic address translation (DAT)
0	43	Enables instruction-execution protection
0	44	Controls ASN and LX reuse
0	45	AFP-register management control
0	46	Vector processing enablement control
0	"48–50"	"Masks for malfunction alert, emergency signal, and external call subclasses"
1	"0–51"	"Primary Address-Space Control Element" (ASCE): origins of region-table, segment-table, and real-space token
7	"0–51"	"Secondary Address-Space Control Element" (ASCE): origins of region-table, segment-table, and real-space token
9	"32–43"	Event masks covering successful branching, instruction fetching, storage changes, zero-address detection, transaction completion, and related controls
12	"0–63"	Trace controls including branch trace, mode trace, trace-entry address, ASN trace, and explicit trace settings
13	"0–63"	"Home Address-Space Control Element" (ASCE): origins and controls related to region-table and segment-table

Additional control registers are responsible for managing authorization indexes, storage event handling, timer subclass masks, and linkage stack entry addresses.

This extensive set of refined control registers underpins sophisticated CPU management capabilities vital for enterprise-grade workloads and system security.

Floating-point Control (FPC) register

The FPC register encompasses Interrupt Masks (IM), Status Flags (SF), Data Exception Code (DXC), Decimal Rounding Mode (DRM), and Binary Rounding Mode (BRM). The DXC is preserved during interrupts only if the AFP-register control bit (bit 13 in control register 0) is enabled. Although each DXC bit has specific significance, it is commonly handled as an 8-bit integer by software.

Fields within the FPC
Byte name	Bits	Field name	Purpose
masks	0	IMi	Mask for IEEE invalid operation exceptions
masks	1	IMz	Mask for IEEE division-by-zero exceptions
masks	2	IMo	Mask for IEEE overflow exceptions
masks	3	IMu	Mask for IEEE underflow exceptions
masks	4	IMx	Mask for IEEE inexact result exceptions
masks	5	IMq	Mask for quantum exceptions
flags	8	SFi	Flag indicating IEEE invalid operation exception occurred
flags	9	SFz	Flag indicating IEEE division-by-zero exception occurred
flags	10	SFo	Flag indicating IEEE overflow exception occurred
flags	11	SFu	Flag indicating IEEE underflow exception occurred
flags	12	SFx	Flag indicating IEEE inexact result exception occurred
flags	13	SFq	Flag indicating quantum exception occurred
DXC	16–23	DXC	Data exception code, which includes:
16–21 \| Various \| Indicators for IEEE and quantum exceptions \|
25–27 \| Decimal Floating Point rounding mode \|
29–31 \| Binary Floating Point rounding mode \|

Floating-point registers

The processor contains sixteen floating-point registers (FP0 through FP15), each 64 bits wide. Supported floating-point formats include:

Hexadecimal floating point (originating from System/360)
- ;E: Single precision occupying half of an FP register
- ;D: Double precision filling an entire FP register
- ;X: Extended precision spanning a pair of even-odd FP registers
IEEE 754 binary floating point:
- ;E: Single precision occupying half of an FP register
- ;D: Double precision filling a full FP register
- ;X: Quadruple precision covering an even-odd FP register pair
IEEE 754 decimal floating point:
- ;D: Double precision decimal64 format occupying a full FP register
- ;X: Extended precision decimal128 format using an even-odd FP register pair

General registers

There are sixteen general-purpose registers, each 64 bits in size, utilized as accumulators, base pointers, and index registers. Grandé instructions manipulate all 64 bits; certain Extended-Immediate Facility instructions operate on any halfword or word segment within the register; the majority of other instructions target only the upper half (bits 32–63).

Prefix register

The prefix register performs address translation by converting a real address into an absolute address. In z/Architecture mode, the Prefix Storage Area (PSA) occupies two pages totaling 8 KiB. Bits 0–32 and 51–63 are always zeroed. When bits 0–50 of a real address are zero, they are replaced with bits 0–50 from the prefix register; conversely, if bits 0–50 match those of the prefix register, they are substituted with zeros.

Program status word (PSW)

The PSW contains both the current instruction address and status information for the executing program on the CPU. Additionally, program state is affected by settings found in the Control registers.

Vector registers

Each processor is equipped with thirty-two vector registers, each measuring 128 bits. The lower 64 bits (bits 0–63) of VR0 through VR15 double as floating-point registers FPR0 through FPR15. These vector registers can be partitioned into various field sizes: sixteen fields of 8 bits, eight fields of 16 bits, four fields of 32 bits, two fields of 64 bits, or a single field of the full 128-bit width.

Memory

In z/Architecture, IBM differentiates memory into two categories: Main Storage and Expanded Storage.

Main storage is accessed using 8-bit bytes (octets) and can be grouped into larger aligned units:

Halfword: Comprising two bytes (16 bits)
Word: Consisting of four bytes (32 bits)
Doubleword: Made up of eight bytes (64 bits)
Quadword: Containing sixteen bytes (128 bits)
Page: Encompassing 4096 bytes

While the architecture theoretically supports addressing up to 2⁶⁴-1, practical implementations currently utilize a much smaller range due to engineering limitations.

Expanded storage is addressed in blocks of 4 KiB, with block indices ranging from 0 to 2³².

Main storage address categories

z/Architecture specifies three distinct types of main storage addresses:

Virtual address: The offset within an application’s address space, which undergoes translation through page and segment tables.
Real address: The address after translation or the one observed by operating system components when translation is disabled; it may be modified by prefixing.
Absolute address: The ultimate address obtained after applying prefix register adjustments for the first two pages.

Address format encoding

Similar to ESA, z/Architecture employs truncated addressing but extends it with additional instruction formats. In AR mode, each nonzero base register pairs with an access register defining the address space. The address formats include:

R: Address stored in a general-purpose register
Relative: A signed 16-bit halfword offset relative to the current instruction
Relative long: A signed 32-bit halfword offset relative to the current instruction
RS: Combination of a base register and a 12-bit displacement
RSY: Base register plus a 20-bit displacement (referred to as "Yonder")
RX: Base register combined with an index register and a 12-bit displacement
RXY: Base register plus index register and a 20-bit displacement ("Yonder")
SIY: Base register with a 20-bit displacement ("Yonder")

Addressing modes

Building upon the 24-bit and 31-bit modes from S/370-XA and ESA, z/Architecture introduces a 64-bit virtual addressing mode. This is governed by the EA (bit 31) and BA (bit 32) bits within the PSW, allowing these valid settings:

00: Employs 24-bit addressing
01: Uses 31-bit addressing
11: Enables 64-bit addressing

Translation modes

The architecture supports four virtual translation modes, determined by bit 5 (DAT-mode) along with bits 16–17 (Address-Space Control) in the PSW:

Primary-space mode: Translation tables are used for the primary address space
Access-register mode: Translation tables linked via the access register associated with the base register are utilized
Secondary-space mode: Uses translation tables assigned to the secondary address space
Home-space mode: Translation tables corresponding to the home address space are employed

Operating system support

IBM’s operating systems such as z/OS, z/VSE, z/TPF, and z/VM have been enhanced to support z/Architecture. Although earlier versions operated in 32-bit environments, starting from z/OS version 1.6, z/VSE version 4, and z/VM version 5, hardware compatible with z/Architecture is mandatory.

Support for z/Architecture is also available in Linux through the Linux on IBM Z initiative.

The design of z/Architecture allows simultaneous execution of multiple operating systems and applications that utilize different address sizes, enabling developers to tailor addressing based on specific application requirements.

On July 7, 2009, IBM introduced Architecture Level Set 4 (ALS 4), implemented on System z10 models and those that followed. ALS 4 is identified as ARCHLVL 3 in LOADxx instructions, succeeding ARCHLVL 2 found in earlier systems like the z900 and System z9. The System z10 brought over fifty new instructions, support for larger page frames of one megabyte, and incorporated a hardware decimal floating-point unit (HDFU).

For performance optimization and compatibility reasons, most operating systems running on z/Architecture—including z/OS—restrict code execution to the initial two gigabytes (31-bit addressing) of virtual memory. Conversely, Linux on IBM Z supports full utilization of native 64-bit code execution.

z/OS

Each z/OS address space, known as a 64-bit address space, encompasses a total of 16 exabytes.

Code (or mixed) spaces

The z/OS virtual memory architecture supports multiple address spaces, enabling numerous program codes to reside concurrently in memory, with the Java environment being a notable exception.

Data-only spaces

Data-only spaces are designated memory regions that permit reading and writing but prohibit execution, functioning similarly to the NX bit found in other CPU architectures. The z/Architecture employs 64-bit pointers, allowing access to as much as 16 exabytes of memory.

Dataspaces and hiperspaces

When applications demand data capacity exceeding the 16 exabyte limit of a single address space, extended addressing is achieved through additional data-only spaces classified as:

dataspaces (also called "data spaces"), and
hiperspaces (High Performance Spaces).

These virtual storage segments can each be up to 2 gigabytes in size and contain solely user data, excluding system control blocks or shared areas. Execution of program code is not permitted within either type. Dataspaces support byte-level addressing, whereas hiperspaces operate on a page-level addressing basis.

IBM mainframe expanded storage

IBM mainframes, from the System/360 line through to z/Architecture, have traditionally utilized byte-addressable memory referred to as Central Storage. In 1985, IBM introduced Expanded Storage with its high-end IBM 3090 models. Expanded Storage uses 4KB page addressing and requires data to be transferred into Central Storage before processing. Initially, such page transfers were resource-intensive and managed by paging subsystem software.

The development of the MVPG (Move Page) instruction along with the ADMF (Asynchronous Data Mover Facility) significantly lowered the overhead associated with moving pages between Central and Expanded Storage. Middleware running on z/OS or z/VM typically invokes these mechanisms to access data residing in Expanded Storage. Notable implementations include:

VSAM Local Shared Resources (LSR) buffer pool management that accesses buffers located in hiperspaces.
IBM Db2’s use of hiperpools—buffer pools allocated within hiperspaces.
VM Minidisk Caching.

Prior to the mid-1990s, Central and Expanded Storage were physically separate memory components; subsequently, they were redefined as logical partitions within the same physical memory based on their function. Despite changes, Expanded Storage continues to play a vital role in features such as Hiperbatch, which relies on MVPG for accessing hiperspace regions.

Other historical uses comprised Virtual I/O (VIO) directed at Expanded Storage for temporary dataset handling; this has since been replaced by VIO operations within Central Storage. Over time, z/OS has phased out support for Expanded Storage, consolidating all memory management under Central Storage. Similarly, z/VM version 6.4 declared intentions to cease utilizing Expanded Storage.

MVPG

IBM’s MVPG instruction ("Move Page," opcode X'B254') facilitates synchronous transfer of a single 4KB memory page, halting other processor instructions until the operation completes.

MVPG is analogous to the MVCL ("Move Character Long") instruction; both enable moving blocks larger than 256 bytes within memory through a single command. While neither guarantees complete atomicity, they operate under stringent timing controls and prevent overlapping source and destination regions during transfer.

Traditionally, large memory block movements were performed using software loops or MVCL (introduced with System/370 in 1970). MVPG, patented and introduced by IBM in 1989, offers enhanced efficiency for aligned page transfers and is employed extensively in performance-sensitive middleware tasks such as Db2 buffer pool management.

ADMF

ADMF (Asynchronous Data Mover Facility), launched in 1992, enhances the capabilities of the MVPG (Move Page) instruction, which is limited to transferring a single page, by supporting the transfer of multiple pages between Central and Expanded Storage.

The IOSADMF macro instruction functions as an API layer, preventing the need for direct interaction with low-level ADMF operations. It allows data to be read from or written to a hiperspace area, which is established using DSPSERV CREATE. To maintain reentrancy, IOSADMF utilizes two modes: "List form" and "Execute form."

Non-IBM implementations

Platform Solutions Inc. (PSI) offered Itanium-based servers that were compatible with z/Architecture until IBM acquired PSI in July 2008, after which these products were phased out. Other z/Architecture implementations include FLEX-ES, zPDT, and the Hercules emulator. Hitachi mainframes running recent VOS3 operating system versions incorporate ESA/390 along with proprietary CPU instructions, some of which are 64-bit; however, despite earlier collaboration with IBM on z900-G2/z800 processors, Hitachi systems do not fully conform to the z/Architecture standard.

References

z