Assembler Language Programming

for
IBM System z™ Servers

Version 2.00

John R. Ehrman

IBM Silicon Valley Lab

Second Edition (February 2016)

IBM welcomes your comments. Please address them to

John Ehrman
IBM Silicon Valley Lab
555 Bailey Avenue
San Jose, CA 95141
[email protected]

© Copyright IBM Corporation 2015

US Government Users Restricted Rights − Use, duplication or disclosure restricted by GSA ADP Schedule
Contract with IBM Corp.

ii Assembler Language Programming for IBM System z™ Servers Version 2.00

Contents
Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi

Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxix

Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Outline and Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Programming Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Levels of Difficulty (*) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Exercises and Programming Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Some Personal Observations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Von Neumann Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Why Program in Assembler Language (and Why Not)? . . . . . . . . . . . . . . . . . . . 5
Assembler Language Misconceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Chapter I: Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1. Some Basic Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.1. Notation and Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2. Instruction Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2.1. Register Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2. Binary and Hexadecimal Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1. Positional Notation and Binary Numbers . . . . . . . . . . . . . . . . . . . . . . 16
2.2. Hexadecimal Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3. Converting Integers from One Base to Another (*) . . . . . . . . . . . . . . . . . 19
2.4. Examples of General Conversions (*) . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.5. Number Representations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.6. Logical (Unsigned) Representation . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.7. Two's Complement (Signed) Representation (*) . . . . . . . . . . . . . . . . . . 25
2.8. Computing Two's Complements . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.9. Sign Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.10. Binary Addition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.11. Binary Subtraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.12. How Additions and Subtractions Are Actually Performed (*) . . . . . . . . . . 34
2.13. A Circular View of Binary Arithmetic (*) . . . . . . . . . . . . . . . . . . . . . . 36
2.14. Logical (Unsigned) and Arithmetic (Signed) Results (*) . . . . . . . . . . . . . 37
2.15. Examples of Representations (*) . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Chapter II: System z . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3. Conceptual Structure of System z . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.1. Memory Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2. Central Processing Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.3. General Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.4. Floating-Point Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.5. Program Status Word (PSW) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.6. Other Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.7. Input-Output (I/O) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.8. Features, Facilities, and Assists . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.9. Microprograms and Millicode (*) . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4. Instruction Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.1. Basic Instruction Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.2. Basic Instruction Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.3. Instruction Lengths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.4. Some Operation Codes (*) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.5. Interruptions (*) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.6. Exceptions and Program Interruptions (*) . . . . . . . . . . . . . . . . . . . . . . 56
4.7. Machine Language and Assembler Language . . . . . . . . . . . . . . . . . . . . 58
4.8. Processor Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5. Memory Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.1. The Addressing Halfword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Contents iii
 5.2. Examples of Effective Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.3. Indexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.4. Examples of Indexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.5. Addressing Problems (*) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.6. Address Translation and Virtual Memory (*) . . . . . . . . . . . . . . . . . . . . 67
5.7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Chapter III: Assembler Language Programs . . . . . . . . . . . . . . . . . . . . . . . . . . 71

6. Assembler Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.1. Processing Your Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.1.1. Assembly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.1.2. Linking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.1.3. Loading and Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.2. Preparing Assembler Language Statements . . . . . . . . . . . . . . . . . . . . . . 74
6.3. Statement Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.3.1. What's in a Name Field? (*) . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.4. Writing Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.5. A Sample Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.6. Basic Macro Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
7. Self-Defining Terms and Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
7.1. Self-Defining Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
7.2. EBCDIC Character Representation . . . . . . . . . . . . . . . . . . . . . . . . . . 87
7.3. Symbols and Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
7.4. Program Relocatability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
7.5. The Location Counter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
7.6. Assigning Values to Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
7.7. Symbols and Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
8. Terms, Operators, Expressions, and Operands . . . . . . . . . . . . . . . . . . . . . . . 96
8.1. Terms and Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
8.2. Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
8.3. Evaluating Assembly-Time Expressions (*) . . . . . . . . . . . . . . . . . . . . . 98
8.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
8.5. Machine Instruction Statement Operand Formats . . . . . . . . . . . . . . . . . 102
8.6. Details of Expression Evaluation (*) . . . . . . . . . . . . . . . . . . . . . . . . 103
9. Instructions, Mnemonics, and Operands . . . . . . . . . . . . . . . . . . . . . . . . . . 106
9.1. Basic RR-Type Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
9.2. Writing RR-Type Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
9.3. Basic RX-Type Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
9.4. Writing RX-Type Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
9.5. Explicit and Implied Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
9.6. Typical RS- and SI-Type Instructions . . . . . . . . . . . . . . . . . . . . . . . 111
9.7. Writing RS- and SI-Type Instructions . . . . . . . . . . . . . . . . . . . . . . . 111
9.8. Typical SS-Type Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
9.9. Writing SS-Type Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
9.10. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
10. Establishing and Maintaining Addressability . . . . . . . . . . . . . . . . . . . . . . . 116
10.1. The BASR Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
10.2. Computing Displacements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
10.3. Explicit Base and Displacement . . . . . . . . . . . . . . . . . . . . . . . . . . 119
10.4. The USING Assembler Instruction and Implied Addresses . . . . . . . . . . . 120
10.5. Location Counter Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
10.6. Destroying Base Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
10.7. Calculating Displacements: the Assembly Process, Pass One . . . . . . . . . . 123
10.8. Calculating Displacements: the Assembly Process, Pass Two . . . . . . . . . 125
10.9. Multiple USING Table Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
10.10. The DROP Assembler Instruction . . . . . . . . . . . . . . . . . . . . . . . . 128
10.11. Addressability Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
10.12. Resolutions With Register Zero (*) . . . . . . . . . . . . . . . . . . . . . . . . 130
10.13. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
10.13.1. How the Assembler Helps . . . . . . . . . . . . . . . . . . . . . . . . . . 133

iv Assembler Language Programming for IBM System z™ Servers Version 2.00

Chapter IV: Defining Constants and Storage Areas . . . . . . . . . . . . . . . . . . . . 135
11. Defining Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
11.1. Defining Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
11.2. DC Instruction Statements and Operands . . . . . . . . . . . . . . . . . . . . . 138
11.2.1. Blanks in Nominal Values . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
11.3. Boundary Alignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
11.4. Length Modifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
11.5. Duplication Factors and Multiple Operands . . . . . . . . . . . . . . . . . . . 141
11.6. Multiple Nominal Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
11.7. Length Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
11.8. Decimal Exponents (*) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
11.8.1. Decimal Exponents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
11.8.2. Exponent Modifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
12. Basic Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
12.1. F-Type and H-Type Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
12.2. A-Type Address Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
12.3. Y-Type Address Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
12.4. Constants of Types C, X, and B . . . . . . . . . . . . . . . . . . . . . . . . . . 150
12.5. Padding and Truncation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
12.6. Literals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
12.7. The LTORG Assembler Instruction . . . . . . . . . . . . . . . . . . . . . . . . 156
12.8. Type Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
13. Data Storage Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
13.1. Storage Areas: The DS Assembler Instruction . . . . . . . . . . . . . . . . . . 159
13.2. Zero Duplication Factor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
13.3. The EQU Assembler Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . 162
13.4. EQU Instruction Extended Syntax (*) . . . . . . . . . . . . . . . . . . . . . . . 166
13.5. The ORG Assembler Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . 167
13.6. Parameterization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
13.7. Constants Depending on the Location Counter . . . . . . . . . . . . . . . . . 171
13.8. Assembly Time and Execution Time, Revisited (*) . . . . . . . . . . . . . . . 173
13.9. Summary Observations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Chapter V: Basic Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

14. General Register Data Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
14.1. Load and Store Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
14.2. Multiple Loads and Stores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
14.3. Halfword Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
14.4. Insert and Store Character . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
14.5. ICM and STCM Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
14.6. RR-Type Data Transmission Instructions . . . . . . . . . . . . . . . . . . . . 187
14.7. Load, Store, and Insert for 64-bit General Registers . . . . . . . . . . . . . . . 189
14.8. RRE-Type Data Transmission Instructions for 64-bit General Registers . . . 192
14.9. The Load and Test Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . 193
14.10. Mixed 32- and 64-bit Operands . . . . . . . . . . . . . . . . . . . . . . . . . . 194
14.11. Other General Register Load Instructions (*) . . . . . . . . . . . . . . . . . . 195
14.11.1. Load Byte Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
14.11.2. Load Logical Character Instructions . . . . . . . . . . . . . . . . . . . . 196
14.11.3. Load Logical Halfword Instructions . . . . . . . . . . . . . . . . . . . . 197
14.11.4. Load Logical (Word) Instructions . . . . . . . . . . . . . . . . . . . . . . 197
14.11.5. Load Logical Thirty One Bit Instructions . . . . . . . . . . . . . . . . . 197
14.12. Misunderstandings to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
14.13. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
15. Testing the Condition Code: Conditional Branching . . . . . . . . . . . . . . . . . . 204
15.1. The Branch Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
15.2. The Branch Mask and Branch Condition . . . . . . . . . . . . . . . . . . . . . 205
15.3. Examples of Conditional Branch Instructions . . . . . . . . . . . . . . . . . . 206
15.4. No-Operation Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
15.4.1. Special No-Operation Instructions (*) . . . . . . . . . . . . . . . . . . . . 206
15.5. Conditional No-Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
15.6. Extended Mnemonics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
15.7. A Comment on Programming Style . . . . . . . . . . . . . . . . . . . . . . . . 212

Contents v
 15.8. A Design Oversight and a Modern “Correction” (*) . . . . . . . . . . . . . . . 212
15.9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
16. Fixed-Point Binary Addition, Subtraction, and Comparison . . . . . . . . . . . . . 216
16.1. Signed-Arithmetic Add and Subtract Instructions . . . . . . . . . . . . . . . . 216
16.2. Signed-Arithmetic Operations Using 32-Bit Registers . . . . . . . . . . . . . . 217
16.2.1. Condition Code Settings After Arithmetic . . . . . . . . . . . . . . . . . . 218
16.3. Signed-Arithmetic Operations Using 64-Bit Registers . . . . . . . . . . . . . . 221
16.4. Signed-Arithmetic Compare Instructions . . . . . . . . . . . . . . . . . . . . . 222
16.5. Logical-Arithmetic Add and Subtract Instructions . . . . . . . . . . . . . . . . 224
16.6. Add With Carry, Subtract With Borrow (*) . . . . . . . . . . . . . . . . . . . 228
16.7. Operations With Mixed 64-Bit and 32-Bit Operands . . . . . . . . . . . . . . 229
16.8. Logical-Arithmetic Compare Instructions . . . . . . . . . . . . . . . . . . . . . 232
16.9. Retrieving and Setting the Program Mask (*) . . . . . . . . . . . . . . . . . . 234
16.10. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
17. Binary Shifting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
17.1. Unit Shifts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
17.2. Single-Length Logical Shifts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
17.2.1. Three-Operand Shift Instructions . . . . . . . . . . . . . . . . . . . . . . . 247
17.3. Double-Length Logical Shifts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
17.4. Arithmetic Shift Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
17.5. Rotating Shifts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
17.6. Calculated Shift Amounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
17.7. Bit-Length Constants (*) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
17.8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
18. Binary Multiplication and Division . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
18.1. Overview of Multiplication Instructions . . . . . . . . . . . . . . . . . . . . . . 264
18.2. Arithmetic (Signed) Multiplication Instructions . . . . . . . . . . . . . . . . . 265
18.2.1. Double-Length Arithmetic Products . . . . . . . . . . . . . . . . . . . . . 265
18.2.2. Single-Length Arithmetic Products . . . . . . . . . . . . . . . . . . . . . . 267
18.3. Logical (Unsigned) Multiplication Instructions . . . . . . . . . . . . . . . . . . 270
18.4. How Multiplication Is Done (*) . . . . . . . . . . . . . . . . . . . . . . . . . . 272
18.5. Division Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
18.6. Arithmetic (Signed) Division Instructions . . . . . . . . . . . . . . . . . . . . . 275
18.6.1. Double-Length Division . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
18.6.2. Single-Length Division . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
18.7. Logical (Unsigned) Division Instructions . . . . . . . . . . . . . . . . . . . . . 279
18.8. How Division Is Done (*) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
18.9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
19. Logical Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
19.1. Logical Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
19.2. Register-Based Logical Instructions . . . . . . . . . . . . . . . . . . . . . . . . 289
19.3. Logical AND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
19.4. Logical OR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
19.5. Logical Exclusive OR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
19.6. Interesting Uses of Logical Instructions (*) . . . . . . . . . . . . . . . . . . . . 295
19.7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297

Chapter VI: Addressing, Immediate Operands, and Loops . . . . . . . . . . . . . . . . 301

20. Address Generation and Addressing Modes . . . . . . . . . . . . . . . . . . . . . . . 302
20.1. Address Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
20.1.1. Address Generation With 12-Bit Displacements . . . . . . . . . . . . . . 302
20.1.2. Address Generation With 20-Bit Displacements . . . . . . . . . . . . . . 302
20.1.3. Address Generation With Relative-Immediate Operands . . . . . . . . . 305
20.2. Addressing Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
20.3. Load Address Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
20.4. 64-Bit Virtual Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
20.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
21. Immediate Operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
21.1. Insert and Load Instructions with Immediate Operands . . . . . . . . . . . . . 318
21.1.1. Logical-Immediate Insert Instructions . . . . . . . . . . . . . . . . . . . . 318
21.1.2. Arithmetic- and Logical-Immediate Load Instructions . . . . . . . . . . . 318
21.2. Arithmetic Instructions with Immediate Operands . . . . . . . . . . . . . . . . 321

vi Assembler Language Programming for IBM System z™ Servers Version 2.00

 21.2.1. Arithmetic-Immediate Add and Subtract Instructions . . . . . . . . . . . 321
21.2.2. Arithmetic-Immediate Compare Instructions . . . . . . . . . . . . . . . . 322
21.2.3. Arithmetic-Immediate Multiply Instructions . . . . . . . . . . . . . . . . 322
21.3. Logical Operations with Immediate Operands . . . . . . . . . . . . . . . . . . 323
21.3.1. Logical-Immediate AND Instructions . . . . . . . . . . . . . . . . . . . . 323
21.3.2. Logical-Immediate OR Instructions . . . . . . . . . . . . . . . . . . . . . 323
21.3.3. Logical-Immediate XOR Instructions . . . . . . . . . . . . . . . . . . . . 324
21.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
22. Branches, Loops, and Indexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
22.1. Branch Relative on Condition Instructions . . . . . . . . . . . . . . . . . . . . 329
22.2. A Simple Example of a Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
22.3. Simple Tables and Array Indexing . . . . . . . . . . . . . . . . . . . . . . . . . 332
22.4. Branch on Count Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
22.5. Looping in General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
22.6. Branch on Index Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
22.7. Examples Using BXLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
22.8. Examples Using BXH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
22.9. Specialized Uses of BXH and BXLE (*) . . . . . . . . . . . . . . . . . . . . . 347
22.10. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349

Chapter VII: Bit and Character Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351

23. Bit and Byte Data and Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
23.1. SI- and SIY-Type Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
23.2. MVI Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
23.3. NI, OI, and XI Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
23.4. CLI Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
23.5. Test Under Mask Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
23.6. Bit Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
23.7. Avoiding Bit-Naming Problems (*) . . . . . . . . . . . . . . . . . . . . . . . . 359
23.8. A Data Conversion Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
23.9. Instruction Modification (*) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
23.10. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
24. Character Data and Basic Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . 365
24.1. Basic SS-Type Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
24.2. Operand Specifications and Explicit Lengths . . . . . . . . . . . . . . . . . . . 366
24.3. Symbol Length Attribute References . . . . . . . . . . . . . . . . . . . . . . . 368
24.4. Implied Lengths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
24.5. The Encoded Length “L” and Program Length “N” . . . . . . . . . . . . . . 370
24.6. The MVC and MVCIN Instructions . . . . . . . . . . . . . . . . . . . . . . . 372
24.6.1. MVC: Move Characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
24.6.2. MVCIN: Move Characters Inverse . . . . . . . . . . . . . . . . . . . . . . 373
24.6.3. MVCOS: Move Characters With Optional Specifications (*) . . . . . . . 374
24.7. The NC, OC, and XC Instructions . . . . . . . . . . . . . . . . . . . . . . . . 376
24.8. The CLC Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
24.9. The TR (translate) Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
24.10. The TRT and TRTR Instructions . . . . . . . . . . . . . . . . . . . . . . . . 383
24.10.1. T R T . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
24.10.2. T R T R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
24.11. The Execute Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
24.11.1. Execute Instruction Without Target-Instruction Modification . . . . . . 390
24.11.2. Execute Instruction with Target-Instruction Modification . . . . . . . . 391
24.11.3. Comments on the Execute Instructions (*) . . . . . . . . . . . . . . . . 392
24.11.4. Modifiable Parts of Instructions . . . . . . . . . . . . . . . . . . . . . . . 393
24.12. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
25. Character Data and Extended Instructions . . . . . . . . . . . . . . . . . . . . . . . . 403
25.1. Move Long and Compare Logical Long . . . . . . . . . . . . . . . . . . . . . 403
25.1.1. MVCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
25.1.2. CLCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
25.2. Move Long and Compare Logical Long Extended . . . . . . . . . . . . . . . 410
25.2.1. MVCLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
25.2.2. CLCLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
25.3. Special “C-String” Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . 415

Contents vii
 25.4. Search String Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
25.5. Move String Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
25.6. Compare Logical String Instruction . . . . . . . . . . . . . . . . . . . . . . . . 419
25.7. Translate Extended Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
25.8. Compare Until Substring Equal Instruction (*) . . . . . . . . . . . . . . . . . 423
25.9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
26. Other Types of Character Data (*) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
26.1. Character Representations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
26.1.0. An Early Character Encoding . . . . . . . . . . . . . . . . . . . . . . . . . 428
26.1.1. BCD characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
26.2. EBCDIC Representations and Code Pages . . . . . . . . . . . . . . . . . . . . 430
26.3. ASCII . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
26.4. Double-Byte EBCDIC Data (*) . . . . . . . . . . . . . . . . . . . . . . . . . . 434
26.4.1. The DBCS Option (*) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
26.4.2. G-Type DBCS Constants and Self-Defining Terms (*) . . . . . . . . . . 436
26.4.3. Continuation Rules for DBCS Data (*) . . . . . . . . . . . . . . . . . . . 437
26.5. Unicode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
26.5.1. The Unicode Representation . . . . . . . . . . . . . . . . . . . . . . . . . 438
26.5.2. Glyphs and Characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
26.5.3. Unicode Character Constants . . . . . . . . . . . . . . . . . . . . . . . . . 439
26.6. Unicode Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
26.6.1. String Search, Move, and Compare . . . . . . . . . . . . . . . . . . . . . 441
26.6.2. Optional Operands (*) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
26.6.3. Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
26.6.4. Conversion Among Transformation Formats (*) . . . . . . . . . . . . . . 447
26.7. Translate and Test Extended . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
26.8. Byte Reversal and Workstation Data . . . . . . . . . . . . . . . . . . . . . . . 453
26.8.1. Byte-Reversing Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . 453
26.9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456

Chapter VIII: Zoned and Packed Decimal Data and Operations . . . . . . . . . . . . 459
27. Zoned and Packed Decimal Representations . . . . . . . . . . . . . . . . . . . . . . 460
27.1. Zoned Decimal Representation . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
27.1.1. Why Zoned Decimal Is The Way It Is (*) . . . . . . . . . . . . . . . . . 463
27.2. Zoned Decimal Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
27.3. Packed Decimal Representation . . . . . . . . . . . . . . . . . . . . . . . . . . 465
27.4. Packed Decimal Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
27.4.1. Scale Attributes and Packed Decimal Constants (*) . . . . . . . . . . . . 467
27.5. Converting Between Packed and Zoned . . . . . . . . . . . . . . . . . . . . . . 469
27.6. The PACK Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
27.7. The UNPK Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474
27.8. Packing and Unpacking ASCII and Unicode Data (*) . . . . . . . . . . . . . 478
27.8.1. Packing ASCII and Unicode Data . . . . . . . . . . . . . . . . . . . . . . 478
27.8.2. Unpacking ASCII and Unicode Data . . . . . . . . . . . . . . . . . . . . 479
27.9. Printing Hexadecimal Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
27.10. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
28. Packed Decimal Arithmetic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
28.1. General Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
28.1.1. Precision and Accuracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
28.2. Decimal Addition and Subtraction . . . . . . . . . . . . . . . . . . . . . . . . . 485
28.3. Decimal Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
28.4. Decimal Multiplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
28.5. Decimal Division . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
28.6. True Decimal Addition (*) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492
28.7. Complement Decimal Addition (*) . . . . . . . . . . . . . . . . . . . . . . . . 493
29. Packed Decimal Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
29.1. TP Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498
29.2. ZAP Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
29.3. AP and SP Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501
29.4. CP Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503
29.5. MP Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506
29.6. DP Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509

viii Assembler Language Programming for IBM System z™ Servers Version 2.00
 29.7. SRP Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
29.7.1. Biased and Unbiased Rounding with SRP (*) . . . . . . . . . . . . . . . 513
29.8. MVO Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516
29.9. Decimal Shifting Using MVO (*) . . . . . . . . . . . . . . . . . . . . . . . . . 518
29.9.1. Shift Right an Odd Number of Digits . . . . . . . . . . . . . . . . . . . . 518
29.9.2. Shift Left an Odd Number of Digits . . . . . . . . . . . . . . . . . . . . . 519
29.9.3. Shifting an Even Number of Digits . . . . . . . . . . . . . . . . . . . . . . 519
29.9.4. Shifting Left an Even Number of Digits . . . . . . . . . . . . . . . . . . . 520
29.9.5. Shifting Right an Even Number of Digits . . . . . . . . . . . . . . . . . . 520
29.10. Scaled Packed Decimal Computations: General Rules . . . . . . . . . . . . . 522
29.10.1. Precision and Scale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522
29.10.2. General Rules: Addition and Subtraction . . . . . . . . . . . . . . . . . 523
29.10.3. General Rules: Multiplication . . . . . . . . . . . . . . . . . . . . . . . . 523
29.10.4. General Rules: Division (*) . . . . . . . . . . . . . . . . . . . . . . . . . 524
29.10.5. COBOL and PL/I Notations (*) . . . . . . . . . . . . . . . . . . . . . . 525
29.11. Example of a Packed Decimal “Business” Computation . . . . . . . . . . . 526
29.11.1. The Wholesaler's Calculation . . . . . . . . . . . . . . . . . . . . . . . . 526
29.11.2. The Retailer's Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . 527
29.11.3. Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529
29.11.4. Using Integer and Scale Attributes (*) . . . . . . . . . . . . . . . . . . . 529
29.12. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530
30. Converting and Formatting Packed Decimal Data . . . . . . . . . . . . . . . . . . . 532
30.1. CVD, CVDY, and CVDG Instructions . . . . . . . . . . . . . . . . . . . . . . 532
30.2. CVB, CVBY, and CVBG Instructions . . . . . . . . . . . . . . . . . . . . . . 534
30.3. Editing Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536
30.4. Simple Examples of Editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 538
30.5. Single-Field Editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541
30.5.1. Editing Negative Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541
30.5.2. Protecting High-Order Fields . . . . . . . . . . . . . . . . . . . . . . . . . 542
30.6. The EDMK Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
30.7. Editing Multiple Fields (*) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545
30.8. Summary Comments on Editing (*) . . . . . . . . . . . . . . . . . . . . . . . . 546

Chapter IX: Floating-Point Data and Operations . . . . . . . . . . . . . . . . . . . . . . 551

31. Floating-Point Numbers: Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 552
31.1. Scaled Fixed-Point Arithmetic . . . . . . . . . . . . . . . . . . . . . . . . . . . 552
31.2. Mixed Integer-Fraction Representation . . . . . . . . . . . . . . . . . . . . . . 553
31.2.1. Scaled Fixed-Point Binary Arithmetic (*) . . . . . . . . . . . . . . . . . . 554
31.2.2. Scaled Fixed-Point Binary Constants (*) . . . . . . . . . . . . . . . . . . 555
31.3. Converting Fractions Between Bases (*) . . . . . . . . . . . . . . . . . . . . . 557
31.4. Why Use Floating-Point Numbers? . . . . . . . . . . . . . . . . . . . . . . . . 559
31.4.1. Precision and Accuracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 560
31.5. Floating-Point Representations . . . . . . . . . . . . . . . . . . . . . . . . . . . 560
31.5.1. Left Normalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561
31.5.2. Right Normalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562
31.5.3. No Normalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562
31.5.4. Some Additional Details (*) . . . . . . . . . . . . . . . . . . . . . . . . . . 562
31.6. System z Floating-Point Representations . . . . . . . . . . . . . . . . . . . . . 564
31.7. System z Floating-Point Registers . . . . . . . . . . . . . . . . . . . . . . . . . 564
31.8. Floating-Point Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567
31.9. Representation-Independent Floating-Point Instructions . . . . . . . . . . . . 568
31.9.1. Register-Storage Instructions . . . . . . . . . . . . . . . . . . . . . . . . . 568
31.9.2. Register-Register Instructions . . . . . . . . . . . . . . . . . . . . . . . . . 568
31.9.3. Load-Zero Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569
31.9.4. GPR-FPR Copying Instructions . . . . . . . . . . . . . . . . . . . . . . . 569
31.9.5. Sign-Copying Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . 570
31.10. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 570
32. Basic Concepts of Floating-Point Arithmetic . . . . . . . . . . . . . . . . . . . . . . 573
32.1. Floating-Point Multiplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573
32.2. Pre-Normalization of Fraction Operands . . . . . . . . . . . . . . . . . . . . . 574
32.3. Floating-Point Rounding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574
32.4. Guard and Rounding Digits (*) . . . . . . . . . . . . . . . . . . . . . . . . . . 575

Contents ix
 32.5. Integer-Based Representations (*) . . . . . . . . . . . . . . . . . . . . . . . . . 577
32.6. Floating-Point Division . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578
32.7. Floating-Point Addition and Subtraction . . . . . . . . . . . . . . . . . . . . . 578
32.8. Floating-Point Precision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580
32.9. Floating-Point Range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582
32.10. Exponents and Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . 584
32.11. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585
33. Hexadecimal Floating-Point Data and Operations . . . . . . . . . . . . . . . . . . . 586
33.1. Hexadecimal Floating-Point Data . . . . . . . . . . . . . . . . . . . . . . . . . 586
33.2. Writing Hexadecimal Floating-Point Constants . . . . . . . . . . . . . . . . . 590
33.2.1. Decimal Exponents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591
33.3. Modifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592
33.3.1. Length Modifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592
33.3.2. Scale Modifiers (*) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592
33.3.3. Exponent Modifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
33.4. Subtypes Q and H (*) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594
33.4.1. LQ-Type Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594
33.4.2. Subtype H . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595
33.4.3. Difficult Numbers (*) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596
33.5. Basic Hexadecimal Floating-Point Instructions . . . . . . . . . . . . . . . . . . 597
33.6. Hexadecimal Floating-Point RR-Type Data-Movement Instructions . . . . . 597
33.7. Hexadecimal Floating-Point Multiplication . . . . . . . . . . . . . . . . . . . . 599
33.7.1. Exponent Overflow and Underflow. . . . . . . . . . . . . . . . . . . . . . 602
33.8. Hexadecimal Floating-Point Division . . . . . . . . . . . . . . . . . . . . . . . 603
33.8.1. The Halve Instructions (*) . . . . . . . . . . . . . . . . . . . . . . . . . . 604
33.9. Hexadecimal Floating-Point Addition and Subtraction . . . . . . . . . . . . . 606
33.9.1. Unnormalized Addition and Subtraction . . . . . . . . . . . . . . . . . . 609
33.9.2. Older Uses of Unnormalized Addition (*) . . . . . . . . . . . . . . . . . . 609
33.10. Adding Operands of Like Sign (*) . . . . . . . . . . . . . . . . . . . . . . . . 612
33.11. Adding Operands of Unlike Sign (*) . . . . . . . . . . . . . . . . . . . . . . . 612
33.11.1. Hexadecimal Floating-Point Complement Addition (*) . . . . . . . . . 613
33.11.2. Implementing Hexadecimal Floating-Point Complement Addition (*) . 614
33.12. Hexadecimal Floating-Point Comparison . . . . . . . . . . . . . . . . . . . . 615
33.13. Rounding and Lengthening Instructions . . . . . . . . . . . . . . . . . . . . . 616
33.13.1. Rounding Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616
33.13.2. Lengthening Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . 618
33.14. Converting Between Binary Integers and HFP . . . . . . . . . . . . . . . . . 620
33.14.1. Converting Binary Integers to Hexadecimal Floating-Point . . . . . . . 620
33.14.2. Converting Hexadecimal Floating-Point to Binary Integers . . . . . . . 621
33.15. Hexadecimal Floating-Point Integers and Remainders (*) . . . . . . . . . . . 625
33.16. Square Root Instructions (*) . . . . . . . . . . . . . . . . . . . . . . . . . . . 626
33.17. Multiply and Add/Subtract Instructions (*) . . . . . . . . . . . . . . . . . . . 627
33.18. Some Hexadecimal Floating-Point History (*) . . . . . . . . . . . . . . . . . 629
33.18.1. Zeroing Floating-Point Registers . . . . . . . . . . . . . . . . . . . . . . 629
33.18.2. Hexadecimal Floating-Point to Binary Conversion Comments (*) . . . 629
33.18.3. Initial System/360 Oversights . . . . . . . . . . . . . . . . . . . . . . . . 630
33.19. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 630
34. Binary Floating-Point Data and Operations . . . . . . . . . . . . . . . . . . . . . . . 638
34.1. Binary Floating-Point Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 638
34.1.1. Data Representations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639
34.1.2. Normal Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 640
34.1.3. Special Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 640
34.1.4. Range of the Representation . . . . . . . . . . . . . . . . . . . . . . . . . 641
34.2. Writing Binary Floating-Point Constants . . . . . . . . . . . . . . . . . . . . . 642
34.2.1. Decimal Exponents and Exponent Modifiers . . . . . . . . . . . . . . . . 644
34.2.2. Length Modifiers (*) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645
34.3. Binary Floating-Point Arithmetic in General . . . . . . . . . . . . . . . . . . . 646
34.3.1. Rounding Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646
34.3.2. Denormalized Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647
34.3.3. Arithmetic with Zero, Infinity, and NaNs . . . . . . . . . . . . . . . . . . 648
34.4. Binary Floating-Point Exceptions, Interruptions, and Controls . . . . . . . . 649
34.4.1. Binary Floating-Point Exceptions (*) . . . . . . . . . . . . . . . . . . . . 649

x Assembler Language Programming for IBM System z™ Servers Version 2.00

 34.4.2. FPC Register Instructions (*) . . . . . . . . . . . . . . . . . . . . . . . . . 651
34.4.3. Exception Actions (*) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651
34.4.4. Scaled Exponents (*) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653
34.5. Basic Binary Floating-Point Instructions . . . . . . . . . . . . . . . . . . . . . 653
34.6. Binary Floating-Point RR-Type Data Movement Instructions . . . . . . . . . 655
34.7. Binary Floating-Point Multiplication . . . . . . . . . . . . . . . . . . . . . . . 657
34.8. Binary Floating-Point Division . . . . . . . . . . . . . . . . . . . . . . . . . . . 659
34.9. Binary Floating-Point Addition and Subtraction . . . . . . . . . . . . . . . . . 661
34.10. Binary Floating-Point Comparison . . . . . . . . . . . . . . . . . . . . . . . . 662
34.10.1. Compare and Signal (*) . . . . . . . . . . . . . . . . . . . . . . . . . . . 663
34.11. Binary Floating-Point Rounding and Lengthening Instructions (*) . . . . . 664
34.11.1. Rounding Instructions (*) . . . . . . . . . . . . . . . . . . . . . . . . . . 664
34.11.2. Lengthening Instructions (*) . . . . . . . . . . . . . . . . . . . . . . . . . 664
34.12. Converting Between BFP and Binary Integers (*) . . . . . . . . . . . . . . . 666
34.12.1. Converting Binary Integers to Binary Floating-Point (*) . . . . . . . . . 666
34.12.2. Converting Binary Floating-Point to Binary Integers (*) . . . . . . . . . 666
34.13. Binary Floating-Point Integers and Remainders (*) . . . . . . . . . . . . . . 668
34.13.1. Load FP Integer Instructions . . . . . . . . . . . . . . . . . . . . . . . . 668
34.13.2. Divide to Integer Instructions (*) . . . . . . . . . . . . . . . . . . . . . . 669
34.14. Binary Floating-Point Square Root Instructions (*) . . . . . . . . . . . . . . 671
34.15. Binary Floating-Point Multiply and Add/Subtract (*) . . . . . . . . . . . . . 672
34.16. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673
35. Decimal Floating-Point Data and Operations . . . . . . . . . . . . . . . . . . . . . . 680
35.1. Representations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681
35.1.1. Conceptual View of the Decimal Floating-Point Representation . . . . . 682
35.2. System z Decimal Floating-Point Data Encoding and Representation (*) . . 684
35.2.1. Decimal Floating-Point Data Encoding (*) . . . . . . . . . . . . . . . . . 685
35.2.2. Decimal Floating-Point Data Representation (*) . . . . . . . . . . . . . . 686
35.2.3. Decimal Floating-Point Combination Field (*) . . . . . . . . . . . . . . . 687
35.3. Decimal Floating-Point Constants . . . . . . . . . . . . . . . . . . . . . . . . . 690
35.3.1. Rounding-Mode Suffixes for Decimal Floating-Point Constants . . . . . 691
35.3.2. Decimal Exponents and Modifiers . . . . . . . . . . . . . . . . . . . . . . 692
35.4. Decimal Floating-Point Data Classes (*) . . . . . . . . . . . . . . . . . . . . . 693
35.5. Decimal Floating-Point Operations: Rounding, Quanta, and Exceptions . . . 695
35.5.1. Rounding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695
35.5.2. Preferred Exponent and Quantum . . . . . . . . . . . . . . . . . . . . . . 696
35.5.3. DFP Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 698
35.4.4. Overflow/Underflow Scale Factors (*) . . . . . . . . . . . . . . . . . . . . 699
35.6. Decimal Floating-Point Data Movement Instructions . . . . . . . . . . . . . . 699
35.6.1. Copy Sign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699
35.6.2. Copy between General and Floating-Point Registers . . . . . . . . . . . 700
35.6.3. Copy Among Floating-Point Registers . . . . . . . . . . . . . . . . . . . 700
35.7. Decimal Floating-Point Arithmetic Instructions . . . . . . . . . . . . . . . . . 701
35.7.1. Multiplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702
35.7.2. Division . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703
35.7.3. Addition and Subtraction . . . . . . . . . . . . . . . . . . . . . . . . . . . 703
35.8. Decimal Floating-Point Compare Instructions . . . . . . . . . . . . . . . . . . 705
35.8.1. Compare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705
35.8.2. Compare and Signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705
35.8.3. Compare Biased Exponent . . . . . . . . . . . . . . . . . . . . . . . . . . 706
35.9. Converting Decimal Floating-Point To and From Fixed Binary . . . . . . . . 707
35.9.1. Convert From Fixed Binary To DFP . . . . . . . . . . . . . . . . . . . . 707
35.9.2. Convert From DFP To Fixed Binary . . . . . . . . . . . . . . . . . . . . 707
35.10. Converting Decimal Floating-Point To/From Packed and Zoned Decimal . 709
35.10.1. Convert To/From Signed Packed Decimal . . . . . . . . . . . . . . . . . 709
35.10.2. Convert To/From Unsigned Packed Decimal . . . . . . . . . . . . . . . 711
35.10.3. Convert To/From Zoned Decimal . . . . . . . . . . . . . . . . . . . . . 712
35.11. Decimal Floating-Point Load Operations . . . . . . . . . . . . . . . . . . . . 714
35.11.1. Load and Test, Complement, Negative, and Positive . . . . . . . . . . . 714
35.11.2. Load Floating-Point Integer . . . . . . . . . . . . . . . . . . . . . . . . . 715
35.11.3. Load Lengthened . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 716
35.11.4. Load Rounded . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 717

Contents xi
 35.12. Decimal Floating-Point Miscellaneous Operations (*) . . . . . . . . . . . . . 718
35.12.1. Set Decimal Rounding Mode . . . . . . . . . . . . . . . . . . . . . . . . 718
35.12.2. Extract and Insert Biased Exponent . . . . . . . . . . . . . . . . . . . . 719
35.12.3. Extract Significance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 720
35.12.4. Shift Significand Left/Right . . . . . . . . . . . . . . . . . . . . . . . . . 720
35.12.5. Quantize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722
35.12.6. Reround . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724
35.12.7. Decimal Floating-Point Data Groups (*) . . . . . . . . . . . . . . . . . 726
35.13. Example of a Decimal Floating-Point “Business” Computation . . . . . . . 728
35.13.1. The Wholesaler's Calculation . . . . . . . . . . . . . . . . . . . . . . . . 728
35.13.2. The Retailer's Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . 729
35.13.3. Comparing Packed and Floating Decimal . . . . . . . . . . . . . . . . . 729
35.14. Decimal Floating-Point Binary-Significand Format (*) . . . . . . . . . . . . 730
35.15. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 731
36. Floating-Point Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 739
36.1. Floating-Point Data Representations . . . . . . . . . . . . . . . . . . . . . . . 739
36.2. Floating-Point Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 741
36.3. Floating-Point Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 741
36.4. Defining Floating-Point Constants . . . . . . . . . . . . . . . . . . . . . . . . . 742
36.5. Converting Among Decimal, Hexadecimal and Binary Representations . . . 743
36.5.1. In-Out Conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 743
36.5.2. Out-In Conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744
36.5.3. The PFPO Instruction (*) . . . . . . . . . . . . . . . . . . . . . . . . . . . 745
36.6. “Real” and “Realistic” (Floating-Point) Arithmetic . . . . . . . . . . . . . . . 745
36.7. When Does Zero Not Behave Like Zero? (*) . . . . . . . . . . . . . . . . . . . 747
36.7.1. Hexadecimal Floating-Point . . . . . . . . . . . . . . . . . . . . . . . . . . 748
36.7.2. Binary Floating-Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 748
36.7.3. Decimal Floating-Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749
36.8. Examples of Former Floating-Point Representations and Behaviors (*) . . . 749
36.9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751

Chapter X: Large Programs and Modularization . . . . . . . . . . . . . . . . . . . . . . 755

37. Subroutines and Linkage Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 756
37.1. Basic Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 756
37.1.1. Linkage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757
37.1.2. The Branch and Save Instructions . . . . . . . . . . . . . . . . . . . . . . 757
37.1.3. Argument Passing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759
37.1.4. Returned Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 762
37.1.5. Status Preservation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763
37.2. A General Linkage Convention . . . . . . . . . . . . . . . . . . . . . . . . . . 765
37.3. Argument Passing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766
37.3.1. Variable-Length Argument Lists . . . . . . . . . . . . . . . . . . . . . . . 767
37.3.2. Argument Lists with 64-Bit Addresses . . . . . . . . . . . . . . . . . . . . 768
37.4. Save Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 770
37.4.1. Extended Save Area Conventions (*) . . . . . . . . . . . . . . . . . . . . 773
37.4.2. Format-4 Save Area Conventions for 64-bit Registers (*) . . . . . . . . . 773
37.4.3. Format-5 Save Area Conventions for 32- and 64-bit Registers (*) . . . . 774
37.5. Additional Conventions (*) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777
37.5.1. Entry Point Identifiers (*) . . . . . . . . . . . . . . . . . . . . . . . . . . . 777
37.5.2. Calling Point Identifiers (*) . . . . . . . . . . . . . . . . . . . . . . . . . . 778
37.5.3. Save Area Return Flags (*) . . . . . . . . . . . . . . . . . . . . . . . . . . 778
37.5.4. Return Codes (*) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 779
37.5.5. Conventions for Floating-Point Registers . . . . . . . . . . . . . . . . . . 782
37.5.6. Main-Program Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . 782
37.6. Assisted Linkage (*) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 783
37.7. Lowest Level Subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785
37.8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 787
37.8.1. Standard Linkage Conventions . . . . . . . . . . . . . . . . . . . . . . . . 787
38. Large Programs, Control Sections, and Linking . . . . . . . . . . . . . . . . . . . . . 790
38.1. Uniform Addressability for Large Programs . . . . . . . . . . . . . . . . . . . 790
38.1.1. Other Techniques (*) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 792
38.2. Simplifying Addressability Problems in Large Programs . . . . . . . . . . . . 797

xii Assembler Language Programming for IBM System z™ Servers Version 2.00
 38.2.1. Internal Subroutines Without Local Addressability . . . . . . . . . . . . 797
38.2.2. Internal Subroutines With Local Addressability . . . . . . . . . . . . . . 798
38.2.3. Minimizing the Number of Base Registers . . . . . . . . . . . . . . . . . 799
38.2.4. Relative Branches, Immediate Operands, and Long Displacements . . . 800
38.2.5. Separating Instructions and Data . . . . . . . . . . . . . . . . . . . . . . . 800
38.3. Separate Assemblies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802
38.4. Control Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 803
38.4.1. Resuming Control Sections . . . . . . . . . . . . . . . . . . . . . . . . . . 806
38.4.2. Literals in Multi-Section Assemblies (*) . . . . . . . . . . . . . . . . . . . 808
38.4.3. Location Counter Discontinuities (*) . . . . . . . . . . . . . . . . . . . . 808
38.4.4. Section Alignment (*) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 809
38.4.5. Threaded Location Counters (*) . . . . . . . . . . . . . . . . . . . . . . . 809
38.4.6. The “Location Counter” Instruction LOCTR (*) . . . . . . . . . . . . . 810
38.5. External Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 818
38.5.1. EXTRN and WXTRN Statements . . . . . . . . . . . . . . . . . . . . . 819
38.5.2. V-Type Address Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 820
38.5.3 E N T R Y Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 821
38.5.4. The External Symbol Dictionary Listing . . . . . . . . . . . . . . . . . . 824
38.5.5. External Symbol Addressing and Residence Modes . . . . . . . . . . . . 827
38.6. Object Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 831
38.6.1. Relocation Dictionary and External Symbol Dictionary . . . . . . . . . . 832
38.7. Program Linking: Combining Object Modules . . . . . . . . . . . . . . . . . . 833
38.7.1. Assigning COMMON Sections . . . . . . . . . . . . . . . . . . . . . . . . 836
38.7.2. Relocating Address Constants . . . . . . . . . . . . . . . . . . . . . . . . 836
38.7.3. External Dummy Sections (*) . . . . . . . . . . . . . . . . . . . . . . . . . 838
38.7.4. Loading Object Modules (*) . . . . . . . . . . . . . . . . . . . . . . . . . 841
38.8. Load Modules and Program Objects . . . . . . . . . . . . . . . . . . . . . . . 845
38.8.1. External Subroutines and Assisted Linkage: Overlay (*) . . . . . . . . . . 847
38.8.2. Program Objects (*) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 848
38.8.3. The “Class Attribute” Instruction CATTR . . . . . . . . . . . . . . . . . 851
38.8.4. Programming for Program Objects . . . . . . . . . . . . . . . . . . . . . . 854
38.8.5. Comparing Load Modules and Program Objects . . . . . . . . . . . . . . 854
38.9. Loading Saved Modules into Storage . . . . . . . . . . . . . . . . . . . . . . . 855
38.9.1. Loading Load Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855
38.9.2. Loading Program Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 856
38.10. Changing Addressing Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . 858
38.10.1. The BASSM Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . 859
38.10.2. The BSM Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 860
38.10.3. Branch and Return With Addressing Mode Change . . . . . . . . . . . 861
38.10.4. Load Logical Thirty-One Bits Instructions . . . . . . . . . . . . . . . . 863
38.11. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 866

Chapter XI: Dummy Sections, Enhanced USINGs, and Data Structures . . . . . . . 871
39. Dummy Control Sections and Enhanced USING Statements . . . . . . . . . . . . . 872
39.1. Dummy Control Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 872
39.2. Multiple Data Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875
39.3. Shortcomings of Ordinary USING Statements . . . . . . . . . . . . . . . . . . 876
39.3.1. Ordinary USINGs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 877
39.4. Labeled USING Statements and Qualified Symbols . . . . . . . . . . . . . . . 882
39.4.1. Qualified Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 882
39.4.2. Dropping a Labeled USING Statement . . . . . . . . . . . . . . . . . . . 883
39.4.3. Labeled USING Statement Summary . . . . . . . . . . . . . . . . . . . . 883
39.5. Dependent USING Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . 885
39.5.1. Definition of Dependent USING Statements . . . . . . . . . . . . . . . . 886
39.5.2. Examples of Dependent USING Statements . . . . . . . . . . . . . . . . 886
39.5.3. Mapping a CSECT as a DSECT . . . . . . . . . . . . . . . . . . . . . . . 889
39.5.4. Dropping Dependent USINGs . . . . . . . . . . . . . . . . . . . . . . . . 890
39.5.5. Dependent USING Statement Summary . . . . . . . . . . . . . . . . . . 890
39.6. Labeled Dependent USING Statements . . . . . . . . . . . . . . . . . . . . . . 891
39.6.1. Nesting Structures Addressed with Ordinary USINGs . . . . . . . . . . . 892
39.6.2. Nesting Structures Addressed with Labeled USINGs . . . . . . . . . . . 892
39.6.3. Nested Structures Addressed with Labeled Dependent USINGs . . . . . 892

Contents xiii
 39.6.4. Multiple Nesting of Identical Structures . . . . . . . . . . . . . . . . . . . 893
39.6.5. Mapping an Array of Identical Data Structures . . . . . . . . . . . . . . . 895
39.6.6. Two MVS Data Control Blocks (DCBs) in a Program . . . . . . . . . . 896
39.7. Example of a Large “Personnel-File” Record (*) . . . . . . . . . . . . . . . . 897
39.7.1. Personnel-File Record Example: Comparing Birth Dates . . . . . . . . . 902
39.7.2. Personnel-File Record Example: Comparing Different Dates . . . . . . . 902
39.7.3. Personnel-File Record Example: Copying Addresses . . . . . . . . . . . 903
39.8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904
39.8.1. USING Statement Summary . . . . . . . . . . . . . . . . . . . . . . . . . 904
39.8.2. DROP Statement Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 905
40. Basic Data Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907
40.1. One-Dimensional Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 908
40.2. Two-Dimensional Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 910
40.3. General Array Subscripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 913
40.3.1. Multi-Dimensional Arrays (*) . . . . . . . . . . . . . . . . . . . . . . . . . 913
40.3.2. Non-Homogeneous Arrays (Tables) . . . . . . . . . . . . . . . . . . . . . 914
40.4. Address Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 917
40.5. Searching an Ordered Array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 919
40.6. Stacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 923
40.6.1. An Example Using a Stack . . . . . . . . . . . . . . . . . . . . . . . . . . 923
40.6.2. An Example Implementing a Stack . . . . . . . . . . . . . . . . . . . . . 924
40.7. Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 927
40.7.1. List Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 927
40.7.3. List Deletion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 929
40.7.4. Free Storage Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 929
40.8. Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 934
40.9. Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 937
40.10. Hash Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 941
40.11. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 944

Chapter XII: System Services, Reenterability, and Recursion . . . . . . . . . . . . . . 949

41. Using System Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 950
41.1. Invoking System Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 950
41.2. Invoking System Services with Macro Instructions . . . . . . . . . . . . . . . 951
41.3. Macro Formats: Standard, List, and Execute . . . . . . . . . . . . . . . . . . . 952
41.3.1. List form with Empty Argument List . . . . . . . . . . . . . . . . . . . . 953
41.3.2. Register Forms and Arguments . . . . . . . . . . . . . . . . . . . . . . . . 954
41.3.3. MODE=24, MODE=31 . . . . . . . . . . . . . . . . . . . . . . . . . . . 954
41.3.4. Mixed Case Macro Arguments . . . . . . . . . . . . . . . . . . . . . . . . 955
41.3.5. The SYSSTATE Macro . . . . . . . . . . . . . . . . . . . . . . . . . . . . 955
41.4. Causing Abnormal Termination . . . . . . . . . . . . . . . . . . . . . . . . . . 956
41.5. Storage Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 957
41.5.1. The GETMAIN Macro . . . . . . . . . . . . . . . . . . . . . . . . . . . . 958
41.5.2. The FREEMAIN Macro . . . . . . . . . . . . . . . . . . . . . . . . . . . 959
41.5.3. The STORAGE Macro . . . . . . . . . . . . . . . . . . . . . . . . . . . . 960
41.5.4. Subpools (*) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 961
41.5.5. Optional Operands (*) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 961
41.6. Basic Input and Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 962
41.6.1. A Simple Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 962
41.6.2. Access Techniques and Access Methods . . . . . . . . . . . . . . . . . . . 966
41.6.3. The Data Control Block (DCB) . . . . . . . . . . . . . . . . . . . . . . . 966
41.6.4. Important Record Formats . . . . . . . . . . . . . . . . . . . . . . . . . . 968
41.6.5. Opening the DCB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 969
41.6.6. Closing the DCB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 970
41.6.7. The DCBD Macro and the IHADCB Dummy Section . . . . . . . . . . 970
41.6.8. The DCBE Macro and 31-bit Address Mode . . . . . . . . . . . . . . . . 971
41.6.9. I/O Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 971
41.6.10. A Sample Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 971
41.7. Handling Program Interruptions . . . . . . . . . . . . . . . . . . . . . . . . . . 972
41.7.1. Program Interruptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 973
41.7.2. Establishing a Program Interruption Exit . . . . . . . . . . . . . . . . . . 973
41.7.3. Terminating a Program Interruption Exit . . . . . . . . . . . . . . . . . . 974

xiv Assembler Language Programming for IBM System z™ Servers Version 2.00
 41.7.4. Handling a Program Interruption . . . . . . . . . . . . . . . . . . . . . . . 975
41.8. Abnormal Terminations of Any Kind . . . . . . . . . . . . . . . . . . . . . . . 976
41.8.1. The ESTAE Macro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 978
41.8.2. Interruption Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 979
41.8.3. Percolation and Retry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 979
41.8.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 980
41.9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 981
42. Reenterability and Recursion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 983
42.1. Reenterability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 983
42.1.1. What it Means in General . . . . . . . . . . . . . . . . . . . . . . . . . . . 983
42.1.2. What it Means in Practice . . . . . . . . . . . . . . . . . . . . . . . . . . . 984
42.1.3. Assembly-Time Considerations . . . . . . . . . . . . . . . . . . . . . . . . 984
42.1.4. At Linking Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 984
42.1.5. Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 985
42.2. Recursion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 987
42.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 992

Appendix A: Conversion and Reference Tables . . . . . . . . . . . . . . . . . . . . . . . 995

Hexadecimal Digits in Decimal and Binary . . . . . . . . . . . . . . . . . . . . . . . . . . 995
Hexadecimal Addition and Multiplication Tables . . . . . . . . . . . . . . . . . . . . . . 996
Powers of 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 997
Multiples of Powers of Sixteen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1000
Powers of 10 in Hexadecimal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1001
Hexadecimal and Decimal Integers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1003
Conversion Tables for Hexadecimal Fractions . . . . . . . . . . . . . . . . . . . . . . . . 1011
EBCDIC Character Representation in Assembler Language Programs . . . . . . . . . . 1012
ASCII Character Representation in Assembler Language Programs . . . . . . . . . . . . 1013
DC Statement Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1014

Appendix B: Simple I/O Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1015

B.1. Macro Facilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1015
B.1.1. The CONVERTI Macro Instruction . . . . . . . . . . . . . . . . . . . . . . . . 1016
B.1.2. The CONVERTO Macro Instruction . . . . . . . . . . . . . . . . . . . . . . . 1017
B.1.3. The DUMPOUT Macro Instruction . . . . . . . . . . . . . . . . . . . . . . . . 1018
B.1.4. The PRINTLIN Macro Instruction . . . . . . . . . . . . . . . . . . . . . . . . 1018
B.1.5. The PRINTOUT Macro Instruction . . . . . . . . . . . . . . . . . . . . . . . . 1019
B.1.6. The READCARD Macro Instruction . . . . . . . . . . . . . . . . . . . . . . . 1020
B.1.7. PRINTOUT and DUMPOUT Header . . . . . . . . . . . . . . . . . . . . . . 1020
B.1.8. Usage Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1021
B.2. Sample Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1021
B.3. The Macro Instruction Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1022
B.3.1. Operating System Environment and Installation Considerations . . . . . . . . 1023
B.4.1. CONVERTI Macro Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . 1024
B.4.2. CONVERTO Macro Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 1024
B.4.3. DUMPOUT Macro Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . 1025
B.4.4. PRINTLIN Macro Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . 1026
B.4.5. PRINTOUT Macro Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . 1026
B.4.6. READCARD Macro Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 1028
B.4.7. $$GENIO Macro Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1028

Glossary of Terms and Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1041

Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1057
Basic References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1057
System/360 Architecture History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1058
Assembler Design and Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1058
Other General References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1058

Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1059

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1061

Contents xv
 Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1061

Suggested Solutions to Selected Exercises and Programming Problems . . . . . . . 1063

Section 1 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1064
Section 2 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1065
Section 3 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1071
Section 4 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1072
Section 5 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1074
Section 6 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1076
Section 7 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1077
Section 8 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1079
Section 9 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1082
Section 10 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1083
Section 11 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1085
Section 12 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1086
Section 13 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1088
Section 14 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1093
Section 15 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1096
Section 16 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1098
Section 17 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1112
Section 18 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1124
Section 19 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1137
Section 20 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1142
Section 21 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1145
Section 22 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1148
Section 23 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1156
Section 24 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1158
Section 25 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1170
Section 26 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1175
Section 27 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1180
Section 28 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1187
Section 29 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1189
Section 30 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1197
Section 31 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1204
Section 32 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1209
Section 33 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1212
Section 34 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1223
Section 35 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1230
Section 36 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1238
Section 37 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1241
Section 38 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1249
Section 39 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1261
Section 40 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1264
Section 41 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1275
Section 42 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1278

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1281

Figures
1. Example of numbering and notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2. One stage of a binary adder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3. “Circular” representation of two's complement representation . . . . . . . . . . . . . . . 36
4. Conceptual structure of a typical computer . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5. Conceptual structure of System z . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6. A byte containing 8 binary digits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7. A portion of memory, with addresses shown above each byte . . . . . . . . . . . . . . . 43
8. A portion of memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

xvi Assembler Language Programming for IBM System z™ Servers Version 2.00
 9. A single 64-bit general register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
10. All sixteen general registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
11. Four Floating-Point Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
12. Sketch of a Program Status Word . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
13. Basic instruction cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
14. Instruction formats and data interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
15. Opcode bit patterns for typical instruction types . . . . . . . . . . . . . . . . . . . . . . . 53
16. Instruction cycle with interruptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
17. Typical instruction format for old computers . . . . . . . . . . . . . . . . . . . . . . . . 61
18. Structure of an addressing halfword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
19. Sketch of Effective Address calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
20. RX-type instruction, showing index register specification digit . . . . . . . . . . . . . . . 64
21. Sketch of Effective Address calculation with indexing . . . . . . . . . . . . . . . . . . . . 64
22. 31-bit Virtual Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
23. Simple view of Assembler processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
24. Simple view of program linking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
25. Simple view of program loading and execution . . . . . . . . . . . . . . . . . . . . . . . 74
26. Assembler Language statement columns . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
27. Comment statement examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
28. Block comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
29. Statement fields for machine, assembler, and macro-instruction statements . . . . . . . 77
30. A machine instruction statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
31. An assembler instruction statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
32. The macro-instruction statement RETURN . . . . . . . . . . . . . . . . . . . . . . . . . 78
33. A complete Assembler Language program . . . . . . . . . . . . . . . . . . . . . . . . . . 81
34. RX Instruction with explicit operands . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
35. A simple program segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
36. Simple program segment with assembled contents . . . . . . . . . . . . . . . . . . . . . 118
37. Same program segment, at different memory addresses . . . . . . . . . . . . . . . . . . 118
38. Same program segment, with assembled contents . . . . . . . . . . . . . . . . . . . . . 118
39. Program segment with pre-calculated explicit base and displacements . . . . . . . . . 119
40. Program segment with explicit base and Assembler-calculated displacements . . . . . 119
41. Program Segment with USING Instruction . . . . . . . . . . . . . . . . . . . . . . . . 120
42. Sample program segment with erroneous statement . . . . . . . . . . . . . . . . . . . . 122
43. Sketch of pass one of an assembly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
44. Sketch of pass two of an assembly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
45. USING Table with one entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
46. Program segment with second USING statement . . . . . . . . . . . . . . . . . . . . . 127
47. USING Table with multiple entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
48. Assembled contents when two USINGs are active . . . . . . . . . . . . . . . . . . . . 128
49. USING Table after DROP statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
50. USING Table after second DROP statement . . . . . . . . . . . . . . . . . . . . . . . 130
51. Implied and explicit length specifications . . . . . . . . . . . . . . . . . . . . . . . . . . 140
52. Multiple constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
53. F-type constant with decimal exponent . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
54. Character, hexadecimal, and binary constants . . . . . . . . . . . . . . . . . . . . . . . 150
55. Length attribute reference to two constants, one a literal . . . . . . . . . . . . . . . . . 155
56. Describing fields of a (U.S.) telephone number . . . . . . . . . . . . . . . . . . . . . . 160
57. Describing fields of an Assembler Language statement . . . . . . . . . . . . . . . . . . 161
58. Define a group of words . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
59. Describing fields of an Assembler Language statement using ORG instructions . . . . 167
60. Describing an Assembler symbol cross-reference listing line . . . . . . . . . . . . . . . 171
61. 32-bit portion of a 64-bit general register . . . . . . . . . . . . . . . . . . . . . . . . . . 178
62. Sign extension by LH instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
63. Loss of significant digits using STH/LH . . . . . . . . . . . . . . . . . . . . . . . . . . 183
64. Loss of significant digits using STH/LH . . . . . . . . . . . . . . . . . . . . . . . . . . 183
65. Action of IC and STC instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
66. Interchanging two bytes with IC and STC . . . . . . . . . . . . . . . . . . . . . . . . . 185
67. Inserting a small number into a register . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
68. Examples of some RR-type instructions . . . . . . . . . . . . . . . . . . . . . . . . . . 188
69. 64-bit general register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
70. Sign extension by LGH instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

Figures xvii
 71. Examples of some RR-type instructions for 64-bit operands . . . . . . . . . . . . . . . 192
72. Sign extension by LHR instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
73. Sign extension for instructions with mixed 32- and 64-bit signed operands . . . . . . . 195
74. Sign extension by Load Byte instructions . . . . . . . . . . . . . . . . . . . . . . . . . . 196
75. Zero extension by Load Logical Character instructions . . . . . . . . . . . . . . . . . . 197
76. Operation of Load Logical Halfword instructions . . . . . . . . . . . . . . . . . . . . . 197
77. Operation of Load Logical word instructions . . . . . . . . . . . . . . . . . . . . . . . 197
78. Operation of Load Logical Thirty One Bits instructions . . . . . . . . . . . . . . . . . 198
79. Examples of conditional branch instructions . . . . . . . . . . . . . . . . . . . . . . . . 205
80. CNOP alignments and operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
81. Calculate a sum with an intermediate test . . . . . . . . . . . . . . . . . . . . . . . . . 217
82. Calculate the sum of the first N odd integers . . . . . . . . . . . . . . . . . . . . . . . . 218
83. Example of arithmetic addition and subtraction . . . . . . . . . . . . . . . . . . . . . . 218
84. Testing the result of arithmetic instructions . . . . . . . . . . . . . . . . . . . . . . . . 218
85. Calculate a 64-bit sum with an intermediate test . . . . . . . . . . . . . . . . . . . . . . 221
86. Adding two 64-bit numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
87. Examples of arithmetic comparisons . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
88. Calculate the sum of N odd integers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
89. Adding two 64-bit numbers logically . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
90. Double-length complementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
91. Double-length complementation, a simpler way . . . . . . . . . . . . . . . . . . . . . . 226
92. Double-length addition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
93. Double-length subtraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
94. Example of logical addition and subtraction . . . . . . . . . . . . . . . . . . . . . . . . 227
95. Double-length addition with carry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
96. Double-length subtraction with borrow . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
97. Sign extension for instructions with mixed 32- and 64-bit signed operands . . . . . . . 230
98. Calculate a 64-bit sum with an intermediate test . . . . . . . . . . . . . . . . . . . . . . 230
99. Calculate a 64-bit sum with an intermediate test . . . . . . . . . . . . . . . . . . . . . . 230
100. Sign extension for instructions with mixed 32- and 64-bit unsigned operands . . . . . 231
101. Examples of logical comparisons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
102. Comparing logically ordered values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
103. Bit positions used by IPM and SPM instructions (System/360 PSW sketch) . . . . . 234
104. Register contents before shifting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
105. Logical unit shift left . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
106. Logical unit shift right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
107. Arithmetic unit shift right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
108. Arithmetic unit shift left . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
109. Rounding an integer to the next higher multiple of 8 . . . . . . . . . . . . . . . . . . . 246
110. A 6-byte data entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
111. Storage definitions for a 6-byte data entry . . . . . . . . . . . . . . . . . . . . . . . . . 246
112. Using shift instructions for a 6-byte data item . . . . . . . . . . . . . . . . . . . . . . . 246
113. Shifting to make the low-order bit one (1) . . . . . . . . . . . . . . . . . . . . . . . . . 248
114. Shifting to make the low-order bit one (2) . . . . . . . . . . . . . . . . . . . . . . . . . 249
115. Four integers packed in a 32-bit word . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
116. Extracting one packed integer from a 32-bit word . . . . . . . . . . . . . . . . . . . . . 249
117. Unpacking four unsigned integers using right shifts . . . . . . . . . . . . . . . . . . . . 250
118. Unpacking four unsigned integers using left shifts . . . . . . . . . . . . . . . . . . . . . 250
119. Unpacking four signed integers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
120. Logical rotate unit shift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
121. Packing four unsigned bit-length constants in a 32-bit word . . . . . . . . . . . . . . . 260
122. Packing four signed bit-length constants in a 32-bit word . . . . . . . . . . . . . . . . 260
123. General layout of multiplication operands . . . . . . . . . . . . . . . . . . . . . . . . . 265
124. Double-length product of multiply operations . . . . . . . . . . . . . . . . . . . . . . . 266
125. Calculate the sum of the first 10 cubed integers . . . . . . . . . . . . . . . . . . . . . . 267
126. Illustration of binary multiplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
127. General result of divide operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
128. Operands of double-length division . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
129. Example of division by 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
130. Example of rounded integer division . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
131. Example of rounded integer division with signed dividend . . . . . . . . . . . . . . . . 277
132. Ensuring a valid arithmetic division . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277

xviii Assembler Language Programming for IBM System z™ Servers Version 2.00
133. Causing a fixed-point divide interruption . . . . . . . . . . . . . . . . . . . . . . . . . . 277
134. Operands of single-length division before division . . . . . . . . . . . . . . . . . . . . . 278
135. Operands of single-length division after division . . . . . . . . . . . . . . . . . . . . . . 278
136. Example of logical division . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
137. Illustration of binary division . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
138. Logical operations AND, OR, and XOR . . . . . . . . . . . . . . . . . . . . . . . . . . 289
139. Examples of logical operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
140. Inserting a new integer value using AND and OR . . . . . . . . . . . . . . . . . . . . . 291
141. Data masking using Exclusive OR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
142. Rounding to the next multiple of 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
143. Rounding to the next multiple of 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
144. Complementing a double-length integer . . . . . . . . . . . . . . . . . . . . . . . . . . 293
145. Effective Address generation for long-displacement instructions . . . . . . . . . . . . . 303
146. Addressability range with 12-bit displacements . . . . . . . . . . . . . . . . . . . . . . . 304
147. Addressability range with 20-bit displacements . . . . . . . . . . . . . . . . . . . . . . . 304
148. Effective Address formation for relative-immediate instructions . . . . . . . . . . . . . 305
149. Areas of memory addressed by three AMODEs . . . . . . . . . . . . . . . . . . . . . . 308
150. System z PSW showing addressing-mode bits . . . . . . . . . . . . . . . . . . . . . . . 308
151. Loading integer constants with the LAY instruction . . . . . . . . . . . . . . . . . . . 310
152. Counting number of shifts to make rightmost bit a 1-bit . . . . . . . . . . . . . . . . . 311
153. Using LA to set a branch address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
154. 64-bit Virtual Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
155. 64-bit Virtual Address with Region Indexes . . . . . . . . . . . . . . . . . . . . . . . . 314
156. Instruction classes, including RI, RIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
157. Four halfwords in a 64-bit general register . . . . . . . . . . . . . . . . . . . . . . . . . 317
158. Operation of six Insert Immediate instructions . . . . . . . . . . . . . . . . . . . . . . . 318
159. Operation of LHI instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
160. Operation of LGHI instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
161. Examples of load-immediate instructions . . . . . . . . . . . . . . . . . . . . . . . . . . 320
162. Operation of six logical load instructions . . . . . . . . . . . . . . . . . . . . . . . . . . 320
163. Extracting an unsigned integer value using AND Immediate . . . . . . . . . . . . . . . 323
164. Inserting a new integer value using AND Immediate . . . . . . . . . . . . . . . . . . . 323
165. Data masking using immediate operands . . . . . . . . . . . . . . . . . . . . . . . . . . 324
166. Data masking using a symbolically defined immediate operand . . . . . . . . . . . . . 324
167. A simple loop to scan and replace characters . . . . . . . . . . . . . . . . . . . . . . . . 332
168. A simple loop, using indexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
169. Indexing into a branch table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
170. A backward loop to scan and replace characters . . . . . . . . . . . . . . . . . . . . . . 334
171. Calculate the sum of the first N odd integers . . . . . . . . . . . . . . . . . . . . . . . . 335
172. Store the cubes of the first 10 integers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
173. Sketch of a Do-Until loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
174. Sketch of a Do-While loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
175. Store the cubes of the first 10 integers in a different way . . . . . . . . . . . . . . . . . 340
176. Operation of BXH and BXLE instructions . . . . . . . . . . . . . . . . . . . . . . . . . 342
177. Operation of BXH and BXLE instructions . . . . . . . . . . . . . . . . . . . . . . . . . 342
178. Replacing special characters with blanks, using BXLE . . . . . . . . . . . . . . . . . . 343
179. Creating a table of cubed integers using BXLE . . . . . . . . . . . . . . . . . . . . . . 344
180. Creating a table of cubed integers using BXLE . . . . . . . . . . . . . . . . . . . . . . 344
181. Creating a table of cubed integers with addresses as controls . . . . . . . . . . . . . . . 344
182. Creating a table of cubed integers using BXH . . . . . . . . . . . . . . . . . . . . . . . 346
183. Creating a table of cubed integers, using BXH in a special way . . . . . . . . . . . . . 346
184. Examples of the MVI instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
185. Examples of the NI instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
186. Examples of the OI instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
187. Example of the XI instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
188. A simpler loop to scan and replace characters . . . . . . . . . . . . . . . . . . . . . . . 355
189. Setting an overflow-indication flag bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
190. Adding alternate list elements twice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
191. Defining bit names safely . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
192. Using safely-defined bit names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
193. Converting a binary integer to characters . . . . . . . . . . . . . . . . . . . . . . . . . . 361
194. Adding alternate list elements twice, with program modification . . . . . . . . . . . . . 362

Figures xix
 195. Adding alternate list elements twice, without program modification . . . . . . . . . . . 363
196. Assembler Language syntax of basic SS-type instructions . . . . . . . . . . . . . . . . 366
197. Examples of SS-type instruction operands . . . . . . . . . . . . . . . . . . . . . . . . . 367
198. SS-type instruction using a Length Attribute reference . . . . . . . . . . . . . . . . . . 369
199. Examples of Length Specification Bytes . . . . . . . . . . . . . . . . . . . . . . . . . . 372
200. Emulated operation of MVC instruction . . . . . . . . . . . . . . . . . . . . . . . . . . 372
201. Example of Move Inverse instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
202. Emulated operation of MVCIN instruction . . . . . . . . . . . . . . . . . . . . . . . . 374
203. Example of MVCOS instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
204. Inserting bits in a word using logical SS-type instructions . . . . . . . . . . . . . . . . 377
205. Emulating the TR instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
206. TR instruction to change special characters to blanks . . . . . . . . . . . . . . . . . . . 380
207. Translating hex digits to EBCDIC characters (1) . . . . . . . . . . . . . . . . . . . . . 381
208. Translating hex digits to EBCDIC characters (2) . . . . . . . . . . . . . . . . . . . . . 381
209. Searching for punctuation characters using CLI . . . . . . . . . . . . . . . . . . . . . . 385
210. Searching for punctuation characters using TRT . . . . . . . . . . . . . . . . . . . . . 385
211. Using TRT to validate numeric characters . . . . . . . . . . . . . . . . . . . . . . . . . 385
212. Using TRT to scan for embedded quotations . . . . . . . . . . . . . . . . . . . . . . . 386
213. Using TRT to scan a string of names and build an occurrence list . . . . . . . . . . . 387
214. Using TRTR to validate numeric characters . . . . . . . . . . . . . . . . . . . . . . . . 387
215. Scanning a string backward using CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
216. Scanning a string backward using TRTR . . . . . . . . . . . . . . . . . . . . . . . . . . 388
217. Executing a list of instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
218. Executing a list of instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
219. Constructing an executed instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
220. Moving a string of bytes of unknown length . . . . . . . . . . . . . . . . . . . . . . . . 392
221. Register use by CLCL and MVCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
222. Conceptual execution of the MVCL instruction . . . . . . . . . . . . . . . . . . . . . . 406
223. Using MVCL to set a field to blanks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
224. Moving a message with padding and length checking . . . . . . . . . . . . . . . . . . . 406
225. Conceptual execution of the CLCL instruction . . . . . . . . . . . . . . . . . . . . . . 408
226. Using CLCL to test for blanks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
227. Comparing two records without padding . . . . . . . . . . . . . . . . . . . . . . . . . . 409
228. Register use by MVCLE and CLCLE . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
229. Conceptual execution of the MVCLE instruction . . . . . . . . . . . . . . . . . . . . . 412
230. Using MVCLE to set a field to blanks . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
231. Using MVCLE to initialize an area to zero . . . . . . . . . . . . . . . . . . . . . . . . . 413
232. Conceptual execution of the CLCLE instruction . . . . . . . . . . . . . . . . . . . . . 413
233. Using CLCLE to test for all blanks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
234. Registers bounding the SRST search string . . . . . . . . . . . . . . . . . . . . . . . . . 416
235. Conceptual execution of the SRST instruction . . . . . . . . . . . . . . . . . . . . . . 416
236. Conceptual execution of the MVST instruction . . . . . . . . . . . . . . . . . . . . . . 418
237. Moving a null-terminated string . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
238. Using MVST to isolate comma-separated tokens . . . . . . . . . . . . . . . . . . . . . 418
239. Conceptual execution of the CLST instruction . . . . . . . . . . . . . . . . . . . . . . 420
240. Translating characters to upper case with TRE . . . . . . . . . . . . . . . . . . . . . . 422
241. Examples using the CUSE instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
242. Fragment of an Institute-machine punched paper tape . . . . . . . . . . . . . . . . . . 428
243. Mixed single- and double-byte EBCDIC characters . . . . . . . . . . . . . . . . . . . . 434
244. Examples of DBCS data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
245. Extended continuation for DBCS data . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
246. CU-type constant generating Unicode characters . . . . . . . . . . . . . . . . . . . . . 440
247. Using MVCLU to initialize an area to Unicode spaces . . . . . . . . . . . . . . . . . . 442
248. Using CLCLU to test for Unicode spaces . . . . . . . . . . . . . . . . . . . . . . . . . 443
249. Assembler instruction statement for RRF-type instructions with an optional operand 444
250. Using TRTT to translate from DBCS to Unicode . . . . . . . . . . . . . . . . . . . . 446
251. Translating a long string with TR and MVC, and with TROO . . . . . . . . . . . . . 446
252. Bits of a UTF-16 Unicode character . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
253. Bits of a UTF-16 Unicode surrogate pair . . . . . . . . . . . . . . . . . . . . . . . . . . 447
254. Bits of a UTF-32 Unicode character from a UTF-16 surrogate pair . . . . . . . . . . 448
255. Example of using TRTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
256. Big-Endian storage representation of X'87654321' . . . . . . . . . . . . . . . . . . . . 453

xx Assembler Language Programming for IBM System z™ Servers Version 2.00

257. Little-Endian storage representation of X'87654321' . . . . . . . . . . . . . . . . . . . 453
258. Byte reversal by LRV, LRVR, and STRV instructions . . . . . . . . . . . . . . . . . . 454
259. Byte reversal by LRVH and STRVH instructions . . . . . . . . . . . . . . . . . . . . . 454
260. Four integers packed in a Big-Endian 32-bit word . . . . . . . . . . . . . . . . . . . . . 455
261. The same four integers packed in a Little-Endian 32-bit word . . . . . . . . . . . . . . 455
262. Zone and numeric digits of a byte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
263. Example of MVN and MVZ instructions . . . . . . . . . . . . . . . . . . . . . . . . . . 461
264. Zoned decimal sign conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
265. A zoned decimal number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
266. Zoned decimal constants with implied lengths . . . . . . . . . . . . . . . . . . . . . . . 464
267. Zoned decimal constants with explicit lengths . . . . . . . . . . . . . . . . . . . . . . . 464
268. Representation of a packed decimal number . . . . . . . . . . . . . . . . . . . . . . . . 466
269. Packed decimal constants with implied lengths . . . . . . . . . . . . . . . . . . . . . . 467
270. Packed decimal constants with explicit lengths . . . . . . . . . . . . . . . . . . . . . . . 467
271. Format of typical two-length SS-type instructions . . . . . . . . . . . . . . . . . . . . . 469
272. Examples of assembled PACK and UNPK instructions . . . . . . . . . . . . . . . . . 470
273. Zoned and packed forms of +12345 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
274. PACK instruction operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
275. Converting from zoned to packed decimal using PACK . . . . . . . . . . . . . . . . . 471
276. Examples of the PACK instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
277. Digit swap using PACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
278. Operation of the UNPK instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
279. Example of an UNPK instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
280. Examples of UNPK instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
281. Digit swap using UNPK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
282. Packing ASCII characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
283. Packing Unicode characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
284. Unpacking to ASCII and Unicode characters . . . . . . . . . . . . . . . . . . . . . . . 480
285. Unpacking hex digits (incorrectly) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
286. Unpacking hex digits (correctly) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482
287. Converting hex data to printable characters . . . . . . . . . . . . . . . . . . . . . . . . 482
288. Operands for packed decimal division . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
289. Assembler Language syntax of the TP instruction . . . . . . . . . . . . . . . . . . . . . 498
290. Examples of the ZAP instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
291. Using ZAP to initialize a table of packed decimal operands . . . . . . . . . . . . . . . 500
292. Initializing a table of decimal numbers using MVC . . . . . . . . . . . . . . . . . . . . 500
293. Examples of the AP and SP instructions . . . . . . . . . . . . . . . . . . . . . . . . . . 502
294. Adding a table of 50 packed decimal numbers . . . . . . . . . . . . . . . . . . . . . . . 502
295. Adding positive and negative items separately . . . . . . . . . . . . . . . . . . . . . . . 504
296. Finding the largest item in a table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505
297. Example of decimal multiplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506
298. Using MP to square a table of decimal numbers . . . . . . . . . . . . . . . . . . . . . 507
299. Using ZAP to set correct decimal multiplicand length . . . . . . . . . . . . . . . . . . 507
300. Using ZAP to set correct decimal multiplicand length . . . . . . . . . . . . . . . . . . 507
301. Generating 0 − using MP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508
302. Decimal division using DP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509
303. Decimal division using Length Attribute References for operands . . . . . . . . . . . . 509
304. Computing the average of a table of decimal numbers . . . . . . . . . . . . . . . . . . 510
305. Assembler Language format of SRP machine instruction statement . . . . . . . . . . 511
306. Shifting a decimal operand left 3 places using SRP . . . . . . . . . . . . . . . . . . . . 512
307. Shifting a decimal operand right 2 places using SRP . . . . . . . . . . . . . . . . . . . 512
308. Shifting a decimal operand right 1 place with rounding using SRP . . . . . . . . . . . 513
309. Shifting a decimal operand with an EXecuted SRP . . . . . . . . . . . . . . . . . . . . 513
310. Operation of the MVO instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516
311. Two Examples of MVO results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516
312. Shifting a decimal operand right an odd number of digits . . . . . . . . . . . . . . . . 518
313. Shifting a decimal operand right an odd number of digits . . . . . . . . . . . . . . . . 518
314. Shifting a decimal operand left an odd number of digits . . . . . . . . . . . . . . . . . 519
315. Shifting a decimal operand left by one digit . . . . . . . . . . . . . . . . . . . . . . . . 519
316. Shifting a decimal operand left by three or more digits . . . . . . . . . . . . . . . . . . 519
317. Shifting a decimal operand left an even number of digits . . . . . . . . . . . . . . . . . 520
318. Shifting a decimal operand left an even number of digits . . . . . . . . . . . . . . . . . 520

Figures xxi
 319. Shifting a decimal operand left an even number of digits . . . . . . . . . . . . . . . . . 520
320. Shifting a decimal operand right an even number of digits . . . . . . . . . . . . . . . . 520
321. Shifting a decimal operand right an even number of digits . . . . . . . . . . . . . . . . 521
322. Ensuring decimal point alignment for packed decimal addition . . . . . . . . . . . . . 523
323. A business calculation in packed decimal, part 1 . . . . . . . . . . . . . . . . . . . . . . 527
324. A business calculation in packed decimal, part 2 . . . . . . . . . . . . . . . . . . . . . . 527
325. A business calculation in packed decimal, part 3 . . . . . . . . . . . . . . . . . . . . . . 528
326. A business calculation in packed decimal, part 4 . . . . . . . . . . . . . . . . . . . . . . 528
327. Integer and Scale Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529
328. Using Scale Attributes in a SRP instruction . . . . . . . . . . . . . . . . . . . . . . . . 529
329. Converting a 64-bit binary integer to packed decimal . . . . . . . . . . . . . . . . . . . 533
330. Using CVD to format page numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533
331. Converting decimal characters to binary . . . . . . . . . . . . . . . . . . . . . . . . . . 535
332. Sketch of an editing operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536
333. Representation of an editing pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537
334. Convert a packed decimal integer to characters using UNPK . . . . . . . . . . . . . . 538
335. Convert a packed decimal integer to characters using ED . . . . . . . . . . . . . . . . 538
336. Converting a 32-bit binary integer to characters . . . . . . . . . . . . . . . . . . . . . . 540
337. Editing a binary integer with separating commas . . . . . . . . . . . . . . . . . . . . . 541
338. Editing a signed number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542
339. Using field protection with ED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542
340. Edited result with a floating currency symbol . . . . . . . . . . . . . . . . . . . . . . . 543
341. Edited result with a properly placed floating currency symbol . . . . . . . . . . . . . . 544
342. Integer value with optional sign and separating commas . . . . . . . . . . . . . . . . . 544
343. Editing two packed decimal numbers into a single field . . . . . . . . . . . . . . . . . . 545
344. Editing multiple values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545
345. Logical-operation description of the editing process . . . . . . . . . . . . . . . . . . . . 547
346. ED and EDMK operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548
347. A data item containing an integer value . . . . . . . . . . . . . . . . . . . . . . . . . . . 552
348. A data item containing integer and fraction parts . . . . . . . . . . . . . . . . . . . . . 552
349. Values with radix point outside the digits . . . . . . . . . . . . . . . . . . . . . . . . . . 553
350. Calculating a tax amount in scaled fixed decimal arithmetic . . . . . . . . . . . . . . . 553
351. Calculating a tax amount in scaled fixed binary arithmetic . . . . . . . . . . . . . . . . 554
352. Two binary constants scaled by 2**28 . . . . . . . . . . . . . . . . . . . . . . . . . . . 555
353. Defining a scaled binary constant 10**12 . . . . . . . . . . . . . . . . . . . . . . . . . . 555
354. Multiplying two scaled binary numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . 556
355. Examples of data with widely ranging values . . . . . . . . . . . . . . . . . . . . . . . . 559
356. A typical floating-point representation . . . . . . . . . . . . . . . . . . . . . . . . . . . 560
357. An example of a floating-point representation using 4 decimal digits . . . . . . . . . . 561
358. Another example of a floating-point representation using 4 decimal digits . . . . . . . 561
359. A floating-point representation showing left normalized and unnormalized values . . 561
360. A floating-point representation showing right normalized and unnormalized values . 562
361. A floating-point representation showing values without normalization . . . . . . . . . 562
362. Floating-point numbers with signed exponent . . . . . . . . . . . . . . . . . . . . . . . 563
363. Examples of approximate floating-point representations . . . . . . . . . . . . . . . . . 563
364. Three floating-point data lengths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564
365. Four floating-point registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564
366. All sixteen floating-point registers, showing register pairings . . . . . . . . . . . . . . . 566
367. Integer-based representation of 73 in FPI(10,4) . . . . . . . . . . . . . . . . . . . . . . 577
368. Illustrating floating-point division corrective right shift . . . . . . . . . . . . . . . . . . 578
369. Exponent range of representable and computable values . . . . . . . . . . . . . . . . . 583
370. Hexadecimal floating-point number representations . . . . . . . . . . . . . . . . . . . . 587
371. Quadword aligned constants and data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594
372. Hexadecimal floating-point constants with rounding suffixes . . . . . . . . . . . . . . . 595
373. Examples of hexadecimal floating-point instructions . . . . . . . . . . . . . . . . . . . 598
374. Example of LTXR instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598
375. Examples of extended-precision hexadecimal RR instructions . . . . . . . . . . . . . . 598
376. Short hexadecimal floating-point multiplication . . . . . . . . . . . . . . . . . . . . . . 599
377. Floating-point registers used for hexadecimal floating-point multiplication . . . . . . . 600
378. Calculating a table of short hexadecimal floating-point products . . . . . . . . . . . . 600
379. Calculating a table of long hexadecimal floating-point products . . . . . . . . . . . . . 600
380. Floating-point registers used for hexadecimal floating-point multiplication . . . . . . . 601

xxii Assembler Language Programming for IBM System z™ Servers Version 2.00
381. Example of hexadecimal floating-point divide instructions . . . . . . . . . . . . . . . . 604
382. Example of hexadecimal floating-point divide instructions . . . . . . . . . . . . . . . . 604
383. Example of a hexadecimal floating-point halve instruction . . . . . . . . . . . . . . . . 605
384. Hexadecimal halve instruction causing underflow . . . . . . . . . . . . . . . . . . . . . 605
385. Example of hexadecimal floating-point addition . . . . . . . . . . . . . . . . . . . . . . 606
386. Evaluating a hexadecimal floating-point expression . . . . . . . . . . . . . . . . . . . . 607
387. Evaluating a hexadecimal floating-point inner product . . . . . . . . . . . . . . . . . . 608
388. Evaluating a polynomial with hexadecimal floating-point arithmetic . . . . . . . . . . 608
389. Evaluating a quadratic polynomial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 608
390. Converting a binary integer to hexadecimal floating-point . . . . . . . . . . . . . . . . 609
391. Converting a hexadecimal floating-point number to a binary integer . . . . . . . . . . 610
392. Rounding a long hexadecimal floating-point number to short . . . . . . . . . . . . . . 617
393. Rounded inner product of long HFP numbers . . . . . . . . . . . . . . . . . . . . . . . 617
394. Manually rounding long to short (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618
395. Manually rounding long to short (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618
396. Manually rounding long to short (3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618
397. Converting a 32-bit integer to short hexadecimal floating-point . . . . . . . . . . . . . 620
398. Converting a 64-bit integer to three hexadecimal floating-point values . . . . . . . . . 620
399. Early conversion of integer to hexadecimal floating-point . . . . . . . . . . . . . . . . 621
400. Format of a machine instruction statement for converting HFP to binary . . . . . . . 621
401. Calculating a HFP remainder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625
402. Evaluating a hexadecimal floating-point remainder . . . . . . . . . . . . . . . . . . . . 626
403. Examples of HFP square root instructions . . . . . . . . . . . . . . . . . . . . . . . . . 627
404. Three binary floating-point data representations . . . . . . . . . . . . . . . . . . . . . . 639
405. Range of the binary floating-point representation . . . . . . . . . . . . . . . . . . . . . 641
406. A view of the binary floating-point representation . . . . . . . . . . . . . . . . . . . . . 642
407. Examples of short binary floating-point constants . . . . . . . . . . . . . . . . . . . . . 642
408. Examples of long and extended binary floating-point constants . . . . . . . . . . . . . 643
409. Rounding indicators for binary floating-point constants . . . . . . . . . . . . . . . . . 643
410. Examples of parameterized binary floating-point NaNs . . . . . . . . . . . . . . . . . . 644
411. Binary floating-point constants with decimal exponents and modifiers . . . . . . . . . 645
412. Values representable with gradual underflow . . . . . . . . . . . . . . . . . . . . . . . . 647
413. Floating-Point Control (FPC) register . . . . . . . . . . . . . . . . . . . . . . . . . . . 649
414. Examples of binary floating-point data movement instructions . . . . . . . . . . . . . 656
415. Example of binary floating-point multiply instructions . . . . . . . . . . . . . . . . . . 657
416. Examples of binary floating-point multiplication overflow and underflow . . . . . . . 658
417. Examples of binary floating-point multiply instructions . . . . . . . . . . . . . . . . . 658
418. Example of binary floating-point denormalized product . . . . . . . . . . . . . . . . . 658
419. Example of binary floating-point extended-precision operands . . . . . . . . . . . . . . 658
420. Examples of binary floating-point division . . . . . . . . . . . . . . . . . . . . . . . . . 659
421. Examples of binary floating-point division overflow and underflow . . . . . . . . . . . 660
422. Examples of binary floating-point addition and subtraction . . . . . . . . . . . . . . . 661
423. Examples of binary floating-point comparison . . . . . . . . . . . . . . . . . . . . . . . 663
424. Examples of binary floating-point compare and signal instructions . . . . . . . . . . . 663
425. Examples of binary floating-point rounding instructions . . . . . . . . . . . . . . . . . 664
426. Examples of BFP load lengthened instructions . . . . . . . . . . . . . . . . . . . . . . 665
427. Examples of BFP load lengthened instructions with NaNs . . . . . . . . . . . . . . . . 665
428. Examples of binary integer to binary floating-point instructions . . . . . . . . . . . . . 666
429. Examples of converting binary floating-point fractions to integers with rounding . . . 667
430. Examples of Convert to Fixed instructions . . . . . . . . . . . . . . . . . . . . . . . . . 667
431. Examples of load FP integer instructions . . . . . . . . . . . . . . . . . . . . . . . . . . 669
432. Examples of divide to integer instructions . . . . . . . . . . . . . . . . . . . . . . . . . 670
433. Example of iterative divide to integer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 670
434. Iterative execution of a divide to integer instruction . . . . . . . . . . . . . . . . . . . . 671
435. Examples of binary floating-point square root instructions . . . . . . . . . . . . . . . . 672
436. Example of binary floating-point multiply and add instructions . . . . . . . . . . . . . 673
437. Hexadecimal and binary floating-point representations . . . . . . . . . . . . . . . . . . 681
438. Conceptual decimal floating-point representation . . . . . . . . . . . . . . . . . . . . . 682
439. Three decimal floating-point representations of the same value . . . . . . . . . . . . . 683
440. Decimal floating-point data representation . . . . . . . . . . . . . . . . . . . . . . . . . 686
441. System z decimal floating-point representations . . . . . . . . . . . . . . . . . . . . . . 687
442. DFP constants with exponent modifiers and decimal exponents . . . . . . . . . . . . . 692

Figures xxiii
 443. Examples of decimal floating-point Test Data Class instructions . . . . . . . . . . . . 694
444. Illustration of decimal floating-point rounding candidates . . . . . . . . . . . . . . . . 695
445. Illustration of decimal floating-point rounding candidates near zero . . . . . . . . . . . 695
446. Floating-Point Control (FPC) register . . . . . . . . . . . . . . . . . . . . . . . . . . . 698
447. Examples of converting decimal floating-point to fixed binary . . . . . . . . . . . . . . 708
448. Examples of converting decimal floating-point to binary integer . . . . . . . . . . . . . 709
449. Converting signed packed decimal to decimal floating-point . . . . . . . . . . . . . . . 710
450. Converting decimal floating-point to signed packed decimal . . . . . . . . . . . . . . . 710
451. Converting decimal floating-point to signed packed decimal . . . . . . . . . . . . . . . 710
452. Converting unsigned packed decimal to decimal floating-point . . . . . . . . . . . . . 711
453. Converting decimal floating-point to unsigned packed decimal . . . . . . . . . . . . . 711
454. Effect of the mask operand on Convert from Zoned results . . . . . . . . . . . . . . . 713
455. Examples of converting decimal floating-point to zoned . . . . . . . . . . . . . . . . . 714
456. DFP arithmetic with short operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . 717
457. Floating-Point Control Register showing Decimal Rounding Mode bits . . . . . . . . 718
458. Example of extracting DFP biased exponent . . . . . . . . . . . . . . . . . . . . . . . . 719
459. Example of inserting a biased DFP exponent . . . . . . . . . . . . . . . . . . . . . . . 720
460. Examples of DFP Extract Significance instructions . . . . . . . . . . . . . . . . . . . . 720
461. Converting an extended decimal floating-point value to packed decimal . . . . . . . . 722
462. Calculate price plus tax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724
463. Correctly rounding a cost to two decimal digits . . . . . . . . . . . . . . . . . . . . . . 724
464. Example of a reround instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725
465. Example of rerounding arbitrary amounts . . . . . . . . . . . . . . . . . . . . . . . . . 725
466. Examples of assembled DFP constants using rounding for reround . . . . . . . . . . . 726
467. Example of DFP binary-significand format . . . . . . . . . . . . . . . . . . . . . . . . . 730
468. Sketch of short binary-significand format . . . . . . . . . . . . . . . . . . . . . . . . . . 730
469. BCD-to-DPD encodings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734
470. DPD-to-BCD translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735
471. Degraded precision in adding hexadecimal floating-point pseudo-zeros . . . . . . . . . 748
472. Trivial example of a subroutine (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757
473. Trivial example of a subroutine (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757
474. Subroutine linkage using a BAS instruction . . . . . . . . . . . . . . . . . . . . . . . . 758
475. Subroutine linkage using a BASR instruction . . . . . . . . . . . . . . . . . . . . . . . 759
476. Subroutine linkage using an address constant . . . . . . . . . . . . . . . . . . . . . . . 759
477. Simple shift subroutine (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 760
478. Simple shift subroutine (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 760
479. Simple shift subroutine with named arguments (3) . . . . . . . . . . . . . . . . . . . . 760
480. Simple shift subroutine (4) using argument addresses . . . . . . . . . . . . . . . . . . . 761
481. Simple shift subroutine (5) with argument addresses in memory . . . . . . . . . . . . . 761
482. Subroutine call with inline arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . 761
483. Subroutine returning past inline argument . . . . . . . . . . . . . . . . . . . . . . . . . 762
484. Subroutine call with inline argument addresses . . . . . . . . . . . . . . . . . . . . . . . 762
485. Subroutine with argument address list . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763
486. Subroutine saves and restores registers . . . . . . . . . . . . . . . . . . . . . . . . . . . 764
487. General argument-passing scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766
488. Subroutine call using an argument address list . . . . . . . . . . . . . . . . . . . . . . . 766
489. Subroutine called with an argument address list . . . . . . . . . . . . . . . . . . . . . . 766
490. Constructing an argument address list . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767
491. Two variable-length argument lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767
492. Calling a subroutine with a variable-length argument list . . . . . . . . . . . . . . . . . 767
493. Subroutine called with a variable-length argument list . . . . . . . . . . . . . . . . . . 767
494. Sketch of a variable-length argument list . . . . . . . . . . . . . . . . . . . . . . . . . . 768
495. Sample 64-bit argument list addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . 768
496. Standard save area layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 771
497. Sample subroutine calling sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 771
498. Save area chaining instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 772
499. Chained save areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 772
500. Reloading registers and returning to a caller . . . . . . . . . . . . . . . . . . . . . . . . 772
501. Format-4 save area layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774
502. Example of using a Format-4 save area . . . . . . . . . . . . . . . . . . . . . . . . . . . 774
503. Format-5 save area layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775
504. Saving registers using a Format-5 save area . . . . . . . . . . . . . . . . . . . . . . . . . 776

xxiv Assembler Language Programming for IBM System z™ Servers Version 2.00
505. Return from a routine using a Format-5 save area . . . . . . . . . . . . . . . . . . . . 776
506. Example of an entry point identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777
507. Example of two calling point identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . 778
508. Setting a return flag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778
509. Setting a return code in register 15 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 779
510. Testing a return code returned in register 15 . . . . . . . . . . . . . . . . . . . . . . . . 780
511. Using a return code as a branch index . . . . . . . . . . . . . . . . . . . . . . . . . . . 780
512. Using a return code as a branch index with relative branch instructions . . . . . . . . 780
513. Checking for valid return code values . . . . . . . . . . . . . . . . . . . . . . . . . . . . 780
514. Setting a reason code in register 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 781
515. Using RETURN macros to set return flags and return codes . . . . . . . . . . . . . . 781
516. Returning to an error branch without a return code . . . . . . . . . . . . . . . . . . . . 781
517. Call with error branch instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 782
518. Convention for passing main-program parameters . . . . . . . . . . . . . . . . . . . . . 782
519. Example of calling with assisted linkage . . . . . . . . . . . . . . . . . . . . . . . . . . . 784
520. Example of a routine to implement assisted linkage . . . . . . . . . . . . . . . . . . . . 784
521. Assisted linkage routine with counters . . . . . . . . . . . . . . . . . . . . . . . . . . . 784
522. Example of a lowest level subroutine . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786
523. Establish three base registers (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 791
524. Establish three base registers (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 791
525. Establish three base registers (3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 791
526. Establish three base registers (4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 792
527. Establish three base registers (5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 792
528. Establish three base registers with risks (6) . . . . . . . . . . . . . . . . . . . . . . . . . 792
529. Establish three base registers (7) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 793
530. Establish three base registers (8) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 793
531. Establish three base registers (9) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 793
532. Calling a subroutine not needing local addressability . . . . . . . . . . . . . . . . . . . 798
533. Calling a subroutine not locally addressable . . . . . . . . . . . . . . . . . . . . . . . . 799
534. Subroutine with local addressability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 799
535. Replacing based branch instructions with relative-immediates . . . . . . . . . . . . . . 800
536. Replacing a based EXecute instruction with EXRL . . . . . . . . . . . . . . . . . . . . 800
537. Replacing references to constants with immediate operands . . . . . . . . . . . . . . . 800
538. Replacing short unsigned displacements with long signed displacements . . . . . . . . 800
539. A program fragment needing reorganization . . . . . . . . . . . . . . . . . . . . . . . . 801
540. A program fragment after reorganization . . . . . . . . . . . . . . . . . . . . . . . . . . 801
541. Reorganizing a program to minimize base registers . . . . . . . . . . . . . . . . . . . . 801
542. Incorrect implied reference to a different control section . . . . . . . . . . . . . . . . . 804
543. Correct implied reference to a different control section . . . . . . . . . . . . . . . . . . 804
544. USING Table with two entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805
545. Main program and subroutine in one assembly . . . . . . . . . . . . . . . . . . . . . . 805
546. Main program, subroutine, and common section in one assembly . . . . . . . . . . . 806
547. Resuming control sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806
548. Main program and subroutine in one assembly, multiple CSects . . . . . . . . . . . . 807
549. Statements with Location Counter discontinuities . . . . . . . . . . . . . . . . . . . . . 808
550. Technique for rounding the length of a CSECT . . . . . . . . . . . . . . . . . . . . . . 809
551. Rearrangement of source groups by LOCTR . . . . . . . . . . . . . . . . . . . . . . . 811
552. Simple example of LOCTR (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 811
553. Simple example of LOCTR (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 812
554. Simple example of LOCTR (3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 812
555. A program fragment using LOCTR for reorganization . . . . . . . . . . . . . . . . . . 812
556. Organizing a program to minimize addressability problems . . . . . . . . . . . . . . . 813
557. Organizing a program to minimize addressability problems . . . . . . . . . . . . . . . 813
558. Simple example of LOCTR (4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814
559. Example of unexpected LOCTR behavior (1) . . . . . . . . . . . . . . . . . . . . . . . 814
560. Example of unexpected LOCTR behavior (2) . . . . . . . . . . . . . . . . . . . . . . . 815
561. Calling ShftRt as an external routine . . . . . . . . . . . . . . . . . . . . . . . . . . . . 819
562. ShftRt subroutine as a separate assembly . . . . . . . . . . . . . . . . . . . . . . . . . . 819
563. External references using relative branch instructions . . . . . . . . . . . . . . . . . . . 820
564. Using WXTRN to test whether a routine was linked . . . . . . . . . . . . . . . . . . . 820
565. Calling ShftRt as an external routine . . . . . . . . . . . . . . . . . . . . . . . . . . . . 821
566. ShftRt subroutine in a different CSect . . . . . . . . . . . . . . . . . . . . . . . . . . . 822

Figures xxv
 567. Main program with ENTRY for data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 822
568. Subroutine using EXTRN to reference data . . . . . . . . . . . . . . . . . . . . . . . . 822
569. Subroutine using EXTRN and adcons to reference data . . . . . . . . . . . . . . . . . 823
570. Subroutine with entries for two similar functions . . . . . . . . . . . . . . . . . . . . . 824
571. Subroutine with two similar functions and some common code . . . . . . . . . . . . . 824
572. Sample assembly with external symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . 825
573. External symbol dictionary from sample assembly . . . . . . . . . . . . . . . . . . . . 825
574. Program assembled with different SECTALGN options . . . . . . . . . . . . . . . . . 827
575. Example of ESD listings with different SECTALGN options . . . . . . . . . . . . . . 827
576. Assigning RMODE and AMODE to a section name . . . . . . . . . . . . . . . . . . . 828
577. ESD showing RMODE and AMODE of section names . . . . . . . . . . . . . . . . . 829
578. Example of two source modules to be linked . . . . . . . . . . . . . . . . . . . . . . . 834
579. Sketch of object module from source module 1 . . . . . . . . . . . . . . . . . . . . . . 834
580. Sketch of object module from source module 2 . . . . . . . . . . . . . . . . . . . . . . 835
581. Composite ESD after reading first object module . . . . . . . . . . . . . . . . . . . . . 835
582. Composite ESD after loading second object module . . . . . . . . . . . . . . . . . . . 836
583. Composite ESD after assigning memory addresses . . . . . . . . . . . . . . . . . . . . 836
584. Memory layout of loaded program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837
585. Sample DXD declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 838
586. External dummy section declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 838
587. Referencing external dummy items with Q-cons . . . . . . . . . . . . . . . . . . . . . . 838
588. External dummy items in ESD listing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 839
589. Separate DXD declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 839
590. Example of a completed External Dummy Section . . . . . . . . . . . . . . . . . . . . 839
591. Retrieving an External Dummy Section item . . . . . . . . . . . . . . . . . . . . . . . 840
592. PL/I technique for loading Pseudo Registers . . . . . . . . . . . . . . . . . . . . . . . . 840
593. ESDID Translation Table entry for an incoming symbol . . . . . . . . . . . . . . . . . 842
594. A typical load-time CESD entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 842
595. Composite ESD after assigning load module addresses . . . . . . . . . . . . . . . . . . 845
596. Sketch of a load module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 846
597. A load module after loading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 847
598. Sketch of program object structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 849
599. Sample program assembled with the GOFF option . . . . . . . . . . . . . . . . . . . . 849
600. ESD from program assembled with the GOFF option . . . . . . . . . . . . . . . . . . 850
601. Assigning AMODE to an entry symbol . . . . . . . . . . . . . . . . . . . . . . . . . . . 851
602. ESD showing AMODE assigned to entry and external symbols . . . . . . . . . . . . . 851
603. Sample program defining two Sections and three Classes . . . . . . . . . . . . . . . . . 851
604. Assignment of instructions and data into elements . . . . . . . . . . . . . . . . . . . . 851
605. Assembly listing for sample program . . . . . . . . . . . . . . . . . . . . . . . . . . . . 852
606. External symbol dictionary for sample program . . . . . . . . . . . . . . . . . . . . . . 852
607. Example of declaring parts in a GOFF Class . . . . . . . . . . . . . . . . . . . . . . . 853
608. ESD for parts in a GOFF Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853
609. Sketch of virtual memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856
610. Sample program defining two Sections and three Classes . . . . . . . . . . . . . . . . . 856
611. Sketch of classes in virtual memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857
612. System z PSW showing addressing-mode bits . . . . . . . . . . . . . . . . . . . . . . . 858
613. Important addressing mode bits for BASSM . . . . . . . . . . . . . . . . . . . . . . . . 859
614. BASSM setting of first-operand register for 24-, 31-, and 64-bit addressing modes . . 859
615. Sketch of residence and addressing modes . . . . . . . . . . . . . . . . . . . . . . . . . 863
616. Example showing why LLGT/LLGTR are necessary . . . . . . . . . . . . . . . . . . . 864
617. Example showing why LLGTR is important . . . . . . . . . . . . . . . . . . . . . . . 865
618. Example of a dummy control section . . . . . . . . . . . . . . . . . . . . . . . . . . . . 873
619. Example using a dummy control section . . . . . . . . . . . . . . . . . . . . . . . . . . 873
620. USING Table with two entries, one for a dummy section . . . . . . . . . . . . . . . . 874
621. Object code from references to a dummy control section . . . . . . . . . . . . . . . . . 874
622. Example using a dummy control section . . . . . . . . . . . . . . . . . . . . . . . . . . 874
623. A poor method for describing two instances of a record . . . . . . . . . . . . . . . . . 875
624. A better record description with a DSECT . . . . . . . . . . . . . . . . . . . . . . . . . 876
625. Ordinary USING statement syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 876
626. Copying a field from Old record to New . . . . . . . . . . . . . . . . . . . . . . . . . . 877
627. Incorrect addressing with ordinary USING . . . . . . . . . . . . . . . . . . . . . . . . . 878
628. Correct but awkward addressing with ordinary USING . . . . . . . . . . . . . . . . . 878

xxvi Assembler Language Programming for IBM System z™ Servers Version 2.00
629. Manual coding of base and displacement for a large DSECT . . . . . . . . . . . . . . 879
630. Labeled USING statement syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 882
631. Qualified symbol syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 882
632. Examples of qualifier definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 882
633. Copying a field with Labeled USINGs . . . . . . . . . . . . . . . . . . . . . . . . . . . 883
634. DROP statement for Labeled USING . . . . . . . . . . . . . . . . . . . . . . . . . . . 883
635. Concurrently active Ordinary and Labeled USINGs . . . . . . . . . . . . . . . . . . . 884
636. Dummy control section for record address . . . . . . . . . . . . . . . . . . . . . . . . . 885
637. Improved definition of a record description . . . . . . . . . . . . . . . . . . . . . . . . 885
638. Mapping a substructure with a second DSECT . . . . . . . . . . . . . . . . . . . . . . 886
639. Dependent USING statement syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 886
640. Anchoring an internal DSECT with a Dependent USING . . . . . . . . . . . . . . . . 887
641. Outer DSECT with two nested DSECTs . . . . . . . . . . . . . . . . . . . . . . . . . . 887
642. Assembler listing of multiple Dependent USINGs and DSECTs . . . . . . . . . . . . 888
643. Three independent data structures with one base register . . . . . . . . . . . . . . . . . 888
644. Defining DSECTs for three independent data structures . . . . . . . . . . . . . . . . . 889
645. Defining a mapping of three independent but contiguous data structures . . . . . . . . 889
646. Example of a message-skeleton CSECT . . . . . . . . . . . . . . . . . . . . . . . . . . 889
647. Example of mapping a CSECT as though it is a DSECT . . . . . . . . . . . . . . . . 890
648. Labeled Dependent USING statement syntax . . . . . . . . . . . . . . . . . . . . . . . 891
649. Nesting two identical structures within a third . . . . . . . . . . . . . . . . . . . . . . . 891
650. Addressing two nested DSECTs with Labeled Dependent USINGs . . . . . . . . . . 893
651. Data in nested DSECTs addressed with Labeled Dependent USINGs . . . . . . . . . 893
652. Multiply-Nested Data Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893
653. Doubly Nested DSECT definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 894
654. Addressing doubly nested DSECT definitions . . . . . . . . . . . . . . . . . . . . . . . 894
655. Using the Labeled Dependent USINGs to move data . . . . . . . . . . . . . . . . . . 895
656. Addressing two DCBs with ordinary USINGs . . . . . . . . . . . . . . . . . . . . . . . 896
657. Addressing instructions and DCBs with one register . . . . . . . . . . . . . . . . . . . 897
658. Define a personnel-file record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 898
659. Employee-record Person DSECT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 898
660. Employee-record Date DSECT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 898
661. Employee-record Address DSECT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 899
662. Employee-record Phone DSECT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 899
663. DSECT nesting in an employee record . . . . . . . . . . . . . . . . . . . . . . . . . . . 900
664. Anchoring various DSECTs within Employee record . . . . . . . . . . . . . . . . . . . 901
665. Manipulating fields within an Employee record . . . . . . . . . . . . . . . . . . . . . . 901
666. Addressing DSECTs within Employee record with ordinary USINGs . . . . . . . . . 901
667. Comparing dates of birth in Employee record . . . . . . . . . . . . . . . . . . . . . . . 902
668. Comparing date fields in different parts of an Employee record . . . . . . . . . . . . . 902
669. Copying addresses with an Employee Record . . . . . . . . . . . . . . . . . . . . . . . 903
670. Example of a one-dimensional array of halfwords . . . . . . . . . . . . . . . . . . . . . 908
671. Sum of array elements with known subscript bounds . . . . . . . . . . . . . . . . . . . 908
672. Sum of array elements with unknown subscript bounds . . . . . . . . . . . . . . . . . 909
673. Typical arrangement of elements of a matrix . . . . . . . . . . . . . . . . . . . . . . . . 910
674. Storing an array in column order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 910
675. Storing an array in row order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 910
676. Retrieving a specified element of an array . . . . . . . . . . . . . . . . . . . . . . . . . 911
677. Retrieving a specified element of an array efficiently . . . . . . . . . . . . . . . . . . . 912
678. Searching for a matching table entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . 914
679. Searching for a table entry mapped by a DSECT . . . . . . . . . . . . . . . . . . . . . 915
680. USING Table with two entries, one for a DSECT . . . . . . . . . . . . . . . . . . . . 915
681. Creating a table of addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 917
682. Creating a better table of addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 917
683. Creating a table of addresses at assembly time . . . . . . . . . . . . . . . . . . . . . . . 918
684. Example of a binary search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 921
685. A stack growing toward higher addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 924
686. A stack implemented as an array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 924
687. Pushing a data item onto a stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 924
688. Adding top two elements of a stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925
689. A stack growing toward lower addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 925
690. Add top two elements of a stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925

Figures xxvii
 691. Sketch of a linked list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 927
692. Inserting an element into a linked list . . . . . . . . . . . . . . . . . . . . . . . . . . . . 928
693. Example of inserting an element into a linked list . . . . . . . . . . . . . . . . . . . . . 928
694. DSECT describing a list element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 928
695. Mapping multiple list elements with Labeled USINGs . . . . . . . . . . . . . . . . . . 928
696. Deleting an element from a linked list . . . . . . . . . . . . . . . . . . . . . . . . . . . . 929
697. Example of deleting an element from a linked list . . . . . . . . . . . . . . . . . . . . . 929
698. Example of deleting an element from a linked list . . . . . . . . . . . . . . . . . . . . . 929
699. Defining a free storage list as an array . . . . . . . . . . . . . . . . . . . . . . . . . . . . 930
700. Initializing a free storage list as an array . . . . . . . . . . . . . . . . . . . . . . . . . . 930
701. Example of a list anchor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 930
702. DSECT mapping a list anchor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 930
703. Defining an anchor for a working list . . . . . . . . . . . . . . . . . . . . . . . . . . . . 931
704. Moving a list element from the FSL to the working list . . . . . . . . . . . . . . . . . 931
705. A two-dimensional array to implement a linked list . . . . . . . . . . . . . . . . . . . . 932
706. Initializing a two-dimensional array implementing a linked list . . . . . . . . . . . . . 932
707. Structure of a queue element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 934
708. A queue with several elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 934
709. DSECT structure of a typical queue element . . . . . . . . . . . . . . . . . . . . . . . . 934
710. An element to be inserted into a queue . . . . . . . . . . . . . . . . . . . . . . . . . . . 935
711. A queue after insertion of a new element . . . . . . . . . . . . . . . . . . . . . . . . . . 935
712. Instructions to insert a new queue element . . . . . . . . . . . . . . . . . . . . . . . . . 935
713. Insert a new list element with ordinary USINGs . . . . . . . . . . . . . . . . . . . . . 936
714. Ordinary-USING Code to Insert a New List Element . . . . . . . . . . . . . . . . . . 936
715. Labeled USING example: inserting a new queue element . . . . . . . . . . . . . . . . 936
716. Node of a binary tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 937
717. DSECT structure of a typical tree element . . . . . . . . . . . . . . . . . . . . . . . . . 937
718. Three nodes of a binary tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 938
719. A growing binary tree with seven nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 938
720. Entering a new node in a binary tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . 939
721. Retrieving data from a binary tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 940
722. Example of a binary tree of 7 elements . . . . . . . . . . . . . . . . . . . . . . . . . . . 940
723. Example of searching a hash table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 942
724. Example of searching a hash table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 943
725. Sample macro invocation, Standard form . . . . . . . . . . . . . . . . . . . . . . . . . . 951
726. Generated statements from an OPEN macro . . . . . . . . . . . . . . . . . . . . . . . . 952
727. Sample macro invocation using List form . . . . . . . . . . . . . . . . . . . . . . . . . 952
728. Generated statements from a List form OPEN macro . . . . . . . . . . . . . . . . . . 953
729. Sample macro invocation using Execute form . . . . . . . . . . . . . . . . . . . . . . . 953
730. Generated statements from an Execute form OPEN macro . . . . . . . . . . . . . . . 953
731. Sample macro invocation using empty List form . . . . . . . . . . . . . . . . . . . . . 953
732. Generated instructions from empty List form . . . . . . . . . . . . . . . . . . . . . . . 953
733. Sample macro invocation using Execute form . . . . . . . . . . . . . . . . . . . . . . . 953
734. Generated statements from an Execute form OPEN macro . . . . . . . . . . . . . . . 953
735. Another macro invocation using Execute form and same List form . . . . . . . . . . . 954
736. An R-Type macro invocation generating an argument in a register . . . . . . . . . . . 954
737. Generated statements from R-Type macro . . . . . . . . . . . . . . . . . . . . . . . . . 954
738. A macro invocation with arguments in registers . . . . . . . . . . . . . . . . . . . . . . 954
739. Generated statements from a Standard-form macro with arguments in registers . . . . 954
740. A Standard macro invocation specifying MODE=31 . . . . . . . . . . . . . . . . . . . 955
741. Generated statements from a Standard-for macro with MODE=31 . . . . . . . . . . 955
742. Example of a mixed-case positional macro argument . . . . . . . . . . . . . . . . . . . 955
743. Example of mixed-case keyword macro arguments . . . . . . . . . . . . . . . . . . . . 955
744. Example of mixed-case keyword macro arguments . . . . . . . . . . . . . . . . . . . . 955
745. Sample ABEND macro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956
746. Generated statements from an ABEND macro . . . . . . . . . . . . . . . . . . . . . . 957
747. Sample R=type GETMAIN request . . . . . . . . . . . . . . . . . . . . . . . . . . . . 958
748. Expansion of a sample R-type GETMAIN request . . . . . . . . . . . . . . . . . . . . 959
749. Expansion of a sample VRU-type GETMAIN request . . . . . . . . . . . . . . . . . . 959
750. Example of an R-type FREEMAIN macro . . . . . . . . . . . . . . . . . . . . . . . . 960
751. Sample STORAGE OBTAIN request . . . . . . . . . . . . . . . . . . . . . . . . . . . 960
752. Example of a STORAGE OBTAIN macro expansion . . . . . . . . . . . . . . . . . . 961

xxviii Assembler Language Programming for IBM System z™ Servers Version 2.00
 753. Sample STORAGE RELEASE request . . . . . . . . . . . . . . . . . . . . . . . . . . 961
754. Example of a STORAGE RELEASE macro expansion . . . . . . . . . . . . . . . . . 961
755. A Data Set with records you want to read . . . . . . . . . . . . . . . . . . . . . . . . . 962
756. You submitted a job with a program to read the records . . . . . . . . . . . . . . . . . 963
757. Your program, loaded into memory before execution . . . . . . . . . . . . . . . . . . . 963
758. Your program after executing the OPEN macro . . . . . . . . . . . . . . . . . . . . . . 964
759. Your program after executing the GET macro . . . . . . . . . . . . . . . . . . . . . . . 965
760. Your program after executing the CLOSE macro . . . . . . . . . . . . . . . . . . . . . 965
761. Example of typical DCB parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 968
762. Unblocked and blocked F-type record and block formats . . . . . . . . . . . . . . . . 968
763. Unblocked and blocked V-type record and block formats . . . . . . . . . . . . . . . . 969
764. U-type block formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 969
765. Completion of a DCB during OPEN processing . . . . . . . . . . . . . . . . . . . . . 969
766. DCBD operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 970
767. DCBD operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 970
768. Using IHADCB to map two different DCBs simultaneously . . . . . . . . . . . . . . 970
769. A complete sample program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 972
770. Instruction cycle with interruptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 973
771. Establishing a program interruption exit . . . . . . . . . . . . . . . . . . . . . . . . . . 973
772. Expansion of an ESPIE macro establishing a program interruption exit . . . . . . . . 974
773. Terminating a program interruption exit . . . . . . . . . . . . . . . . . . . . . . . . . . 974
774. Expansion of an ESPIE macro terminating a program interruption exit . . . . . . . . 974
775. ESA/390-mode old PSW in EPIE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 975
776. Sketch of interruption handling control flow . . . . . . . . . . . . . . . . . . . . . . . . 977
777. A simple ESTAE macro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 979
778. Skeleton form of a reenterable program . . . . . . . . . . . . . . . . . . . . . . . . . . . 985
779. I/O macros in a reenterable program . . . . . . . . . . . . . . . . . . . . . . . . . . . . 986
780. Assembly listing for a simple reenterable program . . . . . . . . . . . . . . . . . . . . . 986
781. Example of a reenterable, recursive routine . . . . . . . . . . . . . . . . . . . . . . . . . 990
782. Assembly listing of the reenterable recursive routine . . . . . . . . . . . . . . . . . . . 991

Tables
1. Binary, decimal, and hexadecimal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2. Multiples of powers of sixteen (part 1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . 20
3. Multiples of powers of sixteen (part 2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . 21
4. Examples of two's complement representation . . . . . . . . . . . . . . . . . . . . . . . . 29
5. Examples of sign extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6. RR-type instruction format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
7. RX-type and RS-type instruction format . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
8. SI-type instruction format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
9. SS-type instruction format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
10. Instruction Length Code and instruction types . . . . . . . . . . . . . . . . . . . . . . . . 54
11. General instruction classifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
12. Punched-card image of a RETURN statement . . . . . . . . . . . . . . . . . . . . . . . 78
13. Assembler Language EBCDIC character representation . . . . . . . . . . . . . . . . . . 87
14. Differences between Assembler Language and high-level language symbols . . . . . . . 94
15. Expressions with absolute and relocatable terms . . . . . . . . . . . . . . . . . . . . . . . 99
16. Typical RR-type instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
17. RR-type instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
18. Typical RX-type instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
19. RX-type instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
20. Operands of RX-type instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
21. Typical RS- and SI-type instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
22. Typical RS-type instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
23. Operands of RS-type instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
24. Typical SI-type instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
25. Operands of SI-type instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Figures xxix
 26. Typical SS-type instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
27. Typical type SS-1 instruction with one length field . . . . . . . . . . . . . . . . . . . . 113
28. Operands of type SS-1 single-length instructions . . . . . . . . . . . . . . . . . . . . . . 113
29. Typical type SS-2 instruction with two length fields . . . . . . . . . . . . . . . . . . . . 114
30. Operands of type SS-2 two-length instructions . . . . . . . . . . . . . . . . . . . . . . . 114
31. Examples of truncated and padded constants . . . . . . . . . . . . . . . . . . . . . . . . 152
32. Truncation/padding rules for some DC operands . . . . . . . . . . . . . . . . . . . . . 153
33. Truncation and padding rules for some DC operands with extended types . . . . . . . 158
34. Load/Store instructions for 32-bit general registers . . . . . . . . . . . . . . . . . . . . 179
35. Format of an RX-type instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
36. Multiple load/store instructions for 32-bit general registers . . . . . . . . . . . . . . . . 180
37. RS-type instruction format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
38. Halfword load/store instructions for 32-bit general registers . . . . . . . . . . . . . . . 182
39. Character insert/store instructions for 32-bit general registers . . . . . . . . . . . . . . 184
40. Insert/Store characters under mask instructions for 32-bit general registers . . . . . . . 185
41. RS-type instruction format for ICM and STCM . . . . . . . . . . . . . . . . . . . . . 186
42. CC settings after ICM instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
43. Register/register instructions for 32-bit general registers . . . . . . . . . . . . . . . . . . 187
44. Action of five RR-type general register instructions . . . . . . . . . . . . . . . . . . . . 188
45. Condition Code settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
46. Register/storage instructions for 64-bit general registers . . . . . . . . . . . . . . . . . . 189
47. RXY-type instruction format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
48. RSY-type instruction format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
49. RRE-type instruction format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
50. Register/register instructions for 64-bit general registers . . . . . . . . . . . . . . . . . . 192
51. Action of five RR-type 64-bit general register instructions . . . . . . . . . . . . . . . . 192
52. Load and Test instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
53. Register/register instructions for 64-bit general registers . . . . . . . . . . . . . . . . . . 194
54. Action of 32-bit-to-64-bit general register instructions . . . . . . . . . . . . . . . . . . 194
55. Other general register load instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
56. Summary of instructions discussed in this section . . . . . . . . . . . . . . . . . . . . . 200
57. BCR instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
58. BC instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
59. Mask bits and corresponding CC values . . . . . . . . . . . . . . . . . . . . . . . . . . 205
60. CNOP operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
61. Extended branch mnemonics and their branch mask values . . . . . . . . . . . . . . . 210
62. Frequently used add and subtract instructions . . . . . . . . . . . . . . . . . . . . . . . 216
63. CC settings for arithmetic add and subtract instructions . . . . . . . . . . . . . . . . . 217
64. Arithmetic compare instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
65. CC settings after arithmetic comparisons . . . . . . . . . . . . . . . . . . . . . . . . . . 222
66. Logical arithmetic instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
67. CC settings for logical add and subtract instructions . . . . . . . . . . . . . . . . . . . 224
68. CC indications for logical addition and subtraction . . . . . . . . . . . . . . . . . . . . 225
69. CC settings after logical addition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
70. CC settings after logical subtraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
71. Logical arithmetic instructions with carry/borrow . . . . . . . . . . . . . . . . . . . . . 228
72. Instructions for mixed-length operands . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
73. Arithmetic compare instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
74. CC settings after logical comparisons . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
75. IPM and SPM instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
76. Program Mask bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
77. Summary of instructions discussed in this section . . . . . . . . . . . . . . . . . . . . . 236
78. General register shift instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
79. RS-type shift instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
80. RSY-type instruction format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
81. CC settings for arithmetic shift instructions . . . . . . . . . . . . . . . . . . . . . . . . 252
82. Summary of shift instructions discussed in this section . . . . . . . . . . . . . . . . . . 260
83. Binary integer multiply instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
84. Double-length arithmetic multiply instructions . . . . . . . . . . . . . . . . . . . . . . 265
85. Single-length arithmetic multiply instructions . . . . . . . . . . . . . . . . . . . . . . . 268
86. Logical multiply instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
87. Binary divide instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274

xxx Assembler Language Programming for IBM System z™ Servers Version 2.00
88. Arithmetic divide instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
89. Binary divide instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
90. Summary of multiply instructions discussed in this section . . . . . . . . . . . . . . . . 283
91. Summary of divide instructions discussed in this section . . . . . . . . . . . . . . . . . 283
92. Logical operations involving general registers . . . . . . . . . . . . . . . . . . . . . . . 288
93. CC settings by logical instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
94. Summary of the logical operations AND, OR, XOR . . . . . . . . . . . . . . . . . . . 297
95. Logical-operation instructions discussed in this section . . . . . . . . . . . . . . . . . . 297
96. Format of RXY- and RSY-type instructions . . . . . . . . . . . . . . . . . . . . . . . . 302
97. Format of R-I instructions with 16-bit immediate operands . . . . . . . . . . . . . . . 305
98. Format of R-I instructions with 32-bit immediate operands . . . . . . . . . . . . . . . 305
99. PSW addressing-mode bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
100. Load Address instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
101. Load Address instructions described in this section . . . . . . . . . . . . . . . . . . . . 314
102. RI-type instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
103. RIL-type instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
104. Insert-Immediate instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
105. Load and insert instructions with immediate operands . . . . . . . . . . . . . . . . . . 319
106. Arithmetic-immediate add and subtract instructions . . . . . . . . . . . . . . . . . . . . 321
107. Arithmetic-immediate compare instructions . . . . . . . . . . . . . . . . . . . . . . . . 322
108. Arithmetic-immediate multiply instructions . . . . . . . . . . . . . . . . . . . . . . . . 322
109. AND-immediate instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
110. OR-immediate instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
111. XOR-immediate instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
112. Load and insert instructions with immediate operands . . . . . . . . . . . . . . . . . . 326
113. Arithmetic instructions with immediate operands . . . . . . . . . . . . . . . . . . . . . 326
114. Logical instructions with immediate operands . . . . . . . . . . . . . . . . . . . . . . . 326
115. Format of the BRC instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
116. Format of the BRCL instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
117. Extended branch relative on condition mnemonics and their branch mask values . . . 330
118. Branch on count instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
119. Extended mnemonics for branch relative on count instructions . . . . . . . . . . . . . 334
120. Branch on index instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
121. RS-type BXH and BXLE instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
122. RSY-type BXHG and BXLEG instructions . . . . . . . . . . . . . . . . . . . . . . . . 341
123. RSI-type BRXH and BRXLE instructions . . . . . . . . . . . . . . . . . . . . . . . . . 341
124. RIE-type BRXHG and BRXLG instructions . . . . . . . . . . . . . . . . . . . . . . . 341
125. Extended mnemonics for branch relative on index instructions . . . . . . . . . . . . . 343
126. Branch relative on condition instructions . . . . . . . . . . . . . . . . . . . . . . . . . . 349
127. Branch instructions for loop control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
128. SI-type instruction format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
129. SIY-type instruction format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
130. SI-type instruction actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
131. Move Immediate instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
132. Logical Storage-Immediate instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
133. CC settings by SI-type logical instructions . . . . . . . . . . . . . . . . . . . . . . . . . 354
134. Compare Immediate instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
135. CC settings after CLI instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
136. Storage-Immediate instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
137. CC settings after TM instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
138. Storage-Immediate instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
139. Basic character-handling instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
140. Format of single-length SS-type instructions . . . . . . . . . . . . . . . . . . . . . . . . 365
141. Instruction types and operand formats . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
142. SS-type instructions with explicit length . . . . . . . . . . . . . . . . . . . . . . . . . . 367
143. SS-type instructions with implied length . . . . . . . . . . . . . . . . . . . . . . . . . . 368
144. Determining the Length Specification Byte . . . . . . . . . . . . . . . . . . . . . . . . . 370
145. MVCOS instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
146. SSF instruction format used for the MVCOS instruction . . . . . . . . . . . . . . . . . 374
147. Condition Code settings for TRT and TRTR instructions . . . . . . . . . . . . . . . . 384
148. Execute instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
149. Modifiable portions of typical EX target instructions . . . . . . . . . . . . . . . . . . . 394

Tables xxxi
 150. Operands of single-length SS-type instructions . . . . . . . . . . . . . . . . . . . . . . . 396
151. Basic instructions for data in storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
152. Basic character-handling instructions using padding characters . . . . . . . . . . . . . . 404
153. CC settings after MVCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
154. CC settings after CLCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
155. Format of MVCLE and CLCLE instructions . . . . . . . . . . . . . . . . . . . . . . . 410
156. CC settings after MVCLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
157. CC settings after CLCLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
158. Character-handling instructions for terminated strings . . . . . . . . . . . . . . . . . . 415
159. Format of RRE-type instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
160. CC settings for SRST instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
161. CC settings for MVST instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
162. CC settings for CLST instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
163. CC settings for TRE instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
164. Compare Until Substring Equal instruction . . . . . . . . . . . . . . . . . . . . . . . . 423
165. Condition Code settings by CUSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
166. Results of examples using the CUSE instruction . . . . . . . . . . . . . . . . . . . . . 424
167. Extended instructions for character data . . . . . . . . . . . . . . . . . . . . . . . . . . 425
168. Punched paper tape encodings with values 00-0F . . . . . . . . . . . . . . . . . . . . . 429
169. Punched paper tape encodings with values 10-1F . . . . . . . . . . . . . . . . . . . . . 429
170. Old six-bit BCD character representation . . . . . . . . . . . . . . . . . . . . . . . . . . 430
171. Sample EBCDIC characters with varying code points among code pages . . . . . . . 431
172. 7-bit ASCII character representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
173. Japanese DBCS assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
174. DBCS encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
175. Sample Unicode assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
176. Unicode string instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
177. CC settings for SRSTU instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
178. CC settings after MVCLU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
179. CC settings after CLCLU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
180. RRE-type instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
181. RRF-format instruction with an optional operand . . . . . . . . . . . . . . . . . . . . 444
182. Unicode translate instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
183. Arguments and translate tables for TRxx instructions . . . . . . . . . . . . . . . . . . . 445
184. Registers used by TRxx instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
185. Condition Code settings for TRxx instructions . . . . . . . . . . . . . . . . . . . . . . 445
186. Unicode format conversion instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
187. CC settings after Unicode format conversion instructions . . . . . . . . . . . . . . . . 448
188. Translate and Test Extended instructions . . . . . . . . . . . . . . . . . . . . . . . . . . 450
189. Function-code table sizes for TRTE, TRTRE . . . . . . . . . . . . . . . . . . . . . . . 450
190. Condition code settings for TRTE, TRTRE . . . . . . . . . . . . . . . . . . . . . . . . 451
191. Byte-reversing load and store instructions . . . . . . . . . . . . . . . . . . . . . . . . . 453
192. Extended instructions for Unicode data . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
193. Unicode-based translate instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
194. Unicode format conversion instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
195. Summary of byte-reversing instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
196. Basic packed and zoned decimal instructions . . . . . . . . . . . . . . . . . . . . . . . . 460
197. Examples of zoned decimal data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
198. Punched-card image of two numbers, + 12345 and − 67890 . . . . . . . . . . . . . . . 463
199. Examples of packed decimal data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
200. Format of two-length SS-type instructions . . . . . . . . . . . . . . . . . . . . . . . . . 469
201. Operands of two-length SS-type instructions . . . . . . . . . . . . . . . . . . . . . . . . 470
202. Format of PKA and PKU instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
203. Format of UNPKA and UNPKU instructions . . . . . . . . . . . . . . . . . . . . . . 479
204. CC settings after UNPKA, UNPKU instructions . . . . . . . . . . . . . . . . . . . . . 480
205. Instructions for moving numeric and zone digits . . . . . . . . . . . . . . . . . . . . . . 483
206. Instructions for packing and unpacking data . . . . . . . . . . . . . . . . . . . . . . . . 483
207. CC settings for decimal addition and subtraction . . . . . . . . . . . . . . . . . . . . . 486
208. CC setting after decimal comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
209. Packed decimal arithmetic instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
210. Operand formats for TP instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498
211. Format of the TP instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498

xxxii Assembler Language Programming for IBM System z™ Servers Version 2.00
212. CC settings for the TP instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498
213. CC settings by the ZAP, AP, and SP instructions . . . . . . . . . . . . . . . . . . . . . 499
214. CC setting by the CP instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504
215. Format of the SRP instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
216. Summary of decimal instruction behavior . . . . . . . . . . . . . . . . . . . . . . . . . 530
217. Instructions used for converting and formatting packed decimal . . . . . . . . . . . . . 532
218. Format of the ED and EDMK instructions . . . . . . . . . . . . . . . . . . . . . . . . 536
219. CC settings after ED, EDMK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544
220. ED and EDMK treatment of pattern characters . . . . . . . . . . . . . . . . . . . . . . 547
221. Basic floating-point instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568
222. Instructions copying data between FPRs . . . . . . . . . . . . . . . . . . . . . . . . . . 568
223. Floating-point Load Zero instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . 569
224. Instructions moving data between FPRs and GPRs . . . . . . . . . . . . . . . . . . . 570
225. Copy Sign instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 570
226. Basic Load/Store instructions for floating-point operands . . . . . . . . . . . . . . . . 571
227. Instructions moving operands between GPRs and FPRs . . . . . . . . . . . . . . . . . 571
228. Hexadecimal floating-point data representations . . . . . . . . . . . . . . . . . . . . . . 587
229. Unnormalized and normalized short hexadecimal floating-point numbers . . . . . . . 588
230. Short hexadecimal floating-point numbers . . . . . . . . . . . . . . . . . . . . . . . . . 588
231. Long hexadecimal floating-point numbers . . . . . . . . . . . . . . . . . . . . . . . . . 589
232. Extended hexadecimal floating-point numbers . . . . . . . . . . . . . . . . . . . . . . . 589
233. Assembled hexadecimal floating-point constants . . . . . . . . . . . . . . . . . . . . . . 591
234. Hex floating-point constants with decimal exponents . . . . . . . . . . . . . . . . . . . 591
235. Length-modified hexadecimal floating-point constants . . . . . . . . . . . . . . . . . . 592
236. Hexadecimal floating-point constants with modifiers . . . . . . . . . . . . . . . . . . . 594
237. Hexadecimal floating-point rounding modes with subtype H . . . . . . . . . . . . . . 595
238. Symbolic hexadecimal floating-point constants . . . . . . . . . . . . . . . . . . . . . . 596
239. “Difficult” hexadecimal floating-point conversion values . . . . . . . . . . . . . . . . . 596
240. Data-moving hexadecimal floating-point instructions . . . . . . . . . . . . . . . . . . . 597
241. Hexadecimal floating-point Multiply instructions . . . . . . . . . . . . . . . . . . . . . 599
242. Summary of hexadecimal floating-point multiplication results . . . . . . . . . . . . . . 601
243. Hexadecimal floating-point Divide instructions . . . . . . . . . . . . . . . . . . . . . . 603
244. Hexadecimal floating-point Halve instructions . . . . . . . . . . . . . . . . . . . . . . . 604
245. Hexadecimal floating-point Add/Subtract instructions . . . . . . . . . . . . . . . . . . 606
246. Hexadecimal floating-point Compare instructions . . . . . . . . . . . . . . . . . . . . . 615
247. CC settings for hexadecimal floating-point comparison . . . . . . . . . . . . . . . . . . 616
248. Hexadecimal floating-point Round instructions . . . . . . . . . . . . . . . . . . . . . . 616
249. Hexadecimal floating-point Load Lengthened instructions . . . . . . . . . . . . . . . . 619
250. Hexadecimal floating-point FPR/GPR conversion instructions . . . . . . . . . . . . . 620
251. Format of HFP to fixed binary instructions . . . . . . . . . . . . . . . . . . . . . . . . 621
252. Rounding modifiers for HFP-to-binary conversion . . . . . . . . . . . . . . . . . . . . 621
253. CC settings for HFP-to-binary conversion . . . . . . . . . . . . . . . . . . . . . . . . . 622
254. Instructions moving/converting binary and hexadecimal floating-point operands . . . 622
255. Hexadecimal floating-point instructions generating floating-point integers . . . . . . . 625
256. Hexadecimal floating-point Square Root instructions . . . . . . . . . . . . . . . . . . . 627
257. Hexadecimal floating-point Multiply and add/subtract instructions . . . . . . . . . . . 627
258. Format of RRF-type HFP multiply and add/subtract instructions . . . . . . . . . . . 628
259. Format of RXF-type multiply and add/subtract instructions . . . . . . . . . . . . . . 628
260. Hexadecimal floating-point Move/Test instructions . . . . . . . . . . . . . . . . . . . . 631
261. Hexadecimal floating-point Multiply instructions . . . . . . . . . . . . . . . . . . . . . 631
262. Hexadecimal floating-point Divide instructions . . . . . . . . . . . . . . . . . . . . . . 631
263. Hexadecimal floating-point Add, Subtract, and Compare instructions . . . . . . . . . 631
264. Hexadecimal floating-point Round instructions . . . . . . . . . . . . . . . . . . . . . . 632
265. Hexadecimal floating-point Lengthening instructions . . . . . . . . . . . . . . . . . . . 632
266. Convert hexadecimal floating-point to binary instructions . . . . . . . . . . . . . . . . 632
267. Convert binary to hexadecimal floating-point instructions . . . . . . . . . . . . . . . . 632
268. Form hexadecimal floating-point integer instructions . . . . . . . . . . . . . . . . . . . 632
269. Hexadecimal floating-point Square Root instructions . . . . . . . . . . . . . . . . . . . 632
270. Hexadecimal floating-point Multiply-Add/Subtract instructions . . . . . . . . . . . . . 633
271. Binary floating-point data representations . . . . . . . . . . . . . . . . . . . . . . . . . 638
272. Examples of short-precision binary floating-point normal values . . . . . . . . . . . . 640
273. Examples of short-precision binary floating-point denormalized values . . . . . . . . . 640

Tables xxxiii
 274. Examples of short-precision binary floating-point special values . . . . . . . . . . . . . 641
275. Nominal-value operands for binary floating-point special values . . . . . . . . . . . . 644
276. Assembled binary floating-point special-value constants . . . . . . . . . . . . . . . . . 644
277. Minimum bit lengths for binary floating-point constants . . . . . . . . . . . . . . . . . 645
278. Binary floating-point DXC values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 650
279. Binary floating-point FPC register control instructions . . . . . . . . . . . . . . . . . . 651
280. Invalid operation binary floating-point exception . . . . . . . . . . . . . . . . . . . . . 652
281. Divide by zero binary floating-point exception . . . . . . . . . . . . . . . . . . . . . . . 652
282. Exponent overflow binary floating-point exception . . . . . . . . . . . . . . . . . . . . 652
283. Exponent underflow binary floating-point exception . . . . . . . . . . . . . . . . . . . 652
284. Inexact result binary floating-point exception . . . . . . . . . . . . . . . . . . . . . . . 652
285. BFP overflow/underflow scale factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653
286. Binary floating-point Test Data Class instructions . . . . . . . . . . . . . . . . . . . . . 654
287. Test Data Class second-operand bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654
288. Test Data Class second-operand test-bit/tested-value correspondence . . . . . . . . . . 654
289. Binary floating-point RR-type data movement instructions . . . . . . . . . . . . . . . 655
290. CC settings for BFP data movement instructions . . . . . . . . . . . . . . . . . . . . . 656
291. Binary floating-point Multiply instructions . . . . . . . . . . . . . . . . . . . . . . . . . 657
292. Binary floating-point Divide instructions . . . . . . . . . . . . . . . . . . . . . . . . . . 659
293. Binary floating-point Add and Subtract instructions . . . . . . . . . . . . . . . . . . . 661
294. CC settings after BFP add/subtract instructions . . . . . . . . . . . . . . . . . . . . . . 661
295. Binary floating-point Compare instructions . . . . . . . . . . . . . . . . . . . . . . . . 662
296. CC settings for BFP comparisons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 662
297. Binary floating-point Compare and Signal instructions . . . . . . . . . . . . . . . . . . 663
298. Binary floating-point Round instructions . . . . . . . . . . . . . . . . . . . . . . . . . . 664
299. Binary floating-point Lengthening instructions . . . . . . . . . . . . . . . . . . . . . . . 665
300. Binary integer to binary floating-point conversion instructions . . . . . . . . . . . . . 666
301. Binary floating-point to integer conversion instructions . . . . . . . . . . . . . . . . . . 666
302. Format of BFP Convert To Fixed instructions . . . . . . . . . . . . . . . . . . . . . . 666
303. Rounding modifier for BFP convert to fixed instructions . . . . . . . . . . . . . . . . 667
304. CC settings after convert to binary instructions . . . . . . . . . . . . . . . . . . . . . . 667
305. Load floating-point integer instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . 668
306. Rounding mode modifiers for BFP load integer instructions . . . . . . . . . . . . . . . 669
307. Binary floating-point Divide to Integer instructions . . . . . . . . . . . . . . . . . . . . 669
308. Format of BFP Divide to Integer instructions . . . . . . . . . . . . . . . . . . . . . . . 669
309. CC settings after divide to integer instructions . . . . . . . . . . . . . . . . . . . . . . . 670
310. Binary floating-point Square Root instructions . . . . . . . . . . . . . . . . . . . . . . 671
311. Binary floating-point Multiply and Add/Subtract instructions . . . . . . . . . . . . . . 672
312. Summary of binary floating-point instructions with uniform operand lengths . . . . . 673
313. Binary floating-point Multiply instructions . . . . . . . . . . . . . . . . . . . . . . . . . 674
314. Binary floating-point Round instructions . . . . . . . . . . . . . . . . . . . . . . . . . . 674
315. Binary floating-point Lengthening instructions . . . . . . . . . . . . . . . . . . . . . . . 674
316. Convert binary floating-point to binary integer instructions . . . . . . . . . . . . . . . 675
317. Convert binary integer to binary floating-point instructions . . . . . . . . . . . . . . . 675
318. Summary of binary floating-point operations and exceptions . . . . . . . . . . . . . . 675
319. Decimal floating-point data representations . . . . . . . . . . . . . . . . . . . . . . . . 684
320. Declet encoding for BCD digits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685
321. Converting decimal floating-point declets to BCD digits . . . . . . . . . . . . . . . . . 686
322. First five bits of special-values Combination Field . . . . . . . . . . . . . . . . . . . . 687
323. First 5 bits of finite-value Combination Field . . . . . . . . . . . . . . . . . . . . . . . 688
324. Properties of decimal floating-point representations . . . . . . . . . . . . . . . . . . . . 689
325. Assembled decimal floating-point special-value constants . . . . . . . . . . . . . . . . 690
326. Examples of decimal floating-point short precision zeros . . . . . . . . . . . . . . . . . 691
327. Assembler rounding-mode suffixes for DFP constants . . . . . . . . . . . . . . . . . . 691
328. Decimal floating-point Test Data Class instructions . . . . . . . . . . . . . . . . . . . . 693
329. DFP Test Data Class second-operand bits . . . . . . . . . . . . . . . . . . . . . . . . . 694
330. Test Data Class test-bit vs. tested-class correspondence . . . . . . . . . . . . . . . . . . 694
331. Example of DFP rounding modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696
332. Preferred quanta for some decimal floating-point operations . . . . . . . . . . . . . . . 698
333. Decimal floating-point additional DXC value . . . . . . . . . . . . . . . . . . . . . . . 699
334. Decimal floating-point quantum exception . . . . . . . . . . . . . . . . . . . . . . . . . 699
335. Decimal floating-point scale factors for exponent spills . . . . . . . . . . . . . . . . . . 699

xxxiv Assembler Language Programming for IBM System z™ Servers Version 2.00
336. Copy Sign instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700
337. Instructions moving data between FPRs and GPRs . . . . . . . . . . . . . . . . . . . 700
338. Instructions copying data between FPRs . . . . . . . . . . . . . . . . . . . . . . . . . . 700
339. Decimal floating-point basic arithmetic instructions . . . . . . . . . . . . . . . . . . . . 701
340. Format of DFP arithmetic instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . 701
341. Format of DFP arithmetic instructions with rounding mask . . . . . . . . . . . . . . . 701
342. Instruction-specific rounding mask values . . . . . . . . . . . . . . . . . . . . . . . . . 702
343. CC settings for Add/Subtract instructions . . . . . . . . . . . . . . . . . . . . . . . . . 704
344. CC settings for Compare instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705
345. Decimal floating-point Compare instructions . . . . . . . . . . . . . . . . . . . . . . . 705
346. Decimal floating-point Compare and Signal instructions . . . . . . . . . . . . . . . . . 705
347. Decimal floating-point Compare Biased Exponent instructions . . . . . . . . . . . . . 706
348. CC settings for Compare Biased Exponent instructions . . . . . . . . . . . . . . . . . 706
349. Decimal floating-point convert to/from fixed binary instructions . . . . . . . . . . . . 707
350. Format of Convert to Fixed Binary instructions . . . . . . . . . . . . . . . . . . . . . . 708
351. Format of Convert to Fixed Binary instructions . . . . . . . . . . . . . . . . . . . . . . 708
352. CC settings for Convert to Fixed instructions . . . . . . . . . . . . . . . . . . . . . . . 708
353. Decimal floating-point convert to/from signed packed decimal instructions . . . . . . 709
354. Format of Convert to Signed Packed instructions . . . . . . . . . . . . . . . . . . . . . 709
355. Decimal floating-point convert to/from unsigned packed decimal instructions . . . . . 711
356. Instructions converting between decimal floating-point and zoned decimal . . . . . . 712
357. Format of DFP/zoned decimal conversion instructions . . . . . . . . . . . . . . . . . . 712
358. Condition Code settings for Convert to Zoned . . . . . . . . . . . . . . . . . . . . . . 713
359. Decimal floating-point Load and Test instructions . . . . . . . . . . . . . . . . . . . . 715
360. CC setting after DFP Load and Test instructions . . . . . . . . . . . . . . . . . . . . . 715
361. Instructions copying/complementing data between FPRs . . . . . . . . . . . . . . . . 715
362. Decimal floating-point Load Floating-point Integer instructions . . . . . . . . . . . . 715
363. Format of Load FP Integer instructions . . . . . . . . . . . . . . . . . . . . . . . . . . 715
364. Decimal floating-point Load Lengthened instructions . . . . . . . . . . . . . . . . . . . 716
365. Load Lengthened special operand control mask . . . . . . . . . . . . . . . . . . . . . . 716
366. Decimal floating-point rounding/lengthening instructions . . . . . . . . . . . . . . . . 717
367. Decimal floating-point Set Rounding Mode instruction . . . . . . . . . . . . . . . . . 718
368. Decimal floating-point Insert/Extract Biased Exponent instructions . . . . . . . . . . 719
369. Extracted Biased Exponent for DFP special values . . . . . . . . . . . . . . . . . . . . 719
370. DFP Insert Biased Exponent results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 720
371. Decimal floating-point Extract Significance instructions . . . . . . . . . . . . . . . . . 720
372. Decimal floating-point Shift Significand instructions . . . . . . . . . . . . . . . . . . . 721
373. Format of DFP shift instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 721
374. Decimal floating-point Quantize instructions . . . . . . . . . . . . . . . . . . . . . . . . 722
375. Format of decimal floating-point Quantize instructions . . . . . . . . . . . . . . . . . . 722
376. Decimal floating-point Reround instructions . . . . . . . . . . . . . . . . . . . . . . . . 724
377. Decimal floating-point Test Data Group instructions . . . . . . . . . . . . . . . . . . . 726
378. Test Data Group second-operand bits . . . . . . . . . . . . . . . . . . . . . . . . . . . 726
379. DFP Test Data Class and Test Data Group instructions . . . . . . . . . . . . . . . . . 732
380. DFP Arithmetic and related instructions . . . . . . . . . . . . . . . . . . . . . . . . . . 732
381. DFP length and type conversion instructions . . . . . . . . . . . . . . . . . . . . . . . 732
382. DFP rounding and lengthening instructions . . . . . . . . . . . . . . . . . . . . . . . . 732
383. DFP data-loading instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733
384. Instructions copying between FPRs and GPRs . . . . . . . . . . . . . . . . . . . . . . 733
385. Instruction setting decimal rounding mode . . . . . . . . . . . . . . . . . . . . . . . . . 733
386. Non-canonical declets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733
387. Summary of System z floating-point representations . . . . . . . . . . . . . . . . . . . 739
388. Adding 0.1 in hexadecimal, binary, and decimal floating-point . . . . . . . . . . . . . . 741
389. Exception behavior for hexadecimal floating-point . . . . . . . . . . . . . . . . . . . . 741
390. Exception behavior for binary and decimal floating-point . . . . . . . . . . . . . . . . 741
391. Length modifiers of floating-point constants . . . . . . . . . . . . . . . . . . . . . . . . 742
392. Assembler rounding-mode suffixes for floating-point constants . . . . . . . . . . . . . 742
393. Internal precision required for faithful In-Out conversion . . . . . . . . . . . . . . . . 744
394. Decimal precision required for faithful Out-In conversion . . . . . . . . . . . . . . . . 744
395. Perform Floating-Point Operation instruction . . . . . . . . . . . . . . . . . . . . . . . 745
396. Laws of real and realistic arithmetic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746
397. Examples of hexadecimal floating-point pseudo-zeros . . . . . . . . . . . . . . . . . . . 748

Tables xxxv
 398. Examples of other floating-point representations . . . . . . . . . . . . . . . . . . . . . 750
399. Equivalent decimal and floating-point precisions . . . . . . . . . . . . . . . . . . . . . 751
400. Branch and Save instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758
401. Standard (Format-0) Save Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 770
402. Standard Format-4 save area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773
403. Standard Format-5 save area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775
404. AMODE values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 827
405. R M O D E values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 828
406. Default AMODE and RMODE values . . . . . . . . . . . . . . . . . . . . . . . . . . . 828
407. Valid combinations of AMODE and RMODE values . . . . . . . . . . . . . . . . . . 828
408. Differences in linking COMMONs and External dummy items . . . . . . . . . . . . . 841
409. ESD symbol search types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 841
410. Matching existing CESD SD symbol to incoming symbols . . . . . . . . . . . . . . . 843
411. Matching existing CESD LD symbol to incoming symbols . . . . . . . . . . . . . . . 843
412. Matching existing CESD CM symbol to incoming symbols . . . . . . . . . . . . . . . 843
413. Matching existing CESD ER symbol to incoming symbols . . . . . . . . . . . . . . . 844
414. Matching existing CESD ER symbol to incoming symbols . . . . . . . . . . . . . . . 844
415. Comparing load modules and program objects . . . . . . . . . . . . . . . . . . . . . . 855
416. Instructions to change addressing mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 858
417. CC settings for TAM instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 858
418. PSW addressing-mode bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 858
419. BASSM actions summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 860
420. Operation of BSM instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 860
421. BSM actions summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 861
422. Instruction pairs for call/return with possible AMODE change . . . . . . . . . . . . . 862
423. Calling among addressing modes within an assembly . . . . . . . . . . . . . . . . . . . 863
424. LLGT and LLGTR instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 863
425. Symbol table entries for DSECT symbols . . . . . . . . . . . . . . . . . . . . . . . . . 873
426. Summary of USING Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905
427. Summary of DROP Statement Behaviors . . . . . . . . . . . . . . . . . . . . . . . . . 905
428. Example of a non-homogeneous array . . . . . . . . . . . . . . . . . . . . . . . . . . . 914
429. Array addressing with a table of addresses . . . . . . . . . . . . . . . . . . . . . . . . . 917
430. Example of an address table's contents . . . . . . . . . . . . . . . . . . . . . . . . . . . 918
431. Supervisor and Program Call instructions . . . . . . . . . . . . . . . . . . . . . . . . . 950
432. SVC instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 950
433. PC instruction format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 951
433. Program Call instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 951
434. GETMAIN request options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 958
435. FREEMAIN request options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 960
436. Comparing QSAM and BSAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 966
437. Partial contents of Extended Program Interruption Element (EPIE) . . . . . . . . . . 975
438. Hexadecimal, decimal, and binary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 995
439. Hexadecimal Addition Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 996
440. Hexadecimal Multiplication Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 996
441. Integer powers of 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 997
442. Integer powers of 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 998
443. Multiples of powers of sixteen (part 1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . 1000
444. Multiples of powers of sixteen (part 2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . 1000
445. Powers of 10 expressed in hexadecimal . . . . . . . . . . . . . . . . . . . . . . . . . . . 1001
446. Assembler Language EBCDIC character representation . . . . . . . . . . . . . . . . . 1012
447. 7-bit ASCII character representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1013
448. High Level Assembler DC-Statement Constant Types . . . . . . . . . . . . . . . . . . 1014
449. ASCII Character Representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1077
450. Examples of different types of integer division . . . . . . . . . . . . . . . . . . . . . . . 1129
451. Comparing five binary floating-point operands . . . . . . . . . . . . . . . . . . . . . . 1225

xxxvi Assembler Language Programming for IBM System z™ Servers Version 2.00
Tables xxxvii
xxxviii Assembler Language Programming for IBM System z™ Servers Version 2.00
Foreword

FFFFFFFFFFFF WW WW
FFFFFFFFFFFF WW WW
FF WW WW
FF WW WW
FF WW WW
FFFFFFFF WW WW
FFFFFFFF WW WW WW
FF WW WWWW WW
FF WW WW WW WW
FF WWWW WWWW
FF WWW WWW
FF WW WW

Outline and Overview

We will survey many aspects of Assembler Language programming on System z processors.

Chapters I-IV cover basic material needed for almost all programs.
• Chapter I introduces some notation we'll use, and discusses the important topics of binary and
hexadecimal number representations and arithmetic, and conversion among number represen-
tations.
• Chapter II introduces the “Central Processing Unit” or CPU. We'll survey central memory,
the registers you'll use in your programs, and the Program Status Word (PSW). Then we'll
look at some basic types of instructions and their operation codes, and see how they refer to
data in memory.
• Chapter III describes basic properties of the Assembler Language, including symbols, self-
defining terms, and expression evaluation. Then we will see how to write Assembler Language
statements and their components. Last, we discuss the key concept of addressability and the
important USING statement.
• Chapter IV describes methods for defining often-used data types, and techniques for organizing
data items in your programs.
• The six sections of Chapter V discuss basic instructions, emphasizing those that operate on
data in the general registers, and the important “conditional branch” instructions.
• Chapter VI considers addressing techniques, loops and other iterative processes, and
“immediate” instructions containing useful operands.
• Chapter VII discusses bit and character data and techniques for handling them.
• Chapter VIII examines the packed and zoned decimal data representations, instructions for
packed decimal arithmetic, and for conversion between those representations and EBCDIC
characters.
• Chapter IX describes general concepts of floating-point arithmetic and the three floating-point
representations supported by System z: hexadecimal, binary, and decimal, and instructions for
manipulating data in and among each of the representations. It concludes with a summary of
important differences between floating-point and mathematicians' “real” arithmetics.
• Chapter X discusses large programs and modularization techniques such as subroutines and
common linkage conventions, how to combine separately assembled (or compiled) routines
into a single executable program, and how to change addressing modes.
• Chapter XI describes the powerful “Dummy Control Section” and the enhanced USING
statements, and shows how to apply them to several basic data structures.

Foreword 1
 • Chapter XII introduces common techniques for accessing operating system services, basics of
exception handling, and uses of reenterability and recursion.
• Appendix A contains reference and conversion tables.
• Appendix B describes a set of useful macro instructions that handle simple input, output, con-
version, and display operations.

Programming Environments
Every programming language must eventually deal with the environments under which the pro-
grams will be run. While we will see many examples of program segments, we will defer complete
programs until later sections.

I assume your programs will execute on one of z/OS™, z/VM™, or z/VSE™. I have purposely
omitted discussion of z/Linux™, because Assembler Language is little used in that environment.

If you like, browse the solutions to the Programming Problems: these are complete programs
that have been executed successfully, and produce what I believe are correct answers. The simple
conventions used here for communicating with the Operating System's Supervisor are described in
“Appendix B: Simple I/O Macros” on page 1015; these may be augmented or replaced as desired.

The conventions and procedures needed to execute an Assembler Language program in your
computing environment should be locally available to you.

Levels of Difficulty (*)

This material varies in depth and detail. Where a detailed portion can be skipped with no loss of
continuity, the heading is tagged with a parenthesized asterisk (*), as in the heading just above.

Exercises and Programming Problems

Exercises and programming problems appear throughout. Some are integral to the material, while
others explore interesting sidelines. Exercises and programming problems are rated in order of
estimated difficulty from 1 to 5; the most useful or illustrative exercises are tagged with a plus ( + ),
and are strongly recommended.

In all cases, the exercises and programming problems are important.

Some Personal Observations

1. Some exercises ask you to find what is wrong with a statement or instruction sequence.
While it may be poor style (or manners) to show coding errors, I feel justified in doing so on
two grounds: pedagogical value and self-defense.
• First, it helps to see wrong or poor ways to do something, as well as correct or better
ways.
• Second, some programs may be written by people who learned from examples containing
errors — and their programs will be processing my bills, checking my tax returns, and cal-
culating my bank balance. I want your programs — and theirs — to be as safe, correct,
and reliable as possible.
I trust you will understand. I am of course willing to have you point out my errors. If you
find any, please let me know so I can correct them.
2. This is not intended to be a cookbook. I have tried to give not just occasional recipes for
doing some basic tasks, but a view of some underlying processor structures and the language
closest to the processor, Assembler Language. You may have already been introduced to
programming a computer using a “higher-level” language, and are probably familiar with
concepts such as loops and conditional branching. Because the internal structures of com-
puters have many similarities, I sometimes try to point out not only what a particular

2 Assembler Language Programming for IBM System z™ Servers Version 2.00

 instruction does, but also why it does it that way. Learning to program other processors will
then be a comfortable extension of the concepts and techniques you learned here.
3. This book is too large1 to be used as a text for a programming class of normal length. I
expect that most instructors will use those portions most useful for their selection of topics;
other portions may have information that can be sampled as desired.
I assume you are interested mainly in writing “application-level” programs for z/Architecture
processors, not specialized or privileged operating system components. This text therefore
deals with nonprivileged instructions, which in any event are the great majority of
instructions in all programs.
4. I confess that levels of detail may vary depending on my level of interest in a particular topic.
5. The Exercise and Programming Problem solutions should be considered as samples, and are
not in any way intended to be the “correct” solutions.2 If yours are shorter, simpler, or just
plain nicer, so much the better. But if your solutions seem to be two or three times longer
than these, you may want to study them for suggestions of workable approaches to solving a
programming problem.
6. Some of this material is based on lecture notes I created for Assembler Language classes
when I was at the Stanford Linear Accelerator Center in Menlo Park, California.

1 Yes, this book is too long. As my Chinese-restaurant fortune cookie said: “You have a love for words, and should
write a book.”
2 I urge you not to look at them before you're tried your own solutions (or if you're completely stuck at some point).
It's OK to learn from someone else's programs, but best it you do it only after you're tried your own.

Foreword 3
IIIIIIIIII NN NN
IIIIIIIIII NNN NN
II NNNN NN
II NN NN NN
II NN NN NN
II NN NN NN
II NN NN NN
II NN NN NN
II NN NNNN
II NN NNN
IIIIIIIIII NN NN
IIIIIIIIII NN NN

A digital computer can be considered from various viewpoints; here are five possible views, each
treating the computer's inner workings in successively less detail.
• To an engineer concerned with designing its logical circuits, a computer might be thought of as
a collection of devices for controlling and ordering the flow of electrical signals.
• At another level, a person concerned with methods used to make these logical circuits perform
operations such as addition and division might treat a computer as a collection of registers,
switches, and control mechanisms that perform a series of steps leading (say) to the computa-
tion of a quotient.
• At the next level one might consider a computer's basic operations to be single arithmetic
operations, a simple data movement, or a test of a single piece of data.
• Another viewpoint (typical of “higher-level languages”) considers the basic operations to be
moving blocks of data, evaluating and assigning mathematical expressions, and controlling
counting and testing operations.
• At yet another level, as in certain applications such as traffic simulation, data reduction, and
network analysis, the computer processes information in a form closely approximating the
problem under consideration, and produces output directly applicable to that problem.

Each of these views is of course not especially distinct from its neighbors. We will be primarily
concerned with the middle level, considering the basic operations or instructions that we want the
computer to perform, such as single arithmetic or logical operations, simple data transmission
operations, etc. We will also consider the computer from “neighboring” viewpoints: sometimes it
is useful to know some details of the internal sequencing of operations such as multiplication and
branching; at other times it will be convenient to consider groups of instructions such as macro
instructions that perform operations in a larger context.

The level that is our primary concern is usually known as “Assembler Language programming” or
“assembler coding”.3 The assembler we'll describe is the IBM High Level Assembler for z/OS &
z/VM & z/VSE, known as “HLASM”. It also can be used on IBM Linux for System z.

Getting the desired machine language instructions and data into the computer in executable form
requires the aid of a number of programs: the most important for us is the assembler. Other
important programs are the linker 4 and the operating system Supervisor. Each will be considered
in the appropriate context.

3 Some people call it “BAL” — meaning “Basic Assembler Language” — but the language is not basic (nor is it
BASIC) except in the sense that it can be fundamental to understanding the System z processor's operations.
4 The term “linker” here stands for several important programs that combine and load programs for execution. Their
names vary among operating systems (Binder or Linkage Editor and Program Loader on z/OS, Loader and Link
Editor on z/VM, Linkage Editor on z/VSE, etc.)

4 Assembler Language Programming for IBM System z™ Servers Version 2.00

 To give hardware designers greater freedom to implement instructions in the best way, without
your having to be aware of each implementation's techniques, IBM describes an “architecture”.
A processor's architecture defines the actions of instructions, I/O, storage, etc. to describe a
known set of behaviors, while giving processor designers flexibility in implementing those behav-
iors.

It will help to have available a copy of the z/Architecture Principles of Operation manual. It is
easily obtained, and is the reference for basic System z architecture. You should consult it regu-
larly when we discuss individual instructions.

Remember!
The Assembler Language itself is quite simple. The syntax is sparse, there
are few “reserved words”, and almost no structuring rules. The main
challenge in learning Assembler Language is learning about the processor
for which you're writing programs.

Von Neumann Architecture

The IBM System z processor is one of a large class of computers known as “Von Neumann
Architecture”, named after John Von Neumann, a mathematician at the Institute for Advanced
Study (IAS) in Princeton, NJ, USA. He and colleagues designed a processor in which programs
and data shared the same memory. A machine was built to that design in the early 1950s, and the
overall design (sometimes called “Institute machines”) was widely adapted in the U.S., Europe,
Japan, and Australia. 5

Why Program in Assembler Language (and Why Not)?

Before going any further, ask why you're considering writing programs in Assembler Language.
These are some reasons for programming in Assembler Language:
1. You have to.
Maybe you're taking a course like “Assembler Language Programming”, or you've been
made responsible for an existing Assembler Language application.
2. You want to.
It's useful to know, or maybe you're just curious about what is really going on inside the
processor when you write high-level language programs. The architecture represented by
System/360 and its modern descendants has pervaded the computing industry since the
mid-1960's, and will continue to do so for many years. Because you may encounter some
modern incarnation of the System/360 family, it helps to be familiar with its architecture.
3. It's educational.
Programming in Assembler Language is the best way to learn how the processor works.
Even if you program in high-level languages, there will be times when understanding the
processor's properties will help you understand why certain choices and tradeoffs are made in
programming in those languages.
4. It's fundamental.
A key to writing efficient software is understanding the underlying hardware; no language
other than Assembler Language provides such insights. Even if you don't write much Assem-
bler Language code, writing good high-level language programs often depends on knowing
how to write good Assembler Language programs.
Debugging a problem in high-level language applications may require knowing some machine
language. (You might say that a language needing this kind of debugging isn't very “high-
level”, but it is necessary at times.)

5 Why do I care? My first computer was the ILLIAC I, built to the IAS design.

Foreword 5
 Assembler Language is also a natural vehicle for recovering lost source code (yes, it
happens!). Object or binary programs can easily be disassembled into Assembler Language
source programs.
5. It can be more efficient.
Efficiency depends on many things. Because you can specify almost the exact instruction
sequences you want, you can do many things to improve program efficiency. If you know
which parts of a program consume the most time, recoding those parts in Assembler Lan-
guage can often lead to savings.
However, pursuing efficiency has limits. Programmers have been known to struggle happily
over a program modification that will save a few seconds of processor execution time over
the program's lifetime.6
There is another objection to using Assembler Language to attain efficiency: some modern
compilers can produce quite efficient code for certain applications.7 However, even clever
coding and powerful compilers can't help a badly implemented algorithm. Also, you may
have difficulty learning the costs of various high-level language statements.
6. It's independent.
Error recovery (and avoidance) can be simpler in Assembler Language than with high-level
languages.
You need not rely on the presence of any run-time environment other than the operating
system environment in which your program will execute. You can access many services that
may not be available to high-level languages.
7. It's more flexible.
There are some processor instructions and facilities for which higher-level languages provide
limited or no support. And even when these facilities are supported, their expression in such
languages may be inefficient, restricted, or difficult to use. Assembler Language may be the
simplest, or even the only, way to access those facilities.
Unlike many high-level languages, Assembler Language imposes no assumptions about how
you should (or must) structure your programs. Someone else's program structures or con-
cepts of proper programming technique aren't forced on you by the language, and you have
more freedom to choose solutions you like.
8. It's more powerful.
In addition to Assembler Language's efficiency and flexibility, you also have available to you
the entire repertoire of the processor's instruction set. New instructions on your CPU are
usable immediately; you don't need to wait for high-level language compilers to “catch up”
to the latest architecture. (Some instructions, though, may require special privileges such as
executing in supervisor state.)
9. It's more fun.
You can do things your own way. You can define the meanings of each and every piece of
your program, and not have to be satisfied with assurances that “the compiler (or the system)
takes care of that for you”.
10. It's controllable.
Unlike “higher-level” languages, the assembler creates machine language instructions and data
in exactly the form and order you specify. It doesn't try to organize (or re-organize) anything
for you; there are no “helpful” intermediaries between you and the processor. In a nutshell,
“What you write is what you get”.

6 And possibly wasting many more seconds of processor time re-assembling and re-linking the program than will be
ever saved during its execution! (Yes, I've done that...)
7 Compilers do have occasional errors; finding problems with the generated code is easier if you know Assembler
Language.

6 Assembler Language Programming for IBM System z™ Servers Version 2.00

11. It's stable.
You needn't worry about re-translating and re-testing programs with new releases of com-
pilers or run-time libraries; the object code won't change each time you re-assemble.
12. It's parameterizable.
Because assembler languages have been with us for almost as long as computers, a lot has
been learned about minimizing the pain of modification: we will see that the Assembler Lan-
guage is very rich in possibilities for parameterization. That is, you can revise a value in just
one place in your program, and the assembler automatically adjusts the portions of your
program that depend on that value.
13. It's extensible.
This is one of the best reasons for programming in Assembler Language: you can define
macro instructions that have whatever meaning you want them to have. You can design and
create an entire programming language of your own, and then build other languages on top
of that, for as many levels as you like or need. Macro-instructions also provide some
“insulation” between your program and the habits of the Operating System under whose
control it will run.
Macro instructions are definitely a highly satisfying aspect of Assembler Language program-
ming. Unfortunately, we don't have room here to describe conditional assembly and macros.

Conversely, there are also reasons for not programming in Assembler Language.
1. The language can be verbose.
Economy of expression is not a characteristic of most Assembler Languages except (and this
is an important exception) for the availability of macro instructions. Usually, you must write
more lines of code to do a simple task than if you had chosen a higher-level language.
This is due mainly to the richness of the z/Architecture processor's instruction set, because
the Assembler Language itself is quite simple.
2. The language is very flexible.
It can be too flexible for some users. There are many acceptable ways to use Assembler
Language to solve a given problem, and almost all problems can be solved with a small and
manageable set of instructions.
3. The language is idiosyncratic.
To a large extent, the occasional lapses of regularity and coherence in the syntax and seman-
tics of the Assembler Language are due to irregularities in the System z instruction set and
architecture: instructions that do similar things may have different syntaxes. Thus, the
Assembler Language contains occasional “special cases” and “exceptions to the rules”. (This
is of course not unique to Assembler Language!)
4. The language's flexibility means it's easier to make errors.
While this reason is implicit in the previous three, it also is part of the price you pay for
being able to specify everything yourself; you have more chances to make mistakes. We will
see that there are good ways to avoid some of the pitfalls that this extra freedom provides.
5. Programs can be harder to debug.
In some cases, programmers may not write programs so they can detect processing errors, or
terminate gracefully. Because programs can be written with great freedom, they might not be
organized so that errors do a minimum amount of damage. Similarly, some programmers are
often reluctant to insert the extra instructions necessary to leave an easily-followed diagnostic
trail for the person (you?) trying to discover why your program did something unexpected.
6. Programs may seem hard to maintain.
Maintenance costs are much more strongly influenced by the structure and clarity of the code
than by the language used to write it. Extensive research has shown little difference in mainte-
nance costs between Assembler Language and high-level languages.

Foreword 7
 7. Lack of a run-time library.
Assembler Language programs can be written as a component of a high-level language appli-
cation. But “stand-alone” Assembler Language applications may not have access to the run-
time libraries provided with most high-level languages. By using careful modular design
techniques, this lack can be overcome with a set of routines or macro instructions that
provide functions shareable among many applications.
Assembler Language programs can access run-time libraries, so long as they adhere to appro-
priate programming conventions; this can often reduce programming effort.
8. Lack of portability.
Unlike programs written in some high-level languages, assembler language code is intended
for execution only on the processors for which it is created. (And, high-level language pro-
grams are not always easily moved to other processor architectures!)

If none of the reasons for programming in Assembler Language has much appeal to you — you
don't have to program in Assembler Language, you don't need its efficiency, flexibility, power, or
extensibility, and your sources of amusement (or employment) lie elsewhere — then don't. Use
whatever tool will do the job with the least time, effort, and nuisance, and get on to whatever task
comes next.

Assembler Language Misconceptions

These are some common misconceptions about Assembler Language:
• Assembler Language is dead.
For many small-environment or short-lived applications, fast implementation is more impor-
tant than long life, small size or high performance. But many substantial organizations have
made major investments in Assembler Language applications that must be fast, compact, and
can process high volumes of data efficiently; such applications need regular enhancement.
• It's hard.
The language itself is trivially simple. Understanding programs in any programming language is
more a matter of clear coding and good style and organization. Any programming task can be
made easy or difficult. (We'll offer occasional bits of advice on ways to simplify your program-
ming challenges.)
• Assembler Language programs are faster than compiled programs.
That depends more on your choice of algorithms, the high-level language, and its compiler.
You can write slow programs in any language.
• Assembler Language programs are hard to read.
Only if you write them that way! But you do need to understand the System z instructions.
• It's hard to manage all those base registers.
Not at all: careful program organization and appropriate instruction choice easily make it a
non-problem.
• Assembler Language is hard to maintain, especially if you don't have the needed skills.
Extensive research shows little difference in maintenance costs among programming languages,
and lack of skills is a problem for any programming language.
• Many applications written in Assembler Language can be replaced with “out-of-the-box”
functionality.
It's rare that a purchased software package does exactly what your organization needs; you
must pay in time and money for negotiating, training, and adaptations that you could com-
plete “at home” more promptly and cheaply.
• You don't need to worry about efficiency, because a faster CPU will be along in a year.

8 Assembler Language Programming for IBM System z™ Servers Version 2.00

 Rarely true, because growing businesses continually need to process more data and their pro-
grams must provide new capabilities. Once you fall behind, it's difficult to rewrite inefficient
applications.
• Converting an Assembler Language application to a high-level language will make it easier to
hire skilled programmers.
There are some critical factors here: research has shown that
1. Changing language has many hidden costs and should be avoided.
2. High-level languages do not improve reliability or maintainability.
3. Problem-domain expertise is often more important than programming-language expertise.
It it much easier to train people who understand your business and business processes in
the language you need, rather than hiring people who have the necessary language skill.
Some further considerations include:
− Transition and testing require system stability, which implies possible lost business oppor-
tunity.
− Converting and validating test cases can be a major effort in itself.
− High stress levels for “bilingual” staff.
• You can't do “Structured Programming” in Assembler Language.
− By using a set of Structured Programming macros such as those available with the High
Level Assembler, programs can be as fully structured as any high-level language program.
− Because you have full control over the separation of code and data into individual modules,
you can have greater flexibility in determining the structure of an application than a typical
high-level language may provide.

Remember!

What's good about Assembler Language?

Almost everything you do works OK.

What's bad about Assembler Language?

Almost everything you do works OK.

Exercises
0.1.1.(1) + Why are you interested in Assembler Language?

0.1.2.(0) What is the difficulty level of this exercise?

Foreword 9
10 Assembler Language Programming for IBM System z™ Servers Version 2.00
Chapter I: Getting Started

IIIIIIIIII
IIIIIIIIII
II
II
II
II
II
II
II
II
IIIIIIIIII
IIIIIIIIII

In this chapter, we will look at factors involved in Assembler Language programming, and then
investigate the binary number representation and its arithmetic.
• Section 1 looks at some notation, terminology, and conventions we'll use.
• Section 2 describes basic topics about the number representations used in System z processors:
binary and hexadecimal numbers, arithmetic and logical representations, 2's complement arith-
metic, and discusses alternative number representations.

Chapter I: Getting Started 11

1. Some Basic Items

11
111
1111
11
11
11
11
11
11
11
1111111111
1111111111

In this section we introduce some basic terms and notations that we'll use later, and then investi-
gate the important properties of the binary number representation.

1.1. Notation and Terminology

• Some diagrams and figures need to show the lengths and positions of parts of the figure. In
Figure 1 we want to show some object's structure, and to indicate the amount of space
required for each of its components. To do this, we place a number above the field to indicate
its length. In cases where we also indicate the numbering and positions of the digits in that
component, we use numbers below the field, at its right and left ends. Two four-digit fields in
an eight-digit area would be as shown in Figure 1:

4 4 ─── Field widths

┌────────┬────────┐
│ Field1 │ Field2 │
└────────┴────────┘
0 3 4 7 ─── Start and end positions of fields
Figure 1. Example of numbering and notation

By convention, numbering starts with digit zero on the left. We call the leftmost digit, digits,
or portion of a field the high-order part of the field; the rightmost digit, digits, or portion of the
field the low-order part. Thus, position 0 in this figure is the high-order digit, and position 7 is
the low-order digit.
• Standard mathematical symbols such as subscripts and superscripts, and the capital Sigma used
to denote summation are hard to produce, so we sometimes use a slightly different notation.
For subscripted quantities like B k (“B-sub-k”) we will sometimes use “B k”, but also either
“Bk” or the programming-language convention “B(k)”. For quantities like “element i,j of
ARRAY” or “ARRAY-sub-i,j” (often written “ARRAY i,j”) we write “ARRAY(i,j)”. There
are very few places where the juxtaposition of two letters like “XY” means multiplying X and
Y, but these will be obvious from the context where they appear. In some cases we use super-
scripts for quantities like 10 5 and B k, but we also use the common notation of paired asterisks
to denote exponentiation, as in 10**5 and B**k.

12 Assembler Language Programming for IBM System z™ Servers Version 2.00

 • For the operations of addition, subtraction, multiplication, and division, we use the operators
+, − , *, and / respectively. (In some descriptions, we use “×” for multiplication and “÷ ” for
division.) We use vertical bars or the functional notation ABS() to denote absolute values: |x|
and ABS(x) mean the magnitude of the quantity x.
• To denote the contents of something called “x”, we use c(x) or C(x). Sometimes the object
whose contents we're interested in will be an identifiable object such as a register, so that we
might speak of the contents of Register 1 as c(R1). At other times we may speak of the con-
tents of something whose actual form or location is not precisely known, such as an area of
memory that has been given the name AREA; in this case we still use the notation c(AREA).
• Some words have similar but different meanings. For example, the word “operand” is used in
several different senses in most of the literature describing System z and its Assembler Lan-
guage.
1. In the description of instructions in the z/Architecture Principles of Operation, an operand
is the object being operated on, or is involved in the instruction. For example, in
LM R1,R3,S2
the contents of general register designated by R1 is the first operand, and the contents of
storage addressed by S2 is the second operand. Note that operand numbers may not corre-
spond to their sequential position!
2. In an Assembler Language statement, an operand is defined by its position in the operand
field. For example, in
LM 2,12,SAVE
the first operand is 2, the second operand is 12, and the third operand is the symbol SAVE.
Note the difference in operand numbering compared to the z/Architecture Principles of
Operation description!
3. During execution, an operand is the subject of an operation: an operand is something
being acted on or operated on by an instruction as it is executed in the processor. For
example, in
LM 2,12,SAVE
one operand is the contents of general register 2, and another operand is the contents of
memory named by the symbol SAVE.
We'll try to clarify these differences; the intended sense will be usually clear from the context in
which the word appears.
• Sometimes we need to indicate positions where a blank or space character should appear.
Rather than use a blank “ ” character, we sometimes use a “•” character. For example,
John•Q.•Public
has a blank on each side of the middle initial.
• Sometimes we refer to the “euro” character. Because this document formatter doesn't have
that exact character, we use ∈ as the best available approximation.

Exercises
1.1.1.(1) What is the total width of the fields illustrated in Figure 1 on page 12?

1.2. Instruction Elements

We will often refer to parts of a machine instruction. In the z/Architecture Principles of
Operation, you will see notations like
R1,R2 or D2(X2,B2) or M1 or I2 or L1
where the subscripted letters specify numeric values appearing in the fields of a machine instruc-
tion. They are simply a way to indicate numbers that you or the assembler must provide. In
particular:
• A notation like “R 1” is simply a number that usually denotes any register, not “register
number 1”.

Chapter I: Getting Started 13

 • “ G R R 1” means the general register denoted by the number used in place of R1.
• “GR1” means general register 1.

We'll clarify these and other details as we proceed.

1.2.1. Register Names

We refer regularly to registers, using small numbers like 0, 12, etc. Some people like to use
“names” like R0 and R12 for them. They can be helpful, but can also be very misleading, because
“R0” isn't really a register name; it's only a name for a number. (Some exercises will help you
understand why it can be misleading.) I don't want you to develop a habit of thinking that names
like “R0” always mean “register 0”. I prefer to use just numbers like “0” or “12” to designate
register names.8 That said, we will sometimes refer to a specific register using terms like R0 and
R12, meaning specifically general registers 0 and 12.

Unlike some other processors and their assemblers, there are no reserved register names or
symbols in the System z Assembler Language.

Exercises
1.2.1.(1) If R 1 has value 9, what register is referenced by GR R 1?

Terms and Definitions

algorithm
A finite sequence of well-defined steps for solving a problem. After al Khwarizmi, a nick-
name of the 9th century Persian astronomer and mathematician Abu Jafar Muhammad ibn
Musa, who authored many books on arithmetic and algebra. He worked in Baghdad and his
nickname alludes to his place of origin, Khwarizm (Khiva), in present-day Uzbekistan and
Turkmenistan.
architecture
A description of “the attributes of a system as seen by the programmer, i.e., the conceptual
structure and functional behavior, as distinct from the organization of the data flow and con-
trols, and the physical implementation.” 9
assembler
A program that translates programs written in Assembler Language to machine language
instructions and data.
Assembler Language
A lower-level language allowing programmers maximum freedom in specifying processor
instructions, providing powerful “macro instruction” facilities supporting encapsulation and
economy of expression.
blank
A nonempty, finite-width invisible character; a space. In contexts where explicit blank spaces
appear, we sometimes use the “•” character.
HLASM
IBM's High Level Assembler for z/OS and z/VM and z/VSE. The assembler we describe
here.

8 One reason for using symbolic register names was that all early assemblers' “Symbol Cross Reference” (a list of all
symbols used in your program) showed the places where the names were used — and searching the cross-reference
might be the only way to know which instructions might have referenced specific registers. The IBM High Level
Assembler for z/OS & z/VM & z/VSE provides a “Register Cross Reference” showing where the general registers
were used, whether or not they were named. So, it's no longer necessary to “name” registers.
9 G.M. Amdahl, G.A. Blaauw, and F.P. Brooks, Jr. Architecture of the IBM System/360, IBM Journal of Research
and Development Vol. 8 No. 2, 1964, reprinted in IBM Journal of Research and Development Vol. 44 No. 1/2,
January/March 2000.

14 Assembler Language Programming for IBM System z™ Servers Version 2.00

operator
A character specifying a mathematical operation: + for addition, − for subtraction, * or × for
multiplication, and / or ÷ for division.
space
A nonempty, finite-width invisible character; a blank character. In contexts where explicit
blank spaces appear, we sometimes use the “•” character.

Chapter I: Getting Started 15

2. Binary and Hexadecimal Numbers

2222222222
222222222222
22 22
22
22
22
22
22
22
22
222222222222
222222222222

In this section we examine number representations and methods for converting numbers in those
representations to and from decimal. Then we examine arithmetic using numbers in the binary
representation.

System z, like most other digital computers, uses binary—base two —numbers for most internal
arithmetic. A binary digit takes only values 0 and 1; because it is relatively simple to build a
mechanical or electrical device representing a binary digit, the binary representation is quite
natural. For example, a 1 digit may be represented by the presence of a current through a circuit
component or by the presence of a positive voltage at some point. Facility with binary numbers is
fundamental to understanding the basic operations of System z, so it is important to understand
the binary number representation.

For now, all numbers are assumed to be integers. This means that the “decimal point” (the
“radix point” or “binary point”) lies at the right end of the number. We will discuss nonintegral
(fractional) numbers in Sections 29 and 31.

We are familiar with numbers using radixes other than 10. Times (and angles) measure minutes
and seconds using radix 60; hours are counted using radix 24; and before The United Kingdom
changed to a decimal monetary system: radix 20 for shillings and radix 12 for pence. Binary is
easier.

2.1. Positional Notation and Binary Numbers

In base ten, writing a number such as “1705” means the quantity
1000 + 700 + 00 + 5,
which can also be written as
1×1000 + 7×100 + 0×10 + 5×1,
or as
1×103 + 7×102 + 0×101 + 5×100.

That is, each digit position as we move to the left is weighted by one more power of the base, ten.

16 Assembler Language Programming for IBM System z™ Servers Version 2.00

 Similarly, when in binary notation we write “11010” we mean
10000 + 1000 + 000 + 10 + 0,

1×24 + 1×23 + 0×22 + 1×21 + 0×20,

1×16 + 1×8 + 0×4 + 1×2 + 0×1

which is not the same as what is meant by the decimal number 11010, where powers of ten are
understood. In fact, the binary number 11010 is the representation (in the number system with
base two) of the decimal number 26: the sum in this example is 16+8+2.

To clarify which base is intended we use a notation like the Assembler's: if base 10 is intended,
the digits are written normally; if base 2 is intended, the binary digits are preceded by a “B” and
an apostrophe, and are followed by an apostrophe. For example:
26 = B'11010', 1 = B'1', 10 = B'1010', 8 = B'1000', 999 = B'1111100111'.

Positional notation can be used for any base (or radix). For example, if humans had only one
hand we might use base 5 for numbering, so that 1413 in base 5 would have decimal value 233 (in
our ten-finger decimal world):
14135 = 1×53 + 4×52 + 1×51 + 3×50
= 125 + 100 + 5 + 3
= 23310

Exercises
2.1.1.(1) + Determine the decimal value of the following binary numbers: (a) B'000010110', (b)
B'000101100', (c) B'10101010', (d) B'1111111'.

2.1.2.(1) + Suppose a binary number is represented by a single 1-bit followed by a string of n

zero bits (100...00). What is its value?

2.1.3.(2) Suppose a binary number is represented by a string of n one bits (111...11). What is
its value?

2.2. Hexadecimal Numbers

As values become larger, the number of binary digits required becomes larger also (over three
times as many bits as decimal digits), so we use a more compact notation for binary numbers. If
we consider groups of four binary digits at a time, the possible decimal values that can be repres-
ented run from zero to fifteen. If we then represent each of these groups by the “digits” 0, 1, 2, 3,
4, 5, 6, 7, 8, 9, A, B, C, D, E, F, we can establish the correspondences shown in Table 1 on
page 18. (The letters A through F are a natural choice for “digits”, but we could actually have
chosen any other six symbols to represent the “digits” to which we assign the values 10, 11, ...,
15.10)

We use the same positional notation for base 16 number representation as for decimal and binary
numbers. Thus, we can write the base 16 number A97E 16 as
A×163 + 9×162 + 7×161 + E×160,
or
10×163 + 9×162 + 7×161 + 14×160 = 10×4096 + 9×256 + 7×16 + 14 = 43390.

10 In fact, some early computers such as the ILLIAC I used the characters K, S, N, J, F, and L because those letters
had the required binary 4-bit hole combinations on 5-hole punched paper teletype tape. (Remembering those six
letters was helped by the phrase “Kind Souls Never Josh Fat Ladies”.)

Chapter I: Getting Started 17

 Why use something as unfamiliar as a base-sixteen representation for numbers that are binary in
nature? Base 16 is compact and convenient for expressing long strings of binary digits, and a
natural representation for System z. Other groupings are possible; another form is “octal”, or
base eight, in which the binary digits are grouped by threes.11

Table 1. Binary, decimal, and

hexadecimal
Binary Decimal Hex
Digits Value Digit
0000 0 0
0001 1 1
0010 2 2
0011 3 3
0100 4 4
0101 5 5
0110 6 6
0111 7 7
1000 8 8
1001 9 9
1010 10 A
1011 11 B
1100 12 C
1101 13 D
1110 14 E
1111 15 F

The base sixteen digits in the third column are called hexadecimal12 or hex digits, and we use them
in most situations when we need to refer to binary numbers. As with binary numbers, a notation
similar to the Assembler's will denote hexadecimal quantities: the hexadecimal digits are preceded
by an “X” and an apostrophe, and are followed by an apostrophe. For example:
26 = B'11010' = X'1A', X'26' = B'100110' = 38,

1 = B'1' = X'1', 10 = B'1010' = X'A',

B'1000' = 8 = X'8', 100 = X'64' = B'1100100'.

Converting numbers between binary and hexadecimal representations is easy:

• To convert a hexadecimal number to binary, substitute for each hexadecimal digit the four
binary digits it represents.
• To convert a binary number to hexadecimal, group the binary digits four at a time starting
from the right (adding extra zeros at the left end if needed), and substitute the corresponding
hexadecimal digit.

For example:
X'D5B' = B'1101 0101 1011' (hexadecimal to binary),

B'11 1110 1000' = X'3E8' (binary to hexadecimal).

In the second example we could add two extra binary zero digits at the left or “high-order” end of
the number without affecting its value; similarly, we can omit high-order zero digits, and write
X'11' = B'10001' (rather than B'00010001').

11 Processors whose word lengths were “natural” multiples of 3 included the IBM 70x and 709x processors with 36-bit
words, and several Control Data Corporation (CDC) processors with 48-bit words. Most processors now have word
lengths that are a multiple of 8 bits.
12 The correct term for base 16 is “sexadecimal” (or even “hexadecadic”), but you can understand that abbreviating the
term “sexadecimal” would not be appropriate for dignified corporations.

18 Assembler Language Programming for IBM System z™ Servers Version 2.00

 Don't omit zeros on the right! That is, B'00111100' ≠ X'F'.

Converting between decimal and hexadecimal representations is more cumbersome; it is simplest

to use Tables 2 and 3 starting on page 20 below, and the tables in “Appendix A: Conversion and
Reference Tables” on page 995. The following section discusses general methods for converting
integers from one base to another; if you are satisfied to use the tables, the next section may be
skipped.

We use these abbreviations regularly: bit means “binary digit”, and hex is an abbreviation for
“hexadecimal”.

Exercises
2.2.1.(1) Convert the following hexadecimal numbers to binary: (a) X'A', (b) X'2B', (c) X'3E8'.

2.2.2.(1) Make a table similar to Table 1 on page 18 showing binary, decimal, and octal (base
8) values.

2.2.3.(2) In grouping bits to form hex digits, why can't we start at the left? That is, why do we
begin grouping at the radix point?

2.2.4.(2) + Create addition and multiplication tables for single hexadecimal digits.

2.2.5.(1) Convert the following octal numbers to hexadecimal:

1. 21474
2. 77777
3. 1750
4. 60341303
5. 4631

2.2.6.(3) You may have noticed that the characters in many cartoons and comics have only four
fingers. To help them with “cartoon arithmetic”, create base-8 (octal) addition and multipli-
cation tables.

2.3. Converting Integers from One Base to Another (*)

In our familiar notation, a string of digits like 73294 in some base A means
7×A4 + 3×A3 + 2×A2 + 9×A1 + 4×A0.
Using symbols, the digit string
dn ... d3 d2 d1 d0
is the representation in some base A of a number X:
X = dn×An + ... + d3×A3 + d2×A2 + d1×A1 + d0×A0.

The subscripts on the digits d match the power of the base A. If A has value 10, then the digit
string 73294 is the familiar decimal number seventy-three thousand, two hundred ninety four.

Suppose we want to convert X from its representation in base A to its representation in a new
base B, with digits e0, e1, e2, etc.:
X = em ×Bm + ... + e3×B3 + e2×B2 + e1×B1 + e0×B0.

We know the old and new bases A and B, and the digits d k of the old representation. To find the
digits e k of the new representation, we use the following scheme;
1. Divide X (in base A notation and arithmetic) by the new base B; save the quotient. The
remainder is the low-order digit e 0. This can be seen from the definition of the quotient and
remainder:

Chapter I: Getting Started 19

 X = B × Quotient + Remainder
= B × [em ×B(m-1) + ... + e3×B2 + e2×B1 + e1×B0] + e0.
where the term in square brackets is the quotient.
For example, taking A to be 10 and B to be 16, we convert 73294 to hex:
X = 73294 = 16 × Quotient + Remainder = 16 × 4580 + 14,
so e0 = 1 4 = X'E'.
2. Now, divide the saved quotient by B; save the new quotient, and the new remainder is e 1.
In our example, dividing 4580 by 16 gives quotient 286 and remainder 4, the value of the
next digit, e1.
3. Continue this process until a zero quotient is obtained. The successive remainders are the
desired digits e0, e1, ..., e m ; they were obtained in order of increasing significance, from right
to left.
Continuing to divide by 16 in our example, we obtain remainders 14, 1, and 1; these are the
digits e2, e3, and e 4 respectively. The result of this sample conversion shows that 73294 (base
10) has value 11E4E (base 16).

Our most frequent conversions are between decimal and binary or hexadecimal; use Tables 2 and
3, or the conversion tables in Appendix A.
1. If the number is small enough, find it in the conversion tables.
2. For larger numbers,
a. To convert from hex to decimal, find each digit's decimal value in the tables in Tables 2
and 3, and evaluate the sum.
b. To convert from decimal to hex, find the largest power of 16 in the tables that is less
than or equal to your number, subtract that number, and note the corresponding hex
digit. Repeat, writing the hex digits from left to right. The following example shows how
to do this for the decimal value 1000:
1000
-768 hex digit 3
232
-224 hex digit E
8
-8 hex digit 8
0
so that 1000 (decimal) is X'3E8'.

Table 2. Multiples of powers of sixteen (part 1 of 2)

Hex Digit × 160 × 161 × 162 × 163 × 164
1 1 16 256 4,096 65,536
2 2 32 512 8,192 131,072
3 3 48 768 12,288 196,608
4 4 64 1,024 16,384 262,144
5 5 80 1,280 20,480 327,680
6 6 96 1,536 24,576 393,216
7 7 112 1,792 28,672 458,752
8 8 128 2,048 32,768 524,288
9 9 144 2,304 36,864 589,824
A 10 160 2,560 40,960 655,360
B 11 176 2,816 45,056 720,896
C 12 192 3,072 49,152 786,432
D 13 208 3,328 53,248 851,968
E 14 224 3,584 57,344 917,504
F 15 240 3,840 61,440 983,040

20 Assembler Language Programming for IBM System z™ Servers Version 2.00

 Table 3. Multiples of powers of sixteen (part 2 of 2)
Hex Digit × 165 × 166 × 167
1 1,048,576 16,777,216 268,435,456
2 2,097,152 33,554,432 536,870,912
3 3,145,728 50,331,648 805,306,368
4 4,194,304 67,108,864 1,073,741,824
5 5,242,880 83,886,080 1,342,177,280
6 6,291,456 100,663,296 1,610,612,736
7 7,340,032 117,440,512 1,879,048,192
8 8,388,608 134,217,728 2,147,483,648
9 9,437,184 150,994,944 2,415,919,104
A 10,485,760 167,772,160 2,684,354,560
B 11,534,336 184,549,376 2,952,790,016
C 12,582,912 201,326,592 3,221,225,472
D 13,631,488 218,103,808 3,489,660,928
E 14,680,064 234,881,024 3,758,096,384
F 15,728,640 251,658,240 4,026,531,840

The binary powers 2 10, 220, and 230 are often abbreviated by the letters “K”, “M”, and “G”.
Thus, it is common to refer to the decimal number 4,096 = 212 as “4K”. Similarly, 3×220 might
be referred to as “3M”. Thus, for example, an area of memory (which we'll discuss in Section
3.1) containing 8,192 storage locations might be said to contain “8K bytes” or “8 K-bytes”. 13

Exercises
2.3.1.(2) + Convert these numbers from the given base to the new bases.

1. 26293 (base 10) to bases 2, 4, 8, and 16.

2. X'2FACED' (base 16) to bases 10 and 2.
3. X'BABEF00D' (base 16) to bases 10 and 8.
4. X'C0FFEE' (base 16) to bases 10 and 2.

2.3.2.(2) Convert the following to decimal.

1. X'7FFFFFFF'
2. X'C1C2C3'
3. X'4040405C' (This digit pattern will reappear in other forms!)

2.3.3.(3) Make a table of the hexadecimal values of the squares of the integers from 1 to 32.

2.3.4.(2) + Convert the following hexadecimal numbers to decimal.

1. X'257'
2. X'7FFA'
3. X'8008'
4. X'E000'
5. X'FFFA'
6. X'E1010'

2.3.5.(3) Suppose we must convert a number from its representation in base A to its represen-
tation in base B. In which base will it be most convenient to do the arithmetic involved in the
conversion? How does the result depend on the base used for the conversion?

2.3.6.(2) Convert these octal (base 8) numbers to base 10: (a) 5061, (b) 257, (c) 192. Work
carefully!

13 More properly, the abbreviations K, M, and G refer to the closest powers of 10: one thousand = 1K = 10 3, one
million = 1M = 10 6, etc. To avoid this confusion, you can use the more precise terms “Ki”, “Mi”, and “Gi” to
refer to the binary powers. But few computer people bother.

Chapter I: Getting Started 21

 2.3.7.(2) What decimal values are represented by the binary numbers 9K, 5M, and 2G?

2.4. Examples of General Conversions (*)

We will use the division methods described in the previous section to illustrate conversions from
one base to another.
1. Convert 19 (base 10) to base 2.

9 4 2 1 0
2)19 2)9 2)4 2)2 2)1
18 8 4 2 0
1=e0 1=e1 0=e2 0=e3 1=e4
Hence, 19 = B'10011'.
2. Convert 1000 (base 10) to base 16. (The conversion arithmetic is done in base 10.)

62 3 0
16)1000 16)62 16)3
992 48 0
8=e0 14 (X'E')=e1 3=e2
Hence 1000 = X'3E8'.
3. Convert 627 (base 10) to base 9.

69 7 0
9)627 9)69 9)7
621 63 0
6=e0 6=e1 7=e2
so that 627 (base 10) = 766 (base 9).
4. Convert 766 (base 9) to base 7. First, we convert to base 10, and then do the arithmetic in
decimal:

766 (base 9) = 7×81 + 6×9 + 6 = 567 + 54 + 6 = 627 (base 10)

89 12 1 0
7)627 7)89 7)12 7)1
623 84 7 0
4=e0 5=e1 5=e2 1=e3
so that 766 (base 9) = 1554 (base 7).
If you are mathematically inclined:
Just for fun, now do the conversion in base 9:

108 13 1 0
7)766 7)108 7)13 7)1
762 103 7 0
4=e0 5=e1 5=e2 1=e3
Thus 766 (base 9) = 1554 (base 7) again. This shows that you can
do base conversion using any (other) base for the arithmetic.

5. Convert 1413 (base 5) to base 10. This is simplest if we expand the positional notation:

1413 (base 5) = 1×125 + 4×25 + 1×5 + 3 = 233 10 .

22 Assembler Language Programming for IBM System z™ Servers Version 2.00

 If you are still (or very) mathematically inclined:
Alternatively, since 10 (base 10) = 20 (base 5), we can do the con-
version in base 5 arithmetic:

43 2 0
20)1413 20)43 20)2
130 40 0
113 3=e1 2=e2
110
3=e0
Again, we find 1413 (base 5) = 233 (base 10).

6. Convert X'3E8' to base 10. In this case it is simpler to evaluate the positional notation:
X'3E8' = 3×162 + 14×161 + 8×160,
and then evaluate this sum in decimal. Thus we find
X'3E8' = 3×256 + 14×16 + 8 = 768 + 224 + 8 = 1000.
This type of conversion can be simpler if you use the table of multiples of powers of 16 in Tables
2 and 3, or the conversion tables in Appendix A.

Exercises
2.4.1.(2) Perform the indicated conversions. For number bases greater than 10, assume that the
“digits” corresponding to 10, 11, 12, etc., are represented by the letters A, B, C, etc., respec-
tively.

1. Convert 31659 (base 10) to bases 8, 4, and 2.

2. Convert 6917 (base 10) to bases 5, 13, and 16.
3. Convert X'EF2A' (base 16) to bases 10 and 13.

2.4.2.(2) + Make a table of the hexadecimal representations of the first ten powers of ten, from
100 to 10 9. (Suggestion: use hexadecimal arithmetic, and multiply each term by X'A' to obtain
the next.)

2.4.3.(3) Make a table like those in Tables 2 and 3, except that the nine multiples of the powers
of ten from 0 to 9 should be expressed in hexadecimal notation.

2.4.4.(3) Convert B'1111101000' to base 10 using binary arithmetic (that is, divide by B'1010').

2.4.5.(3) Convert 73294 (base 10) to bases 11, 12, 13, 14, and 15. Can you make any use of the
result of converting to base N to help in converting to base N+1?

2.4.6.(3) Make a base seven multiplication table. Use it to perform the following conversions
directly, without first converting to base ten: (1) 526 (base 7) to base 16, (2) 10110 (base 7) to
base 8, (3) 61436 (base 7) to base 8, (4) 666 (base 7) to base 10.

2.4.7.(2) Convert 629 (base 11) to bases 10 and 12.

2.4.8.(3) In converting from some base A to base 10, it is usually most convenient to expand
the positional notation as illustrated in Examples 5 and 6 of Section 2.4. We can also expand
the positional form by rewriting it in “nested” form:
X = (((...(dn×A)+...+d3)×A+d2)×A+d1)×A+d0.
That is, the leftmost digit is multiplied by A, the next digit is added to it and the result is multi-
plied by A, and so forth until the rightmost digit has been added. Using this technique, perform
the following conversions.

1. 2F3 (base 25) to base 10.

2. 61436 (base 8) to base 10.

Chapter I: Getting Started 23

 3. X'DEFACE' (base 16) to base 10.
4. 999 (base 10) to base 16.

2.4.9.(2) In applying the “nested multiplication” technique of the previous exercise to conver-
sions from base A to base B, what base should be used for the conversion arithmetic?

2.4.10.(3) Using the base seven multiplication table you made in Exercise 2.4.6, perform the
following conversions in base 7 arithmetic: (1) 526 (base 10) to base 16, (2) 10110 (base 2) to
base 5, (3) 61436 (base 8) to base 10, (4) 666 (base 10) to base 7.

2.4.11.(3) Write the decimal value 8 in bases 8, 7, 6, 5, 4, 3, 2, and 1.

2.4.12.(3) If you have two numbers in bases A and B, what is a necessary relationship between
A and B that will allow you to use the same “digit grouping” technique you used to convert
between binary and hexadecimal?

2.4.13.(3) Show the value of 1610 in bases 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, and 3.

2.4.14.(4) Using base 7 arithmetic, calculate the sum and product of 435 7 and 64 7. First,
convert those two numbers to base 10 and then add and multiply the results in base 10; then
use those results to test that you have evaluated the base 7 sum and product correctly.

2.4.15.(2) Convert the following decimal values to base 3: 2, 6, 10, 12, 16, 28, 41, 99, 104.

2.5. Number Representations

Now that we know how to convert numbers between binary and hexadecimal, we will see how
they are used in System z for address calculations, indexing, and integer arithmetic. Up to now,
we have examined the binary number representation only for nonnegative numbers; representing
negative numbers requires further consideration.

There are three fixed-point (integer) number representations in common use: the radix-
complement, the sign-magnitude, and the diminished radix-complement representations. In prac-
tice, the widely-used radix-complement representation is called the two's complement
representation, and the diminished radix-complement representation is called the ones' complement
representation. 14 Two of these representations are used in System z: the two's complement form is
used for addressing and integer arithmetic, and the sign-magnitude form is used for floating-point
and packed decimal numbers. A variation of the radix-complement form is used internally for
packed decimal arithmetic, which we'll see in Chapter VIII.

With so many representations, you might wonder why the System z designers settled on two's
complement. The reason follows from the processor's “architecture”: since virtually all computers
use the two's complement representation for address arithmetic, and because in System z the
general registers are used for both arithmetic and addressing, it is natural that ordinary integer
arithmetic has the same form.

We will illustrate the following discussion using 32-bit numbers, corresponding (as we shall see) to
the length of a word in memory and half the length of a general register.15

14 Why is it called “two's complement”? The name of the ones' complement representation seems obvious: just comple-
ment each bit by subtracting it from 1 (or, change 0 to 1 and 1 to 0); but we don't get the two's complement by
subtracting each bit from 2! We'll explain this oddity shortly.
15 z/Architecture provides 64-bit general registers, but for now our examples will use the 32-bit length.

24 Assembler Language Programming for IBM System z™ Servers Version 2.00

2.6. Logical (Unsigned) Representation
To begin, we examine what is represented by the rightmost 32 bits of any nonnegative integer.

This is represented
by:
0 X'00000000'
1 X'00000001'
130 X'00000082'
224 − 1 X'00FFFFFF'
231 − 1 X'7FFFFFFF'
231 X'80000000'
2 −1
32 X'FFFFFFFF'
232+ 1 X'100000001'

Thus, if a number is less than 232, its value can be held correctly in the 32 available bits. If it is
greater than or equal to 232, some significant bits are lost off the left end. (That is, the number's
value is represented modulo 232.) Some instructions perform unsigned addition and subtraction
with numbers that satisfy the inequalities
0 ≤ x ≤ 232-1.
Such arithmetic is called logical or unsigned arithmetic; we call this the logical or unsigned repre-
sentation of binary numbers. If the 32 bits of a logical binary integer are denoted b31,b 30,...,b 1,b 0
(this temporary scheme is the reverse of the field-numbering convention introduced in Figure 1
on page 12), then the value X represented by the binary digits b31 b 30...b 1 b 0 is
X = b31×231 + b30×230 + ... + b2×22 + b1×21 + b0×20
in the logical representation. This is the most common numeric interpretation of a string of bits.

The representation of a nonnegative 32-bit number less than 2 31 is the same in the sign-
magnitude, ones' complement, and two's complement representations (and is also the same as its
logical representation), no matter which of the three forms is chosen to represent negative
numbers. Since the two's complement representation is used for most integer arithmetic in
System z, we will investigate its properties in detail. Arithmetic using binary numbers in this
representation will be covered shortly.

Exercises
2.6.1.(2) + Give the decimal value of the following hexadecimal numbers in the logical represen-
tation:

1. X'DEADBEEF'
2. X'FFFFFFFF'
3. X'DEC0DED1'

2.7. Two's Complement (Signed) Representation (*)

This section describes the mathematical justification for the two's complement representation.
You can skip to Section 2.8 where a simple “recipe” for calculating the two's complement of a
number is shown on page 27.

Most programs must deal with both positive and negative numbers. A single bit (usually, the left-
most) is used to represent the number's sign. A 0 bit represents a “ + ” sign, and a 1 bit represents
a “ − ” sign.

First, the two's complement representation of a 32-bit nonnegative binary integer Y satisfying the
inequalities
0 ≤ Y ≤ 231−1 (numbers within that range with a “+ ” sign bit)
is the same as the logical representation. 231 − 1 is the largest integer that can be represented using
31 bits; the remaining (32nd) digit at the left end is zero, the sign digit.

Chapter I: Getting Started 25

 Now, consider negative numbers. The two's complement representation of a negative integer Y
satisfying the inequalities
−231 ≤ Y ≤ −1 (numbers within that range with a “− ” sign bit)
is simply 232 + Y. The bit pattern representing this value can be found this way. The leftmost bit
is set to 1 to indicate that the number is negative, and the remaining 31 bits are set to the binary
representation of the nonnegative integer (231+Y). The result therefore satisfies the inequalities
0 ≤ 231+Y ≤ 231−1.
The reasons for representing negative numbers this way are not obvious, but we will see that it
leads to very simple rules for performing arithmetic on signed binary numbers.

In effect, we have done the following: if Y is positive, we find its value by adding the individual
terms (bi×2i); because the leftmost (sign) bit is zero, it does not contribute to the sum. If Y is
negative, the sum of the rightmost 31 bits is (231+Y), and the leftmost bit is 1. Now, if we assign
value − 231 to the sign bit, we can combine these to obtain
Y = (−231)×b31 + b30×230 + ... + b2×22 + b1×21 + b0×20,
where the digits b30 through b 0 are the representation of 231+Y, not the representation of |Y|,
the absolute value of Y. This formula is almost the same as that used for the logical represen-
tation, except that the leftmost bit has negative “weight”. (There are good reasons to assign − 231
to the sign bit.)

Finally, we will see how the representations of positive and negative numbers work together. The
relationship between the logical and two's complement representations is seen by examining the
above sum for the logical representation of X:
Xlogical = b31×231 + b30×230 + ... + b2×22 + b1×21 + b0×20.

If b31 is zero, the logical and two's complement representations yield the same value, and
Yarith = X logical. Now, suppose we are given the 32-bit two's complement representation of a
negative number Y arith , and we want to know the value those 32 bits would represent if we con-
sider them as the logical representation of a number X logical. Since bit b31 is 1, indicating a nega-
tive number, and we represent the remaining 31 bits of Yarith by (Yarith + 231), we find that
Xlogical = 231 + (Yarith + 231) = (Yarith + 232) (modulo 232).

This is interesting: because we can only represent numbers less than 232 in the 32-bit logical repre-
sentation, Y arith + 232 for nonnegative Y must have the same bit pattern as X logical, since the extra
(232) bit is lost. Thus, for
0 ≤ Xlogical ≤ 232−1 and −231 ≤ Yarith ≤ 231−1,
we have the following key relation between the logical and two's complement representations:
Xlogical = (Yarith + 232) (modulo 232).
That is, the bit pattern corresponding to the two's complement representation of any positive or neg-
ative number − 231 ≤ Y ≤ + 231 − 1 is the rightmost 32 bits of the sum 232 + Y (modulo 2 32).

Why it is called “two's” complement?

This equation is the original source of the term “two's complement”. In
the earliest computers it was customary to treat binary numbers as frac-
tions: the representation was the same as just described, except that the
“binary point” or “radix point” was assumed to lie just to the right of the
sign bit rather than at the right-hand end of the number, so that values
were in the range − 1 ≤ value < + 1. The equation giving the relation-
ship between logical and arithmetic representations was then written
X = Y + 2 (modulo 2),
so that the representation of a negative number was obtained by finding
its complement with respect to 2: its “two's” complement.

26 Assembler Language Programming for IBM System z™ Servers Version 2.00

 Calculating the two's complement representation of a negative number is very cumbersome if we
follow the above steps for any negative number Y: we would first have to calculate the binary
representation of the positive quantity 231+ Y . But calculating (231 − 1+Y)+1 instead is very
simple, because the representation of 231 − 1 is exactly 31 one-bits. Now, because Y is negative,
231−1 + Y = (231−1) − |Y|.
Thus |Y|, the magnitude of Y, is subtracted from a string of 31 one-bits. But wherever |Y| has a
one bit, the resulting difference bit will be zero, and vice versa. Thus, there is no need to subtract!
Just change each of the 31 bits of |Y| to its opposite (namely the result of subtracting it from 1),
and we have the value of 231 − 1 − |Y|. This result is called the “ones' complement” of |Y|. Finally,
we add 1 to the rightmost bit position to get 231+Y, set the leftmost bit (the sign bit) to 1, and
we are done.
If Yarith was nonnegative, complementing all 32 bits automatically sets a 1-bit in the sign; and if
Yarith was negative, complementing all 32 bits sets the sign to zero. So, we don't have to do
anything special with the sign bit!
This simple method lets us find the binary representation (in the two's complement represen-
tation) of a negative number, as we will see in the next section.

Exercises
2.7.1.(3) Convert X'AB0DE' to base 15, using hexadecimal arithmetic throughout.

2.7.2.(3) We saw that the radix-complement representation of a number Y in radix r with n

digits is
rn+Y (modulo rn)
Suppose r=10 and n=4. Show the ten's-complement representation of the following values,
and indicate which are and are not validly representable.
(1) + 729, (2) − 729, (3) − 1, (4) + 9999, (5) − 5000, (6) + 5000, (7) − 9999.

2.7.3.(2) What is the decimal value of the 12-bit binary number 100000000001 in a signed two's
complement representation?

2.7.4.(3) Based on your results of Exercise 2.7.3, give an expression for the value of the n-bit
binary number 10000...000001 in a signed two's complement representation.

2.7.5.(3) + Knowing the logical representation of the three numbers in Exercise 2.6.1, convert
them to their signed decimal representation.

2.8. Computing Two's Complements

A simple scheme for computing two's complements is based on the observation that the represen-
tation of a negative number Y is simply 232 − |Y|.

Two's-Complementation Recipe
Given a binary number Y, to find the two's complement representation
of − Y:
1. Take the ones' complement of all bits of Y: change 0 digits to 1,
and 1 digits to 0.
2. Add 1 in the low-order (rightmost) position, and ignore carries out
of the leftmost position.

These two examples do the arithmetic with eight binary digits rather than thirty-two.
1. Find the two's complement representation of − 2.

Chapter I: Getting Started 27

 (1) representation of +2: 0000 0010
(2) form ones' complement: 1111 1101
(3) add one: + 1
1111 1110
2. Find the two's complement representation of − 75.
(1) representation of +75: 0100 1011
(2) form ones' complement: 1011 0100
(3) add one: + 1
1011 0101
This recipe also works in the opposite direction.
3. Find the two's complement representation of B'11111110' (−2).
(1) form ones' complement: 0000 0001
(2) add one: + 1
0000 0010
This is the binary representation of +2; thus the two's complement of the two's complement of a
number is the original number. So, our recipe for computing complements does not depend on
the sign of the original operand.
Two unusual cases arise during complementation when all the bits except the sign bit are zero:
the complemented result is the same as the original operand.
4. Find the two's complement representation of B'00000000'.
(1) form ones' complement: 1111 1111
(2) add one: + 1
(carry one off left end) 0000 0000
The result is zero, and the carry of a 1 bit out the left-hand end is lost. Thus the negative of zero
is still zero. This is mathematically satisfying: there is no negative zero.16
5. Find the 8-bit two's complement representation of B'10000000'.
(1) form ones' complement: 0111 1111
(2) add one: + 1
1000 0000
In this case, the complement of the number is also the same as the original number. This partic-
ular number, a negative sign bit with all other bits zero, is called the “maximum negative
number”. It is well defined, and behaves normally in all arithmetic operations except that is has
no representable negation.
The maximum negative number has no corresponding positive value available for the represent-
able negative value. We say that we have generated an overflow condition —the result is too large
to fit into the number of bits allotted for it. Overflow will be treated in more detail in the fol-
lowing sections on two's complement arithmetic.
Some examples of numbers in the 32-bit arithmetic representation are shown in Table 4 on
page 29.

16 Some older computers used the ones' complement representation for binary integers, so negative zeros were possible.
System z packed decimal and floating-point numbers (discussed in Chapters VIII and IX) support negative zeros.

28 Assembler Language Programming for IBM System z™ Servers Version 2.00

 32-bit Two's
Decimal Value Complement
Representation
0 X'00000000'
1 X'00000001'
256 X'00000100'
5000 X'00001388'
+ 2147483647 ( + 231 − 1) X'7FFFFFFF'
− 2147483648 ( − 231) X'80000000'
− 2147483647 ( − 231+ 1 ) X'80000001'
− 5000 X'FFFFEC78'
− 256 X'FFFFFF00'
−2 X'FFFFFFFE'
−1 X'FFFFFFFF'
Table 4. Examples of two's complement representation

The number of values with positive sign is the same as the number of values with negative sign,
since every bit may be chosen arbitrarily. Because zero has a positive sign bit, it is sometimes
treated as a positive number, even though (mathematically) it has no sign. If we exclude zero as a
positive number, then there is one fewer member of the set of positive values than of the set of
negative values, since there is no representation for +231. With 32 bits, we can represent 232
values: between − 1 and − 231 there are 231 values; 0 is a single value; between +1 and +2 31 − 1
there are 231 − 1 values. The total number of possible signed values is therefore 231+ 1 + ( 2 31 − 1),
or 232 .
Unfortunately, the terminology used to describe this process can be confusing. We are actually
describing the mathematical operation of negation that turns a value into its negative. For other
number representations, the operation that forms the negative of a number will be different,
because there are many ways to represent a negative number. However, sometimes
complementation is used to describe the operation of negation! For example, we often talk about
the binary representation of some number, and then say that in negating that quantity we have
formed its two's complement.

Exercises
2.8.1.(1) Why does the simple two-step prescription for computing complements given above
not depend on the sign of the number being complemented?

2.8.2.(2) + Give the decimal values represented by each of the following 16-bit numbers,
assuming that the binary values are in two's complement representation:

1. X'0257'
2. X'7FFA'
3. X'8008'
4. X'E000'
5. X'FFFA'

(See Exercise 2.3.4. also.)

2.8.3.(2) It is sometimes said that the complement of a number X is the same as − X. State this
more precisely.

2.8.4.(2) Four 16-bit areas of a program are named A, B, C, and D. Their contents are
c(A) = X'7D40'
c(B) = X'D000'
c(C) = X'15A2'
c(D) = X'800A'
If they are the signed 16-bit two's complement binary representations of four decimal numbers,
determine their decimal values.

Chapter I: Getting Started 29

 2.8.5.(2) Given the quantities Z = 0, A = 1, B = 9, C = 62, D = 101, E = 255, F = 256,
give the nine-bit (eight bits plus sign) representations of the positive and negative values of each
quantity in the two's complement representation.

2.8.6.(3) Give the 32-bit two's complement representation (in either hexadecimal or binary) of
both the positive and negative values of the following decimal integers: (1) 10, (2) 729, (3)
1000000, (4) 1000000000, (5) 2147483648, (6) 65535, (7) 2147483647.

2.8.7.(3) Sometimes two's complementation is described by these steps:

• Subtract 1
• Complement all bits

Does this differ from the two's complementation recipe given on page 27? Create examples that
show how this form does or does not differ from that recipe.

2.8.8.(1) Give the 16-bit two's complement binary representation of each decimal number in
hexadecimal.

1. + 13055
2. − 9582

2.8.9.(2) + Show the 32-bit hexadecimal value of the two's complement binary representation of
each of the following decimal values.

1. +5
2. − 97
3. + 65795
4. − 16777158
5. + 16777219
6. − 78606

2.8.10.(1) + Assuming a 16-bit two's complement representation, give the signed decimal values
of these hexadecimal values.

1. X'B00F'
2. X'FFF1'
3. X'0FFF'
4. X'F001'

2.9. Sign Extension

In the representation of nonnegative numbers, an arbitrary number of zero bits may be attached
to the left end of a number without affecting its value. For example, the 8-bit and 16-bit repres-
entations of +9 are
B'0000 1001' and B'0000 0000 0000 1001'
respectively. Similarly for negative numbers, we can add any number of 1 bits at the left without
affecting the value. For example, the 8-bit and 16-bit two's complement representations of − 9 are
B'1111 0111' and B'1111 1111 1111 0111'
respectively. Thus, for numbers that can be represented correctly in a given number of bits, the
correct representation using a larger number of bits is found by duplicating the sign bit toward the
left as many places as desired. This is called sign extension, and is illustrated in the following:

30 Assembler Language Programming for IBM System z™ Servers Version 2.00

 Length Representation of +1 Representation of − 1
8 bits X'01' X'FF'
16 bits X'0001' X'FFFF'
32 bits X'00000001' X'FFFFFFFF'
64 bits X'0000000000000001' X'FFFFFFFFFFFFFFFF'
Table 5. Examples of sign extension

We will discuss sign extension again when we examine instructions that perform shifting, and
instructions that perform arithmetic on operands of different lengths.

Exercises
2.9.1.(2) Provide the 32-bit sign extensions in binary and hexadecimal notation of the five items
in Exercise 2.8.2.

2.10. Binary Addition

Though number-representation details may vary slightly from one processor to another, the
methods for performing binary arithmetic remain nearly the same for all processors. Thus the fol-
lowing is slightly more general than if only System z is discussed. The rules for adding binary
digits are:

0 0 1 1
+0 +1 +0 +1
0 1 1 10 (carry)

Adding numbers in the logical representation is simplest, because all the bits are numeric digits
and do not represent signs. The only unusual condition is whether or not a carry occurs out of
the leftmost digit position, which would indicate whether the resulting sum is or is not correctly
representable by the number of bits available.

In the two's complement representation, addition is performed in the same way, but the result is
interpreted somewhat differently.
1. All bits of each operand are added, including sign bits, and carries out the left end of the sum
are lost. (This is the same as for adding numbers in the logical representation.)
2. If the result cannot be correctly represented using the number of digits available, a fixed-point
overflow condition occurs. The actions taken when an overflow condition occurs will vary;
sometimes it can be ignored.

Using signed 4-bit binary values, we know that valid values must lie in the range
− 8 ≤ value ≤ + 7. we first add B'0010' ( + 2) to itself, and then we add B'0100' ( + 4) to itself.
0010 0100
+0010 +0100
0100 (no overflow) 1000 (overflow)
In the first case, 2 + 2=4, which lies in the representable range for our 4-bit numbers. But in the
second case, 4 + 4 = − 8, because + 8 is not representable. That is, the sum has overflowed.

A fixed-point overflow condition is possible only when adding operands of like sign: adding
numbers with opposite signs always produces a representable result (or, as is often said, the result
is in range). When an overflow occurs, the sign of the result is always the opposite of the sign of
the two operands. The actual method used to detect overflow is simpler, since sign-change
detection would require remembering the signs of both operands for comparison against the sign
of the sum. Here is how it's done:

Overflow Detection Recipe

If the carries into and out of the sign bit position disagree, arithmetic
overflow has occurred.

Chapter I: Getting Started 31

 There are two kinds of binary addition: arithmetic and logical. They produce identical bit pat-
terns, as we will see in Section 2.14. Overflow is detected only for arithmetic addition, while
logical addition is concerned only with a possible carry out of the high-order bit position.

Exercises
2.10.1.(2) + Consider adding the 8-bit binary number X'F5' to itself. There is no carry from
X'5'+ X'5'=X'A', but there is a carry from X'F'+ X'F'=X'1E'. Since the carry out of the low-
order digit position is different from the carry out of the high-order digit position, has overflow
occurred?

2.11. Binary Subtraction

Subtraction is performed by adding the two's complement of the number to be subtracted, the
second operand. That is, A − B is calculated as A + ( − B), where ( − B) is the two's complement of
B. A few examples using 8-bit binary two's complement arithmetic will help illustrate addition
and subtraction.

While this prescription is essentially correct, there is a minor but important complication we'll
examine after illustrating the basic scheme. (In Examples 6 and 7, note that the carries into and
out of the high-order bit are different.)

• Example 1.
5-3: 0000 0101
-0000 0011
becomes
0000 0101
+1111 1101
(carry lost) 0000 0010 = 2
• Example 2.
3-5: 0000 0011
-0000 0101
becomes
0000 0011
+1111 1011
(no carry) 1111 1110 = -2
• Example 3.
25-(-17): 0001 1001
-1110 1111
becomes
0001 1001
+0001 0001
(no carry) 0010 1010 = 42
• Example 4.
(-17)-25: 1110 1111
-0001 1001
becomes
1110 1111
+1110 0111
(carry lost) 1101 0110 = -42

32 Assembler Language Programming for IBM System z™ Servers Version 2.00

• Example 5.
-17-(-25): 1110 1111
-1110 0111
becomes
1110 1111
+0001 1001
(carry lost) 0000 1000 = 8
• Example 6.
67-(-93): 0100 0011
-1010 0011
becomes
0100 0011
+0101 1101
(no carry) 1010 0000 = -96 (overflow)
• Example 7.
(-93)-67: 1010 0011
-0100 0011
becomes
1010 0011
+1011 1101
(carry lost) 0110 0000 = 96 (overflow)
• Example 8.
-128-(-93): 1000 0000
-1010 0011
becomes
1000 0000
+0101 1101
(no carry) 1101 1101 = -35
• Example 9.
3-3: 0000 0011
-0000 0011
becomes
0000 0011
+1111 1101
(carry lost) 0000 0000 = 0
The above examples illustrate addition and subtraction and give the expected results. However,
there is one case where the method as given above fails to detect correctly the presence or absence
of overflow, and this occurs when the maximum negative number is being subtracted from some-
thing. (This is the minor complication mentioned previously.)
• Example 10.
1-(-128): 0000 0001
-1000 0000
becomes
0000 0001
+1000 0000
(no carry) 1000 0001 = -127 (no overflow found?)
• Example 11.
-1-(-128): 1111 1111
-1000 0000
becomes
1111 1111
+1000 0000
(carry lost) 0111 1111 = +127 (overflow indicated?)

Chapter I: Getting Started 33

 In each of these two last cases, the result seems to be arithmetically correct, but our original over-
flow indication is incorrect. This is because taking the two's complement of the maximum nega-
tive number before adding it has already generated an overflow condition. To see how the
processor can still use our overflow detection scheme as originally described (the carries into and
out of the leftmost bit differ), it is worth examining the actual addition process in slightly more
detail. The next section may be omitted if you are uninterested in such details, but be sure to
learn the “Binary Subtraction Recipe” on page 35.

Exercises
2.11.1.(2) Give the 32-bit integer representation in hexadecimal or binary of the result of the
following operations, where the operands are given as decimal numbers.

1. 10 − ( − 10)
2. 729 − 65535
3. 2147483647 + 2
4. 1000000000 + ( − 2147483647)
5. 0 − ( + 0)
6. ( − 10) + 10

Do the arithmetic in the two's complement representation, indicating for each case (1) the pres-
ence or absence of overflow, and (2) the presence or absence of a carry out of the leftmost digit
position.

2.11.2.(2) Assume that the values defined in Exercise 2.8.4 are used to compute three 16-bit
numbers X, Y, and Z. Using 16-bit binary arithmetic, determine the final (hex) contents of the
16-bit fields named X, Y, and Z, and whether or not an overflow condition has occurred.
c(X) = c(A) - c(C)
c(Y) = c(B) + c(D)
c(Z) = c(A) + c(D)

2.11.3.(3) Suppose you want to subtract 1 from a binary number. A suggested technique uses
these two steps: (1) change all the rightmost zeros to ones, and (2) change the previous right-
most one to zero. Create examples to show that this technique is or is not correct.

2.11.4.(4) Assume that the method in Exercise 2.11.3 is correct. How can you detect overflow
conditions?

2.11.5.(2) Evaluate each of the following 32-bit sums and differences, and in each case deter-
mine (a) whether an arithmetic overflow occurs, and (b) whether there is a carry out of the
leftmost bit.

1. X'7D26F071'+X'B40E99A4'
2. X'7D26F071'-X'B40E99A4'
3. X'FFFFF39A'+X'FFFE4B06'
4. X'FFFFF39A'-X'FFFE4B06'
5. X'80000003'+X'0000007C'
6. X'80000003'+X'8000007C'

2.12. How Additions and Subtractions Are Actually Performed (*)

Remember that the two's complement of a number (the two's complement representation of the
negation of a number) is found by inverting each bit of the number and then adding a one in the
low-order position. Digital circuits that invert bits are called NOT circuits. Similarly, adding a 1
bit to the low-order digit position is also easy, because each digit position of an adder circuit must
add the corresponding bits of the two input operands A and B, and the carry bit from the next
lower-order bit position, as illustrated in figure 2. as illustrated in Figure 2 on page 35.

34 Assembler Language Programming for IBM System z™ Servers Version 2.00

 ┌─────────┐
│Bit n of │
│Operand A│
└─┬───────┘
┌────────────┐ ┌────────┐ │┌────────────┐
│ Carry bit │ │ Adder │───┘│ Carry bit │
│ to Adder │──┤Position│────┤from Adder │
│Position n+1│ │ n │───┐│Position n-1│
└────────────┘ └──┬─────┘ │└────────────┘
┌─────────┐ │ ┌┴────────┐
│Bit n of │ │ │Bit n of │
│ sum A+B │──┘ │Operand B│
└─────────┘ └─────────┘
Figure 2. One stage of a binary adder

In the lowest-order position of the adder there will be no carry from a lower-order bit position.
However, if an identical adder circuit is used, it still has a carry input that can be used to insert
the 1 bit to be added to the low-order position during a complementation or subtraction opera-
tion! Thus subtraction is simply a matter of passing the second operand through a bit inverter
(forming the ones' complement), and then activating the low-order carry input to the adder to add
the required one-bit.

Binary Subtraction Recipe

Subtraction is performed by adding the ones' complement of the second
operand and a low-order one-bit to the first operand, in a single opera-
tion. The subtraction in Example 10 is evaluated this way:
1-(-128): 0000 0001 first operand
-1000 0000 second operand
becomes
0000 0001 first operand
0111 1111 ones' complement of second operand
+ 1 complementation bit
(0)1000 0001 (overflow!)

An overflow is indicated because carries into (1) and out of the high-order bit (0) are different.

Exercises
2.12.1.(2) For each of the quantities defined in Exercise 2.8.5 on page 30, compute the fol-
lowing nine-bit values, indicating for each case whether or not there is a carry out of the high-
order digit position, and whether or not an overflow has occurred. (Some of the values may not
be representable; state which.) (1) A + C; (2) D − E; (3) Z + ( − F); (4) ( − E) − C; (5) ( − B) + A; (6)
C − Z; (7) A + ( − A).

2.12.2.(3) In the ones' complement representation, subtraction is sometimes described this way:

• Take the ones' complement of the subtrahend (the number to be subtracted), and add the
operands. Cross off the high-order digit and add 1 to the sum.
• If the subtrahend is greater than the minuend (the number from which the subtrahend is
subtracted), take the ones' complement of the subtrahend, add the operands, then comple-
ment the result and put a minus sign in the high-order position.

Construct some examples showing how this process works, for operands of both signs and of
various magnitudes.

Chapter I: Getting Started 35

2.13. A Circular View of Binary Arithmetic (*)
We'll use a four-bit binary representation to illustrate some concepts we have been discussing.
The “circular” diagram in Figure 3 contains all 16 possible four-bit numbers.

│
o 0100
0101 o │ o 0011
│
0110 o │ o 0010
│
│
0111 o │ o 0001
│
x overflow point │
│ 0000
─────•──────────────────────┼──────────────────────o────
1000 │
│ carry point x
│
1001 • │ • 1111
│
│
1010 • │ • 1110
│
1011 • │ • 1101
• 1100
│
Figure 3. “Circular” representation of two's complement representation

First, suppose the numbers are considered to be the logical representation of the integers from 0
to 15. Counting up from 0000 by one takes us around the circle counter-clockwise from 0000 to
1111 and then back to 0000, as we would expect for numbers modulo 2 4. Adding and subtracting
two numbers can be thought of as adding and subtracting the angles (measured counter-clockwise
from 0000) represented by the numbers. Thus,
0100 + 0110 = 1010, and 1100 + 0111 = 0011.

A carry condition occurs in addition if we go past the “carry point” in the counter-clockwise
direction; similarly, a “borrow” condition occurs in subtraction if we go past the “carry point” in
the clockwise direction.

For the two's complement representation, the negative of a number is the one vertically opposite
it across the horizontal axis. Thus, the negative of 0011 is 1101, and the negative of 0001 is 1111.
We also see that the numbers 0000 and 1000 are their own negatives, just as we found in exam-
ples 4 and 5 of Section 2.8 above.

Now, consider the numbers to be the signed 4-bit two's complement representation of the integers
from − 8 to +7. In the figure, the numbers with a zero sign bit are represented by open circles (o),
and the numbers with a sign bit = 1 are represented by the solid black dots (•). As before, we
can visualize adding and subtracting numbers by adding or subtracting the corresponding angles
represented by the numbers. Now, however, we can detect overflow conditions as well: if in
adding or subtracting we move in either direction past the “overflow point” between 1000 and
0111, an overflow condition occurs. Thus if we add
0110 + 0011 = 1001
we generate an overflow by passing the overflow point in a counter-clockwise direction. Similarly,
in the subtraction
1010 - 0110 = 0100
we generate an overflow by passing the overflow point in a clockwise direction.

36 Assembler Language Programming for IBM System z™ Servers Version 2.00

 Experiment with this diagram; it reveals many properties of two's complement arithmetic.

Exercises
2.13.1.(3) + In many early editions of the System/360 Principles of Operation, the Subtract oper-
ation was described as follows: “Subtraction is performed by adding the two's complement of
the second operand to the first operand. All 32 bits of both operands participate. If the carries
out of the sign-bit position and the high-order numeric bit position agree, the difference is satis-
factory; if they disagree, an overflow occurs.”
This differs from the subtraction rule given in Section 2.13. Construct one or more examples
that will show that these two descriptions are not precisely equivalent.

2.14. Logical (Unsigned) and Arithmetic (Signed) Results (*)

We can show that the correct algebraic result is obtained by simply adding all the bits of the
operands in the two's complement representation as though they were logical operands. For
32-bit operands, the logical representation X corresponding to an arithmetic signed integer x satis-
fies the relation
X = 232 + x (modulo 232),
then the sum of two logical operands X and Y is
(X + Y) = 232 + 232 + (x + y) (modulo 232)
= 232 + (x + y) (modulo 232)
= x + y

Thus the arithmetic and logical sums give the same binary result; the leftmost bits and the high-
order two carry bits are just interpreted differently in the two representations.

Logical vs. arithmetic

Logical and arithmetic sums and differences of binary integers produce
identical bit patterns.

We can make a further observation about adding and subtracting numbers in the logical represen-
tation. From the examples in Section 2.11, we see that in subtraction, if the second operand is
logically smaller than or equal to the first (see examples 1, 4, 5, 7, 9, and 11) then there will be a
carry out of the leftmost bit position. Conversely, we see (in examples 2, 3, 6, 8, and 10) that if
the first operand is logically smaller than the second operand subtracted from it, there is no carry
out of the left end. In these latter cases we have in some sense generated a “negative” logical
answer, since the result is not correctly represented to the given number of bits. We'll see exam-
ples of these cases when we examine instructions that perform logical arithmetic.

Exercises
2.14.1.(2) Assuming an eleven-bit word, give the logical and two's complement representations
of the following quantities: (1) 200, (2) 1023, (3) − 1000, (4) 2047, (5) − 1, (6) − 1024, (7)
− 1023, (8) 1024, (9) − 0. If a quantity is not representable, indicate that it is not.

2.14.2.(2) + Consider the four five-bit binary numbers

A=11111, B=00010, C=10000, D=01111.
For each pair of values (like A+A, A+B, etc.) determine (a) their sum, (b) whether or not a
carry occurs, and (c) for arithmetic addition, whether or not an overflow occurs. Display the
results in a short table. (Because addition is commutative: — X+Y = Y+X — you will need to
evaluate only ten sums.)

2.14.3.(3) + Using the same values for A,B,C,D in Exercise 2.14.2, determine the result, the carry
condition, and the arithmetic overflow condition for pair-wise subtraction (like A-B, B-A, etc.)

Chapter I: Getting Started 37

 of these values. Display your results in a short table; this time your table will need all 16
entries, because subtraction is non-commutative: X − Y ≠ Y − X.

2.14.4.(2) + Can an overflow be caused by subtracting two numbers of opposite signs?

2.15. Examples of Representations (*)

It may help to see the differences among the sign-magnitude, radix complement (two's comple-
ment), and diminished radix-complement (ones' complement) representations. 17 All 5-bit binary
numbers with positive and negative values would be represented as shown in the following table.

Binary Logical Sign- Ones' Two's

Digits Representation Magnitude Complement Complement
00000 0 +0 +0 0
00001 1 +1 +1 +1
00010 2 +2 +2 +2
00011 3 +3 +3 +3
00100 4 +4 +4 +4
00101 5 +5 +5 +5
00110 6 +6 +6 +6
00111 7 +7 +7 +7
01000 8 +8 +8 +8
01001 9 +9 +9 +9
01010 10 + 10 + 10 + 10
01011 11 + 11 + 11 + 11
01100 12 + 12 + 12 + 12
01101 13 + 13 + 13 + 13
01110 14 + 14 + 14 + 14
01111 15 + 15 + 15 + 15
10000 16 −0 − 15 − 16
10001 17 −1 − 14 − 15
10010 18 −2 − 13 − 14
10011 19 −3 − 12 − 13
10100 20 −4 − 11 − 12
10101 21 −5 − 10 − 11
10110 22 −6 −9 − 10
10111 23 −7 −8 −9
11000 24 −8 −7 −8
11001 25 −9 −6 −7
11010 26 − 10 −5 −6
11011 27 − 11 −4 −5
11100 28 − 12 −3 −4
11101 29 − 13 −2 −3
11110 30 − 14 −1 −2
11111 31 − 15 −0 −1

In the sign-magnitude and ones' (diminished radix) complement representations, there are two
distinct representations for zero. In the two's (radix complement) representation, there is no rep-
resentation for +16 corresponding to the valid representation for − 16.
The sign bit in the sign-magnitude representation is attached to the (unsigned) magnitude of the
value. However, the “sign bit” in the two's complement representation is not just an indicator: it
is numerically significant.
Representing signed numbers in a computer always involves tradeoffs: how should “peculiar”
cases like these be handled?

17 More formally, the representation in radix r of an n-bit negative number X is r n − X in the two's complement repre-
sentation, and (r n − 1) − X in the ones' complement representation.

38 Assembler Language Programming for IBM System z™ Servers Version 2.00

Exercises
2.15.1.(2) Suppose your computer uses the ten's complement representation for integers. (This
representation was very widely used in mechanical desk calculators, and in many early com-
puters.) Write the following values in ten's-complement notation: (1) + 28, (2) − 49, (3) + 527,
(4) − 333, (5) − 1234, (6) + 2469.

2.15.2.(3) Using the representations you calculated in Exercise 2.15.1, evaluate the following
using ten's complement arithmetic: (a) + 28 + ( − 49), (b) + 527 + ( − 333), (c) − 1234 + 2469.

2.15.3.(3) Write the values in Exercise 2.15.1 in the diminished radix-complement (nines' com-
plement) representation.

Terms and Definitions

arithmetic representation
A signed number representation.
bit
A binary digit, taking values 0 and 1.
diminished radix-complement representation
A signed representation where negative numbers are represented by subtracting each digit
from (the radix minus 1).
hex
See hexadecimal.
hexadecimal
A base-16 representation. Its digits are 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F.
logical representation
An unsigned number representation.
ones' complement representation
A signed binary representation where negative numbers are represented by changing each 0
bit to a 1 bit and vice versa.
overflow
The sum, difference, product, or quotient of two numbers is too large to be correctly repres-
ented in the number of digits provided.
radix-complement representation
A signed representation where the numerically significant high-order digit contains sign infor-
mation.
sign-magnitude representation
The familiar signed representation of numbers with prefixed + or − signs.
two's complement representation
A signed binary representation where the high-order bit contains sign information, and has
weight − 2 n − 1.

Chapter I: Getting Started 39

40 Assembler Language Programming for IBM System z™ Servers Version 2.00
Chapter II: System z

IIIIIIIIII IIIIIIIIII
IIIIIIIIII IIIIIIIIII
II II
II II
II II
II II
II II
II II
II II
II II
IIIIIIIIII IIIIIIIIII
IIIIIIIIII IIIIIIIIII

This chapter's three sections introduce the main features of System z processors:
• Section 3 describes basic structures: memory organization and addressing, general purpose reg-
isters, the Program Status Word (PSW), and other topics.
• Section 4 discusses the instruction cycle, basic machine instruction types and lengths,
exceptions and interruptions and their effects on the instruction cycle.
• Section 5 covers address calculation, the “addressing halfword”, Effective Addresses, indexing,
addressing problems, and virtual memory.

Chapter II: System z 41

3. Conceptual Structure of System z

3333333333
333333333333
33 33
33
33
3333
3333
33
33
33 33
333333333333
3333333333

We can describe the structure of most computers in terms of four functional units: memory, arith-
metic, control, and input-output. A real computer may not identify components this way, but it
helps us to think of them as distinct units.

┌──────────┐ Control ┌─────────┐ Control ┌────────────┐

│Arithmetic│─ ─ ─ ─ ─ ─ ─ ─│ Control │─ ─ ─ ─ ─ ─ ─ ─│Input─output│
│ Unit │ │ Unit │ │ Unit │
└─────┬────┘ └────┬────┘ └─────┬──────┘
  
│Data │Data │Data
  
┌─────┴───────────────────────────┴────────────────────────────┴──────┐
│ │
│ Memory │
│ │
└─────────────────────────────────────────────────────────────────────┘
Figure 4. Conceptual structure of a typical computer

The solid lines in Figure 4 represent data paths among the various units, and the dashed lines
indicate the flow of control signals. As indicated, the same memory holds instructions for the
control unit and the data used by the arithmetic and input-output units. This gives modern digital
processors their flexibility and power: they can treat instructions as data or data as instructions.

System z makes no special distinction between the arithmetic and control units, and the combina-
tion is often called the “Central Processing Unit”, or “CPU”.

42 Assembler Language Programming for IBM System z™ Servers Version 2.00

 ┌──────────────────────────────┐ Control ┌──────────────┐
│ Central Processing │─ ─ ─ ─ ─ ─ ─ ─│ Input─output │
│ Unit │ │ Unit │
└──────────────┬───────────────┘ └──────┬───────┘
 
│Data │Data
 
┌──────────────┴────────────────────────────────────────┴───────┐
│ │
│ Memory │
│ │
└───────────────────────────────────────────────────────────────┘
Figure 5. Conceptual structure of System z

“Memory” is sometimes called “central storage” or similar terms. It refers to that part of the
processor holding the directly accessible instructions and data to be manipulated by those
instructions.

As Figure 5 indicates, input and output — once initiated by the CPU — is performed between
external devices and memory, and does not pass through the CPU. The Input-output Unit com-
municates the status of its operations to the CPU, indicating error conditions or completion of
the operation.

3.1. Memory Organization

Digital computers deal with data consisting of binary digits, easily and rapidly accessed from
“central memory”. The basic data item is an eight-bit group called a byte.18 The bits in a byte are
numbered from 0 to 7, beginning on the left with the numerically most significant digit. (The
importance of designating the “left” side of a byte will be clearer when we consider groups of
bytes.) In Figure 6, the leftmost bit is a 1-bit, and the rightmost bit is a 0-bit.

─8 bits─
┌──────────┐
│ 11010010 │
└──────────┘
0 7
Figure 6. A byte containing 8 binary digits

Bytes in memory are arranged so that each byte may be referenced as easily as any other. The
bytes are individually numbered beginning at zero; the number associated with each byte is called
its memory address. Memory may be thought of as a linear string of bits; the bits are grouped
into bytes arranged in order of increasing addresses. Only bytes have addresses; bits within a byte
don't have their own addresses.

.. 701 702 703 704 705 706 707 ..

─ ─┬──────┬──────┬──────┬──────┬──────┬──────┬──────┬─ ─
│ byte │ byte │ byte │ byte │ byte │ byte │ byte │
─ ─┴──────┴──────┴──────┴──────┴──────┴──────┴──────┴─ ─

Figure 7. A portion of memory, with addresses shown above each byte

The bits in a byte are accessed (or “read”) by the CPU without being changed. Reading the con-
tents of a byte does not affect the contents; the memory provides the CPU with a copy of the

18 Because the eight bits in a byte are often described using two hex digits, some people like to call a “half byte” hex
digit a cute name like “nibble” or even “nybble”. We won't.

Chapter II: System z 43

 contents of a byte. Storing (or “writing”) a new bit pattern into a byte replaces the previous con-
tents.

Many machine instructions referring to memory actually refer to a group of consecutive bytes. In
such situations the group is normally addressed by referring to its leftmost member, the byte with
the lowest address in the group.19 Also, some instructions require the address of a group of bytes
(the address of the leftmost byte) to also be a multiple of the length of the group, in which case
we say that the group is aligned.20 The possible lengths for such groups of bytes are 2, 4, 8, or 16;
we sometimes refer to them as halfwords, words (or fullwords), doublewords, and quadwords
respectively.
8DF 8E0 8E1 8E2 8E3 8E4 8E5 8E6 8E7 8E8 8E9 8EA 8EB 8EC 8ED 8EE 8EF 8F0
─┬─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┬─
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │
─┴─────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┴─
│ halfword │ halfword │ halfword │ halfword │ halfword │ halfword │ halfword │ halfword │
│────────word─────────│────────word─────────│────────word─────────│────────word─────────│
│─────────────────doubleword──────────────────│─────────────────doubleword──────────────────│
│──────────────────────────────────────────quadword───────────────────────────────────────────│
Figure 8. A portion of memory

When some operation manipulates a group of bytes, we call that group an “operand”: something
that is “operated on”. The group always consists of data from consecutively-addressed bytes in
memory.

Some operations treat the operand as a string of bits whose meaning for that operation is inde-
pendent of the fact that they are arranged into 8-bit bytes in memory. For example, suppose a
halfword operand (a group of two bytes whose address is divisible by 2) is specified for an opera-
tion, and the address of the 16-bit operand is X'8EA'. Then the 16 bits in the bytes at X'8EA' and
X'8EB' will be treated as a single 16-bit halfword, and we ignore the fact that they are stored in
memory as two distinct eight-bit bytes. Thus, bit 0 of the halfword operand — its leftmost bit —
corresponds to bit 0 of the byte at X'8EA', and bit 15 of the halfword operand — its rightmost bit
— corresponds to bit 7 of the byte at X'8EB'.21

Bytes in memory contain only bit patterns. Whether the bit pattern is interpreted as an instruc-
tion, or as one of many types of data, depends only on the context of its use; at one time it may
be data, and at another, an instruction. Whatever the interpretation, however, a byte is simply a
group of eight bits.

We now see why we use hexadecimal (base 16) notation for expressing binary numbers instead of
octal (base 8) notation. It is simplest to arrange bits in groups of the same size, and the presence
of eight bits in a byte makes four-bit groups natural. A half-byte contains 4 bits, exactly the
number of bits needed to represent one hex digit. If octal notation is used, a byte would contain
two three-bit octal digits and two extra bits.

Exercises
3.1.1.(2) + An area of memory reserved for data begins at address X'2EC9' and ends with address
X'30A6' (including the start and end bytes!). How many bytes are there in the area, and how
many halfwords, words, and doublewords can be stored in the area?

3.1.2.(1) The memory of System z can be thought of as a continuous string of bits. Does each
individual bit in memory have an address? Explain.

19 This is true with few exceptions, which we will note as they appear. For now, remember “leftmost” as the rule.
20 In early System/360 processors, many memory operands had to be aligned on byte boundaries whose addresses were
a multiple of the operand's length. While this is no longer required for most (but not all) instructions, proper align-
ment is always a good programming practice.
21 z/Architecture processors use what is called “big-endian” addressing; we'll examine “endianness” in detail in Chapter
VII, Section 26.7.

44 Assembler Language Programming for IBM System z™ Servers Version 2.00

 3.1.3.(2) Suppose we are interested in the string of contiguous bits starting with bit 5 of
memory address X'1A023' and ending with bit 1 of the byte at memory address X'1A03B'
(including the start and end bits). Determine the number of bits in the string.

3.1.4.(1) State which of the following addresses refer to halfwords, words, and doublewords:
(1) X'123456'; (2) X'234567'; (3) X'345678'; (4) X'000BBC'.

3.1.5.(1) Determine the number of bits that can be stored in a memory area of the following
sizes: (1) X'20000' bytes, (2) X'8000' bytes, (3) X'200000' bytes.

3.1.6.(1) Express the contents of the byte in Figure 6 on page 43 in octal notation and in
hexadecimal notation.

3.1.7.(1) + If you examine the rightmost hex digit of a memory address, what can you tell about
the alignment of the address?

3.2. Central Processing Unit

The CPU performs the operations specified by your program. An important element of the CPU
is a set of registers, a special and very fast form of memory kept very close to the instruction and
data processing functions of the CPU.
• The general registers are used for arithmetic and logical operations, and to hold addresses of
data and instructions; 22
• the Floating-Point Registers are used for floating-point arithmetic and data;
• the Program Status Word is used by the CPU to control the progress of your program as it is
executed.

3.3. General Registers

There are sixteen general registers, numbered from zero to fifteen. Each is 64 bits (or 16 hex
digits or 8 bytes) long. They are represented schematically in Figures 9 and 10.

───────────────────────────── 64 bits ─────────────────────────────

─────────── 32 bits ──────────── ─────────── 32 bits ────────────
┌─────────────────────────────────┬─────────────────────────────────┐
│ │ │
└─────────────────────────────────┴─────────────────────────────────┘
0 31 32 63
Figure 9. A single 64-bit general register

When we discuss instructions that do 32- and 64-bit arithmetic, we'll understand why this picture
shows two 32-bit parts of a 64-bit general register.

22 Because the general registers are used for so many activities, they are sometimes called “General Purpose Registers”.

Chapter II: System z 45

 ┌────────────────────────────────────────────┬────────────────────────────────────────────┐
│ General Register 0 │ General Register 1 │
├────────────────────────────────────────────┼────────────────────────────────────────────┤
│ General Register 2 │ General Register 3 │
├────────────────────────────────────────────┼────────────────────────────────────────────┤
│ General Register 4 │ General Register 5 │
├────────────────────────────────────────────┼────────────────────────────────────────────┤
│ General Register 6 │ General Register 7 │
├────────────────────────────────────────────┼────────────────────────────────────────────┤
│ General Register 8 │ General Register 9 │
├────────────────────────────────────────────┼────────────────────────────────────────────┤
│ General Register 10 │ General Register 11 │
├────────────────────────────────────────────┼────────────────────────────────────────────┤
│ General Register 12 │ General Register 13 │
├────────────────────────────────────────────┼────────────────────────────────────────────┤
│ General Register 14 │ General Register 15 │
└────────────────────────────────────────────┴────────────────────────────────────────────┘
Figure 10. All sixteen general registers

This figure arranges the registers in pairs, the left register being even-numbered and the right being
the next higher odd-numbered register. Some operations require using a pair of registers, and in
such cases it is always an even-odd-numbered pair.

We will often refer to the general registers using a short notation: we sometimes write “GRn”
(meaning the rightmost 32 bits of a 64-bit register) or “GGn” (meaning all 64 bits) or simply
“Rn” to refer to general register n when the register length is clear from context. Thus, in
Figure 10, we might use R1 to mean register 1, R14 to mean register 14, and so on.

Be Careful!
“R1” (without a subscript) is not the same as the notation “R 1” (with a
subscript). This difference will be important when we discuss machine
instructions.

Exercises
3.3.1.(1) Suppose a shifting operation requires the use of a pair of general registers. Is it possible
to perform the shifting operation using both GR7 and GR8? Using GR15 and GR0? Using
GR6 and GR7?

3.3.2.(1) How many bytes can be placed in a pair of general registers?

3.4. Floating-Point Registers

On the earliest System/360 models only four floating-point registers were available, and then only
as an option. Sixteen are always present in System z processors, as we will see in Section 32.7.
Each is 64 bits (16 hex digits, 8 bytes, or 1 doubleword) long. We will look into this more deeply
when we discuss floating-point instructions and data in Chapter IX.

46 Assembler Language Programming for IBM System z™ Servers Version 2.00

 ───────────────────────── 64 bits ─────────────────────────
┌───────────────────────────────────────────────────────────┐
│ F0 │
├───────────────────────────────────────────────────────────┤
│ F2 │
├───────────────────────────────────────────────────────────┤
│ F4 │
├───────────────────────────────────────────────────────────┤
│ F6 │
└───────────────────────────────────────────────────────────┘
0 63

Figure 11. Four Floating-Point Registers

Sometimes the floating-point registers contain operands 32 bits long. In this case they use only
the left half of the register, and the rightmost 32 bits are ignored. In other situations, a floating-
point instruction using 128-bit operands will use a pair of floating-point registers.

We won't mention the floating-point registers until we discuss instructions for floating-point arith-
metic. We sometimes use the abbreviations “FPRn” or “FRn” or “Fn” to refer to floating-point
registers.

In some cases we use “register” to describe a general register or a floating-point register (or some
other type of register); which is meant will be clear from context.

Exercises
3.4.1.(1) How many short (32-bit) floating-point numbers can be held in a floating-point reg-
ister?

3.4.2.(3) Can you think of any reasons why the designers of System/360 and System z included
a separate set of registers for floating-point arithmetic? That is, why should it not be possible to
use the general registers for binary integer arithmetic, addresses, and floating-point arithmetic?

3.5. Program Status Word (PSW)

Usually, the Program Status Word (PSW) is of no immediate concern, and you need not worry
about its contents. It is another internal register that contains various fields indicating the status of
the program being executed. As the System/360 and System z processors have evolved, the PSW
has taken several forms.

For our purposes, we need to know about only a few parts of a PSW: the Instruction Address
(IA), the Condition Code (CC), the Instruction Length Code (ILC), and the Program Mask
(PM). Of these, the IA is most important now; we'll see more about the others later.

Figure 12 illustrates these four parts of a PSW (and the “System Flags”). The IA is always in the
rightmost position; the positions of the other three aren't significant. (In fact, PSWs since about
1975 no longer have a field for the ILC.)

┌────────┬─ ─ ─ ─ ─┬─┬─ ─┬─┬─ ─┬────┬─ ─ ─ ─ ─┬────────────────────────────────┐

│ System │ │I│ │C│ │Pro─│ │ Instruction │
│ Flags │ │L│ │C│ │gram│ │ Address │
│ │ │C│ │ │ │Mask│ │ (IA) │
└────────┴─ ─ ─ ─ ─┴─┴─ ─┴─┴─ ─┴────┴─ ─ ─ ─ ─┴────────────────────────────────┘
Figure 12. Sketch of a Program Status Word

The PSW for the currently executing program resides in the CPU, not in memory.

The CC is set (given a value) by some instructions — for example, to indicate that the result of an
addition operation is a negative number. Other instructions may have no effect on the CC; in

Chapter II: System z 47

 such cases we say that it is not set, or that its value is unchanged. Still other instructions can test
the value of the CC and make decisions based on the result.

Among the system flag bits in the PSW is the “P” bit, which determines whether or not the CPU
will allow certain instructions to be executed. If the “P” bit is 1, the CPU is in Problem State and
will not execute privileged instructions, such as those specifying Input-Output operations. If you
try to execute a privileged instruction while the CPU is in Problem State, a program interruption
will occur instead. When the “P” bit is 0, the CPU is in Supervisor State, and it allows any
instruction to be executed. This is how supervisory programs retain control over activities critical
to the smooth operation of a complex programming system.

3.6. Other Registers

In all System z processors, the CPU contains many additional registers including Access Registers
and Control Registers. The Access Registers are used for special types of addressing. The
Control Registers are not normally available to application programs: they are not used for arith-
metic or for addressing by a program because they control various execution functions.

We'll say more about these and other registers as needed.

3.7. Input-Output (I/O)

Data transmission between main memory and external devices is managed by channels. Channels
transmit bytes of data from an external device to memory, or from memory to an external device,
while allowing the CPU to continue with the execution of a processing program. We will use
some simple forms of I/O later, especially for Programming Problems at the end of each chapter.

3.8. Features, Facilities, and Assists

The System z family of processors has grown from its original System/360 capabilities.23 The
added capabilities are sometimes called “features”, “facilities”, or “assists”. For example, the
“long-displacement” facility is a recent addition. We assume that your CPU has all the facilities
needed to execute our instructions and program examples.

3.9. Microprograms and Millicode (*)

For the earliest System/360 models, internal operations were controlled by “microprograms” that
were kept in a special type of read-only memory. The internal circuits were then “programmed”
by a combination of hardware and micro-instructions to act like a System/360 processor!

Modern processors, in contrast, use a combination of hardware, microcode, and “millicode”

instructions to execute the instructions you write, and to perform other CPU “housekeeping”
functions. Millicode instructions are kept in a reserved area of main memory. They are very
similar to your instructions, but can do things that your “normal” instructions can't do. 24 The set
of millicode instructions is sometimes referred to as “firmware”.

Terms and Definitions

byte
A group of 8 bits; the basic addressable unit of memory.

23 This is quite an understatement.

24 If you're interested in learning more about millicode, see the article by Lisa Heller and Mark Farrell in the I B M
Journal of Research and Development, Vol. 48 No. 3/4, May/July 2004.

48 Assembler Language Programming for IBM System z™ Servers Version 2.00

CC
Condition Code, a 2-bit field in the PSW used to indicate the status or result of executing
certain instructions.
CPU
Central Processing Unit
FPR
Floating-Point Register
GR
General Register
ILC
See Instruction Length Code.
Instruction Length Code
A 2-bit field in low storage indicating the length in halfwords of an instruction that caused a
particular type of interruption.
millicode
Internal instructions used by the CPU to perform operations too complex to be done cost-
effectively in hardware.
problem state
A state in which the CPU disallows the execution of certain privileged instructions.
PSW
Program Status Word, containing information about the current state of a program.
supervisor state
A state in which the CPU allows the execution of all instructions.

Chapter II: System z 49

4. Instruction Execution

44
444
4444
44 44
44 44
44 44
44444444444
444444444444
44
44
44
44

In this section we see how instructions are executed by the CPU, and then look at examples of
the formats used for five representative classes of instructions.

As we saw in Figure 5 on page 43, instructions executed by the computer reside in memory
along with the data to be processed. Instructions in System z can be 2, 4, or 6 bytes long.
Instructions are always aligned so that the leftmost byte is on a halfword boundary: that is, the
address of an instruction must always be divisible by two. This alignment does not depend on the
length of the instruction; it doesn't matter, for instance, that a 4-byte instruction begins halfway
between two word boundaries. It is more precise to say that instructions are 1, 2, or 3 halfwords
long.

Unlike some types of data, there is no requirement that an instruction start at an address that is a
multiple of its length; only that it start on a halfword boundary.

4.1. Basic Instruction Cycle

The process of executing instructions may be visualized in Figure 13.

┌───────┐ ┌────────┐ ┌─────────┐

┌────│ FETCH ├─────│ DECODE ├─────│ EXECUTE ├────┐
│ └───────┘ └────────┘ └─────────┘ │
│ │
└───────────────────────────────────────────────────┘
Figure 13. Basic instruction cycle

In the “fetch” portion of the cycle, the CPU locates the instruction beginning at the halfword in
memory whose address is contained in the rightmost part of the PSW (the Instruction Address, or
IA), and places it into an internal register where it is decoded. Though this internal register is not
accessible to programs, we will refer to it as the Instruction Register, or IR. The CPU determines
the length of the instruction by examining its first two bits, as we will see shortly.

To complete the fetch portion of the cycle, the CPU adds the length in bytes of the instruction
now in the Instruction Register to the IA in the PSW, so that the IA will contain the address of
the next instruction to be fetched when the current instruction completes its execution. This

50 Assembler Language Programming for IBM System z™ Servers Version 2.00

 means that instructions must be packed tightly in memory; there are no leftover bytes or gaps
between instructions executed in sequence.

To decode the instruction, the CPU examines the bit pattern in the IR to see what action is
intended. Since (1) the bytes were brought from memory and (2) the memory contains both data
and instructions, the bytes brought to the IR may actually represent data and not instructions.
The CPU has no way of knowing this; it simply goes to the memory address in the IA portion of
the PSW and fetches those bytes into the IR to be interpreted as an instruction. If this is what
you intended, good; otherwise, strange things can happen.

Not all of the possible bit patterns in the IR might represent “valid” instructions (i.e., actions the
CPU can execute, or will allow to execute). The decoding mechanism can sometimes detect con-
fused situations (such as data being interpreted as instructions) before too much damage has been
done, and cause remedial actions to be initiated.

Assuming that the bytes in the IR contain a valid instruction, further actions may be necessary
before the decoding is completed, such as calculating addresses of the operands to be manipulated
during the execute portion of the cycle.

During the execution phase, the actual operation is performed. It could cause the contents of one
general register to replace the contents of another, or it may involve many intermediate steps of
complicated logic or arithmetic. If no errors are detected during the execution phase (such as
attempting to divide a number by zero), the CPU resumes the instruction cycle by returning to
the fetch portion of the cycle.

We sometimes refer to the entire cycle of fetching, decoding, and executing an instruction simply
as “executing” that instruction.

Instructions
The IA portion of the PSW addresses the next instruction to be fetched.
If you didn't intend the fetched bytes to be an instruction, it's a mistake
you must correct.

Exercises
4.1.1.(2) How could you build a CPU without a separate Instruction Address (such as in the
z/Architecture PSW)?

4.2. Basic Instruction Types

The instructions provided by the original System/360 processors had five formats:
1. register-and-register (RR)
2. register-and-indexed-storage (RX)
3. register-and-storage (RS)
4. storage-and-immediate (SI)
5. storage-and-storage (SS)

Modern System z processors support over 30 instruction formats that we'll introduce as needed.
These five formats are enough for now, because newer instruction formats are variations on these
basic forms.

The letters RR, RX, RS, SI, and SS are abbreviations that indicate the type, or class, of an
instruction. Individual instructions belonging to each class will be treated in later chapters.

Figure 14 on page 52 gives a useful way to visualize the behavior of these classes:
• RR-type instructions operate on data within registers;
• RX- and RS-type instructions operate on data between registers and memory;

Chapter II: System z 51

 • SS-type instructions operate on data in two memory locations; and
• SI-type instructions operate on data in memory using an operand in an instruction.

┌─────────────────────────────┐
│ Registers │
└─────────┬──────────┬──────┬─┘
└────────┘ 
RR │
┌───────────────────┐ │RX,
│ Instruction │ │RS
└───────────────┬───┘ │
SI│ SS │
 ┌────────┐ 
┌─┴───────┴──────────┴──────┴─┐
│ Memory │
└─────────────────────────────┘
Figure 14. Instruction formats and data interactions

The first byte of an instruction always contains an operation code (often abbreviated “opcode”),
specifying the operation to be performed. The second byte usually contains data about the
location, type, or length of the data to be operated on. This second byte has several forms: it is
called the “register specification” byte (for RR, RX, and RS instructions), the “immediate data”
byte (for SI instructions), or the “length specification” byte (for SS instructions).25 The interpreta-
tion of this second byte therefore depends on the class to which the instruction belongs.
• RR-type instructions are always one halfword long.

register
operation
specifica-
code
tion
Table 6. RR-type instruction
format

• RX- and RS-type instructions are always two halfwords long.

register
operation
specifica- addressing halfword
code
tion
Table 7. RX-type and RS-type instruction format

The RX- and RS-type instruction formats differ only in the interpretation of the bits in the
“Register Specification” byte.
• SI-type instructions are always two halfwords long.

operation imme-
addressing halfword
code diate data
Table 8. SI-type instruction format

Instead of a register specification, the second byte of an SI-type instruction contains an 8-bit
data item used in executing the instruction.

25 In some newer instructions, the second byte may contain another part of the opcode; and in some instructions, part
of the opcode may be in the sixth byte! The CPU knows, so you needn't worry.

52 Assembler Language Programming for IBM System z™ Servers Version 2.00

 • SS-type instructions are always three halfwords long.

length
operation
specifica- addressing halfword addressing halfword
code
tion
Table 9. SS-type instruction format

For most instructions except RR-type instructions, an addressing halfword is used by the CPU to
compute the address of an operand; this important process is described in “5.1. The Addressing
Halfword”, on page 62, and again in Section 20. These classifications are not exhaustive; many
newer instructions are variations on these basic forms.

Exercises
4.2.1.(1) Must a 4-byte RX-type instruction begin on a word boundary?

4.2.2.(1) What is the length of the shortest instruction in System z?

4.2.3.(2) How is it possible for instructions of different lengths to be packed tightly into
memory with no wasted bytes?

4.2.4.(1) + May an instruction begin on a word boundary? On a doubleword boundary?

4.2.5.(2) + Figure 14 on page 52 implies that both instructions and data reside in the same
memory. How can you tell if a given string of bytes represents instructions or data?

4.3. Instruction Lengths

The first two bits of the operation code tell the CPU how many bytes to fetch from memory.
Since at least two bytes per instruction must always be fetched, the CPU can check the two
leading bits to tell how many more bytes (if any) are required. The bit patterns are shown in
Figure 15; “xxxxxx” represents the remaining six bits of the eight-bit operation code.

00xxxxxx 2-byte instructions such as RR-type

01xxxxxx 4-byte instructions such as RX-type
10xxxxxx 4-byte instructions such as RS- and SI-type
11xxxxxx 6-byte instructions such as SS-type
Figure 15. Opcode bit patterns for typical instruction types

If the first two bits of the opcode are 00 the instruction is one halfword long; if the bits are 01 or
10 it is two halfwords long; and if the bits are 11 it is three halfwords long.

Before decoding the instruction, the CPU places the number of pairs of bytes in the instruction
(the number of halfwords: 1, 2, or 3) into an internal two-bit PSW field called the Instruction
Length Code (ILC). It is important to remember that the two bits of the ILC are not the same as
the first two bits of the opcode. Table 10 on page 54* shows the relationship between the first 2
bits of the opcode and the ILC:

* Courtesy of Michael Stack.

Chapter II: System z 53

 ILC ILC Instruction Opcode
Instruction length
(decimal) (binary) types bits 0-1
0 B'00' Not available
1 B'01' RR B'00' One halfword
2 B'10' RX B'01' Two halfwords
2 B'10' RS, SI B'10' Two halfwords
3 B'11' SS B'11' Three halfwords
Table 10. Instruction Length Code and instruction types

If an error is detected during decoding or executing the instruction, the PSW at the time of the
error is saved, and the programmer can examine the ILC and the IA of the saved PSW to deter-
mine what instruction caused the error. If the ILC was not saved it would not be possible to
determine the exact location of the offending instruction, since the location of the next instruction
to be executed is already in the IA portion of the saved PSW, and the length of the bad instruc-
tion could have been 2, 4, or 6 bytes.

Exercises
4.3.1.(1) Is it possible for a six-byte instruction to be mistaken by the CPU for a four-byte
instruction? Explain.

4.3.2.(2) + A program segment consists of the following six operations (only the opcodes are
given): X'05', X'58', X'89', X'5A', X'D2', X'50'. Determine the length in bytes of the program
segment.

4.3.3.(2) For each of the instructions in the previous exercise, determine the value of the
Instruction Length Code after each has been fetched.

4.3.4.(2) By examining Figure 15 on page 53, deduce a simple formula that can be used to
determine, for any System z instruction, what number should be added to the Instruction
Address in the PSW to give the address of the following instruction.

4.3.5.(2) + Make (and study) a short table of four rows, with the following column headings:
(1) value of first two bits of opcode, (2) instruction type, (3) instruction length, (4) ILC after
instruction fetch is complete, and (5) number of addressing halfwords.

4.3.6.(2) + The following twelve halfwords taken from memory are known to be a sequence of
instructions. (The spaces have been inserted for readability; the bytes in memory are contig-
uous.)
90EC D00C 0580 50D0 89EA D703 89EE 89EE 18CD 41D0 89E6 1B11
Determine (1) how many instructions there are, (2) their lengths, and (3) their types.

4.3.7.(3) + Suppose you know the PSW and ILC after an execution error has occurred. How do
you determine the address of the instruction that caused the error?

4.3.8.(2) What would happen if gaps are left between instructions?

4.4. Some Operation Codes (*)

Table 11 on page 55 summarizes the characteristics of some basic instructions, as they depend on
the first four bits of the operation code. As described above, the first two bits determine the type
and length of the instruction. The second pair of bits determines (to some degree) the operand
length or the general functions performed by the instructions. (These groupings are only approxi-
mate, but they may help you to appreciate how opcodes are designed.)

A closer examination of a complete table of operation codes reveals a great deal of symmetry in
the opcodes used for similar functions. For example, the four original System/360 instructions

54 Assembler Language Programming for IBM System z™ Servers Version 2.00

 that perform the “Logical AND” operation all have operation codes where the second hex digit is
4 and the first hex digits differ by multiples of 4 (X'14', X'54', X'94', and X'D4').

First pair Second pair of bits

of bits 00 01 10 11
Word logical, Long Short
00 Branching, status
fixed-point hexadecimal hexadecimal
(RR) switching
binary floating-point floating-point
Branching, Word logical, Long Short
01
halfword fixed- fixed-point hexadecimal hexadecimal
(RX)
point binary floating-point floating-point
Branching,
10 Fixed-point,
shifting, status Logical
(RS, SI) logical, I/O
switching
11
Logical Packed decimal
(SS)
Table 11. General instruction classifications

Since we will refer to instructions almost entirely using mnemonics — short abbreviations for their
full names — these details are only of minor interest.

Exercises
4.4.1.(2) Examine the operation codes given in Exercise 4.3.2, and determine their general
instruction classifications from Table 11.

4.5. Interruptions (*)

The instruction cycle shown in Section 4.1 on page 50 describes the basic mechanism of instruc-
tion sequencing. However, a more workable view requires understanding interruptions, sometimes
called interrupts. We'll discuss them briefly here, and in more detail when we describe possible
exceptions caused by instructions.

When an interruption occurs, the CPU stores the PSW that currently controls its operation in a
predefined area of memory, and immediately replaces it with a new one from a different prede-
fined area of memory. Many things can cause this PSW switching: a program may contain an
instruction that causes an interruption to occur, or some external event such as a completed I/O
operation could cause an interruption. The basic mechanism used for handling interruptions is
illustrated in Figure 16.

┌───────┐ ┌────────┐ ┌─────────┐

┌────│ FETCH ├─────│ DECODE ├─────│ EXECUTE ├────┐
│ └───────┘ └────────┘ └─────────┘ │
│ │
 
│ no ┌──────────┴────┐
│───────────────────────────────────────┤Any Interrupts?│
│ └──────────┬────┘
│ │yes
no  ┌─────────────────────────────────────────────│
│  yes 
┌───┴────┴──┐ ┌────────────┐ ┌────────────────────┴────┐
│ Any other │───┤Load New PSW│───│Note interruption cause, │
│interrupts?│ │from Memory │ │save Old PSW, status info│
└───────────┘ └────────────┘ └─────────────────────────┘
Figure 16. Instruction cycle with interruptions

Chapter II: System z 55

 The usual cycle of fetching, decoding, and executing will continue undisturbed so long as no inter-
ruption occurs. 26 When an interruption condition is present, the CPU first examines bits in the
PSW (or in the Program Mask or in other special registers) to see whether the interruption should
be accepted. If these bits are zero, the interruption condition is said to be masked or disabled,
and the CPU takes a default action before proceeding to the next instruction.

If the interruption is not masked (or is enabled), the CPU places information about the cause of
the condition into a reserved “Interruption Code” area near the low-address end of memory. The
CPU then stores the current (old) PSW and loads a new PSW. Instruction fetching then
resumes, with the next instruction being fetched from the memory address specified by the IA
portion of the newly-loaded PSW. This will almost always be in the Supervisor.

Normally, the new PSW will disable further interruptions until the Supervisor can save informa-
tion about the status of the program being interrupted. After this status information (such as
register contents and the old PSW) has been saved, the CPU can be enabled for further inter-
ruptions. After the interruptions have been handled, the saved status information is restored and
the interrupted program can be resumed.

These are the six classes of interruptions, with examples of possible causes:
1. Restart (operator action)
2. External (timer, clock comparator)
3. Machine Check 27 (equipment malfunction)
4. Input-Output (an I/O device has signaled a condition)
5. Program (exception condition during program execution)
6. Supervisor Call (program requests an Operating System service)

Corresponding to each class is an area of memory where an old PSW is stored, and an area from
which a new PSW is loaded by the CPU. Thus there are six areas in memory into which old
PSWs are stored, and another six areas from which new PSWs are retrieved. These areas are at
fixed positions in the low-address end of memory; a programmer has no control over where they
are placed.

We sometimes distinguish two different classes of interruption. The first is caused by events whose
occurrence cannot be predicted, or for which a program cannot test in advance: these are some-
times called involuntary or asynchronous interrupts. The first four classes of interruption are invol-
untary. Except for the restart interruption, all the involuntary interruptions can be masked.

The program and supervisor call interruptions are voluntary or synchronous. They are mutually
exclusive, and cannot both occur at the same time. Program interruptions are caused by many
conditions, as you will discover. A supervisor call interruption occurs only as a result of exe-
cuting a Supervisor Call (SVC) instruction.

The program and supervisor call interrupts are “voluntary” because the program can (if it wishes)
know what instruction will be executed next, and what interruption-causing actions that instruc-
tion could take.

4.6. Exceptions and Program Interruptions (*)

Programs can create many types of exception condition. Some of them may not be serious, and
your program can tell the CPU to take some default action (like setting the Condition Code, or
generating a specified default result). Other exception conditions require interrupting the instruc-
tion cycle.

We will be most concerned with program interruptions. They may be caused by error conditions
detected during any of the three portions of the instruction cycle. For example, if the IA specifies

26 Figure 16 doesn't account for the possibility that an interruption can occur during the fetch or decode phases. In
almost all cases, this distinction is unimportant.
27 This interruption shouldn't be masked off because the CPU must save diagnostic information before the situation gets
worse.

56 Assembler Language Programming for IBM System z™ Servers Version 2.00

that an instruction should be fetched from an odd memory address, no fetch occurs and an inter-
ruption is generated instead. During the decode phase, the CPU may discover that the operation
code is invalid. Similarly, an error condition such as attempting to divide a number by zero may
occur during the execution phase.

Exceptions and Interruptions

Exception: An unusual condition possibly requiring attention; your
program may be able to request the CPU take a default
action and continue execution, or cause an interruption.
Interruption: An exception condition requiring alteration of the
normal sequence of program execution by passing
control to the Operating System.

For most program interruption conditions, the Operating System provides a brief indication of the
cause of the interruption. Additional diagnostic information may also be given, such as the old
PSW and the contents of the general and floating-point registers, and the contents of various areas
of memory. You can then use this information to try to deduce the cause of the interruption.
The most common types of program interruptions are shown below with their associated Inter-
ruption Codes. This list is not complete, but may help you find the causes of typical interruptions
generated by your programs.
IC=1 Invalid Operation Code. The decoding phase has found an operation code that cannot
be executed. This could be due to (1) allowing data to be fetched as instructions, or (2)
the program's destroying part of itself.
IC=2 Privileged Operation. The program is trying to execute an instruction not allowed in
problem state.
IC=3 Execute exception. An execute instruction is attempting to execute another execute
instruction.
IC=4 Access, Protection. The program has attempted to refer to some area of memory to
which access is not allowed. There can be other causes, but this is the most common.
IC=5 Addressing. The program has attempted to address a nonexistent memory address.
IC=6 Specification Error. This can be caused by many conditions, but a common cause is
referring to an odd-numbered register when an even-numbered register is required. An
odd IA in the PSW indicates an attempt to access an instruction not starting on a
halfword boundary.
IC=7 Data Exception. This is caused by invalid packed decimal data, or by binary or decimal
floating-point conditions described in Chapter IX.
IC=8 Fixed-Point Overflow. This is caused when a fixed-point binary result is too large.
IC=9 Fixed-Point Divide Exception. A binary divide instruction has found that a quotient
would be too big to fit in a register, or a divisor is zero.
IC=A Decimal Overflow. A packed decimal result is too large to fit in the result field.
IC=B Decimal Divide. A packed decimal quotient is too large to fit in the result field, or a
divisor is zero.
IC=C Hexadecimal floating-point exponent overflow. A hexadecimal floating-point result is
too large.
IC=D Hexadecimal floating-point exponent underflow. A hexadecimal floating-point result is
too small.
IC=E Hexadecimal floating-point lost significance. A hexadecimal floating-point result has lost
all its significant digits.
IC=F Hexadecimal floating-point divide exception. A hexadecimal floating-point operation is
attempting to divide by zero.
Four of the fifteen possible program interruption conditions are often regarded as harmless: fixed-
point and decimal overflow exceptions, and hexadecimal floating-point exponent underflow and

Chapter II: System z 57

 lost-significance exceptions. By setting an appropriate mask bit in the Program Mask to zero (see
Figure 12 on page 47), you can use the SPM instruction (described on page 234) to request that
the CPU take a predefined default action and continue execution without causing an interruption.
Other default actions can be requested for many floating-point operations, by setting mask bits in
the Floating-Point Control Register (more about this in Chapter IX).
Thus, exception conditions can sometimes cause an interruption, and sometimes take a default
action if the interruption is masked. For example, a fixed-point overflow if enabled will cause an
interruption with interruption code 8; but if masked off, the CPU will set the Condition Code to
3 before fetching the next instruction.
The CPU may seem overly cautious about detecting error conditions: the number of ways to gen-
erate interrupts sometimes seems larger than the number of ways to write a correct program!
However, these error-detection mechanisms help catch program errors: an interruption condition
will usually be generated before your program has gone too far, and you will have an indication
that something is wrong before the cause is obscured.
Consider the problem of finding program errors on a CPU in which all bit patterns represent
valid data or operation codes, and where none but the most unusual error conditions were caught.
The processor could offer little help, and you would have to write programs with many internal
checks and tests. In addition to the extra effort needed to write correct programs, the time used
for checking would cause the program to run more slowly. Program interruptions should be seen
as helpful clues from the CPU, and not as an indication that something is wrong with the
processor.

Exercises
4.6.1.(2) + Suppose the contents of the following 8-byte System/360 PSW28 (sketched in
Figure 12 on page 47) was displayed as the result of a program interruption. What error con-
dition is immediately evident? (The “xxxxxxxx” digits are unimportant for this exercise.)
xxxxxxxx 4017E26F

4.6.2.(3) Suppose the 8-byte Program New PSW area of memory had been initialized with the
following “New PSW”: (The “xxxxxxxx” digits are unimportant for this exercise.)
xxxxxxxx 0000A237
What do you suppose would happen if any program interruption occurs?

4.6.3.(1) What caused the following Interruption Codes?

1. 0001
2. 0009
3. 000C

4.7. Machine Language and Assembler Language

Sometimes people refer to Assembler Language programming as “machine language” or
“processor language” programming. In the earliest days of digital computers, there were almost
no programming tools like assemblers and compilers, so the instructions and data for programs
had to be created in the form of binary (or decimal or hexadecimal) digits that were loaded
directly into memory for execution, without any intermediate translation.
Thus, we consider “machine language” to be the processor's internal bit patterns representing
instructions and data types. Because it's difficult to know (and work with) these bit patterns, we
use assemblers and compilers to convert a program from forms manageable by humans into the
forms needed by the processor.

28 The modern z/Architecture PSW is quite different!

58 Assembler Language Programming for IBM System z™ Servers Version 2.00

 Even though Assembler Language is considered a lower-level language, we rarely program digital
computers in “machine language”, so it is no longer accurate to say we program in machine lan-
guage.29

4.8. Processor Evolution

Since the early days of System/360, many updates, changes, enhancements, and improvements
have been made to the original architecture. These have included 31-bit and 64-bit addressing
(which we'll see in Section 20), 64-bit registers, and a vast variety of new instructions. Many of
the instructions we'll see didn't exist in System/360. Each generation of processors has introduced
small and large enhancements; while we'll start with basic instructions that have been used for
many years, we'll also see many new forms that can simplify programming chores that were more
difficult or expensive when only the older instructions were available.
IBM has tried very hard to ensure that existing applications continue to execute correctly on each
new generation of processors. This concern with “backward compatibility” has made it easy for
users to increase the capacity and performance of their systems without having to rewrite and
retest large applications in which they have invested considerable time and effort.
Backward compatibility doesn't apply as uniformly to specialized programs that use system-
specific features, but most such features are typically managed by the operating system.

Terms and Definitions

decode
The CPU action of analyzing the contents of the IR to determine the validity and type of
instruction.
exception condition
A condition indicating an unusual result. Some exceptions can deliver a default result if an
interruption has been masked off by appropriate settings, while others always cause an inter-
ruption.
execute
The CPU's action of performing the operation requested by the instruction in the IR.
fetch
The CPU action of bringing halfwords from memory into the Instruction Register to be
interpreted as an instruction.
IC
Interruption Code, a value indicating the cause of an interruption.
ILC
See Instruction Length Code.
Instruction Length Code
A 2-bit field in low storage indicating the length in halfwords of an instruction that caused a
particular type of interruption.
interruption
A process taking control away from the currently executing instruction stream, saving infor-
mation about the interrupted program, and giving control to the Operating System Super-
visor.
IR
Instruction Register, a conceptual internal register in the CPU into which fetched instructions
are placed.

29 But some hardy souls still make corrective “patches” to programs in machine language, or enter machine language
instructions into memory using various testing and debugging techniques.

Chapter II: System z 59

 machine language
The internal representations of instructions and data processed by a computer.
operation code
The portion of an instruction specifying the actions to be performed by the CPU when it
executes the instruction. Often called “opcode”.
PM
Program Mask, a 4-bit field in the PSW used to control whether or not certain types of
exception conditions should cause an interruption, or take a predefined default action.

60 Assembler Language Programming for IBM System z™ Servers Version 2.00

5. Memory Addressing

55555555555
555555555555
55
55
555555555
5555555555
555
55
55
555
55555555555
555555555

We now describe how the CPU calculates addresses of data and instructions in memory when it
decodes the instructions of your program.

The addressing technique used in System z differs from that found in many earlier computers,
where the actual memory address (or addresses) of the operand (or operands) was part of the
instruction.

┌──────────┬───────────────────────────────────┐
│ opcode │ operand address │
└──────────┴───────────────────────────────────┘
Figure 17. Typical instruction format for old computers

When memory sizes were limited, this was a reasonable and efficient choice.30

Because the original System/360 architecture allowed addressing up to 224 bytes of memory, the
older technique of placing actual operand addresses into the instructions would have required at
least a 24-bit field for each such address. Since few processors had as many as 224 bytes of
memory, and because few programs needed as many as 224 bytes of memory to execute, many of
the bits in the 24-bit address field would be wasted by such a direct-addressing technique, and
instructions would be longer than needed.

In System z, the scheme used for addressing memory operands is much more flexible than using
actual operand addresses, and more economical in using the bits allotted to each instruction; but
more complex in the way it determines operand addresses.

The System z family of processors supports three modes of addressing. This section describes a
fundamental type of base-displacement address generation with 24-bit addresses. Section 20 in
Chapter VI describes 31-bit and 64-bit addressing, as well as two other types of address gener-
ation.

30 Another reason is that memory was very expensive! A really big machine might have had as many as 128 kilobytes of
memory; modern processors can have billions of times more.

Chapter II: System z 61

5.1. The Addressing Halfword
To refer to data or instructions in memory, a program will almost always use one of the general
registers, because the CPU uses information in a part of many instructions called an “addressing
halfword”. An addressing halfword always occupies a halfword in memory.

│─4 bits─│──────────12 bits──────────│

┌──────────┬─────────────────────────────┐
│base digit│ displacement │
└──────────┴─────────────────────────────┘
0 3 4 15
Figure 18. Structure of an addressing halfword

The first 4 bits of the addressing halfword contain a hex digit called the base register specification
digit, or base digit.31 The base digit specifies a general register called the base register. The 12-bit
field in the rest of the addressing halfword contains an unsigned nonnegative number called the
displacement that takes values from 0 to 4095.

To generate the address of an operand, the CPU does the following:

Step 1: The 12-bit displacement is put at the right-hand end of an internal register called the
Effective Address Register (abbreviated “EAR”), and the leftmost bits of the EAR
are cleared to zeros.
Step 2a: If the base register specification digit is not zero, then the contents of the specified
general register (the base register) are added to the contents of the EAR, and carries
out the left end are ignored.
Step 2b: If the base register specification digit is zero, nothing is added to the EAR (so that
general register zero will never be used by the CPU as a base register). That is, a
zero base digit means “no register”.

The result in the EAR is called the Effective Address. It may be used as the address of an
operand in memory, and for many other purposes (such as a shift count). These steps are
sketched in Figure 19.

────── General Registers ────

│ ─ ─ ─ │ ─ Addressing Halfword ─
├───────────────────────────────┤ ┌───┬─────────────────────┐
│ │ │ b │ displacement │
├───────────────────────────────┤ └─┬─┴──────────┬──────────┘
│ │ │ │
├───────────────────────────────┤ │ │
│ │ │ 
├───────────────────────────────┤─────────┘ ┌───────┐
│ General Register b │────────────────── │ Adder │
├───────────────────────────────┤ └───┬───┘
│ ─ ─ ─ │ │

┌─────────────────────────────────┐
EAR │ Effective Address │
└─────────────────────────────────┘
Figure 19. Sketch of Effective Address calculation

This method of generating addresses is called base-displacement addressing. In 24-bit addressing

mode (which we're assuming for now), only the rightmost 24 bits of the Effective Address are
used.

31 The base register specification digit was sometimes called the “base register address”, but this is misleading because
the base registers aren't “addressable” like bytes in memory.

62 Assembler Language Programming for IBM System z™ Servers Version 2.00

 Remember
An addressing halfword is not an address. It can be used to form an
Effective Address.

Exercises
5.1.1.(2) The use of the term “halfword” in describing an addressing halfword implies that it
(the addressing halfword) lies on a halfword boundary. Is this true under all circumstances?

5.1.2.(1) How many values may be assumed by the base register specification digit? How many
registers may be used by the CPU as base registers?

5.2. Examples of Effective Addresses

In the following examples, additions are done in both binary and hexadecimal arithmetic.
1. Suppose the addressing halfword of an instruction is 1011 001011010101 in binary (X'B2D5')
and suppose general register 11 contains
1100 0111 0011 1110 1001 0000 1010 1111
in binary (or C73E90AF in hex). Then, assuming we are generating 24-bit addresses, the
Effective Address of the instruction is
0000 0000 0000 0010 1101 0101 0002D5 (displacement)
+0011 1110 1001 0000 1010 1111 3E90AF (base)
0011 1110 1001 0011 1000 0100 3E9384 (Effective Address)
2. Suppose the addressing halfword of the same instruction is X'0468'. Then the Effective
Address is X'000468', since general register zero is never used as a base register.
3. Suppose the addressing halfword of the same instruction is X'B000', and the contents of R11
are as before. Then the Effective Address is X'3E90AF'; a zero displacement is valid.

Exercises
5.2.1.(2) + Assume general registers 0, 1, and 2 contain these values:
c(GR0) = X'12001038'
c(GR1) = X'0902A020'
c(GR2) = X'001AAEA4'
Calculate the 24-bit Effective Address for these addressing halfwords: (1) X'206C', (2) X'1EEC',
(3) X'0FB0'.

5.2.2.(2) + Assuming the same register contents as in Exercise 5.2.1, calculate the 24-bit Effec-
tive Address for these addressing halfwords: (1) X'1FEF', (2) X'0FC8', (3) X'2EA4'.

5.3. Indexing
After the displacement has been added to the base (if any), the CPU again checks the type of the
instruction. If the instruction is type RX, an indexing cycle is needed. The second byte of an
RX-type instruction (the “register specification” in Table 7 on page 52) contains two four-bit
fields: the second is called the index register specification digit or index register digit or index
digit, as shown in Figure 20 on page 64.

Chapter II: System z 63

 8 bits 4 bits 4 bits 16 bits
┌──────────────┬────────┬────────┬────────────────────────────────┐
│ opcode │operand │index │ │
│ │register│register│ addressing halfword │
│ 01xxxxxx │digit │digit │ │
└──────────────┴────────┴────────┴────────────────────────────────┘
0 7 8 11 12 15 16 31
Figure 20. RX-type instruction, showing index register specification digit

Step 3: If the instruction is type RX, and the 4-bit index register specification digit is not
zero, then the contents of the general register specified by the index register specifi-
cation digit are added to the contents of the EAR (again ignoring carries out the left
end). A zero index digit means “no register”, not general register zero.

The resulting quantity in the EAR is still called the Effective Address (sometimes called the
Indexed Effective Address). These steps are sketched in Figure 21.

────── General Registers ────

│ ─ ─ ─ │ ─ Addressing Halfword ──
├───────────────────────────────┤ ┌───┬───┬────────────────────┐
│ │ │ x │ b │ displacement │
├───────────────────────────────┤ └─┬─┴─┬─┴─────────┬──────────┘
│ │ │ │ │
├───────────────────────────────┤ │ │ │
│ │ │ │ 
├───────────────────────────────┤───┼───┘ ┌───────┐
│ General Register b │────┼────────── │ Adder │
├───────────────────────────────┤ │ └───┬───┘
│ │ │ 
├───────────────────────────────┤───┘ ┌───────┐
│ General Register x │─────────────── │ Adder │
├───────────────────────────────┤ └───┬───┘
│ ─ ─ ─ │ │

┌─────────────────────────────────┐
EAR │ Effective Address │
└─────────────────────────────────┘
Figure 21. Sketch of Effective Address calculation with indexing

Modern CPUs add the base and index register contents with a three-input adder, so there is actu-
ally only one calculation. The index register specification digit is sometimes called the index digit;
similarly, the specified register is the index register, and the quantity in it is the index.

Indexing is a powerful way to process structures of data items like arrays with uniform and regular
spacing, as we will see in Section 40. The addressing halfword provides the address of a fixed
position, and the index selects a particular item.

Exercises
5.3.1.(1) Draw a picture showing the locations of the base register specification digit, the base
register, and the base address. Then do the same for the corresponding index quantities.

5.3.2.(1) How does the CPU determine that an indexing cycle is needed during address compu-
tation?

5.3.3.(2) For each instruction type, determine the maximum number of general registers that
might be accessed by the CPU in calculating Effective Addresses.

5.3.4.(2) Under what circumstances will the CPU not calculate an Effective Address?

64 Assembler Language Programming for IBM System z™ Servers Version 2.00

5.4. Examples of Indexing
Continuing the examples of calculating Effective Addresss that we saw in Section 5.2:
4. Suppose an RX-type instruction is X'430A7468' and that GR7 contains X'12345678' and
GR10 contains X'FEDCBA98'. (The base register specification digit X'7' means that GR7 is
used as the source of the base address.) Again assuming we are generating 24-bit addresses, the
Effective Address is
0000 0000 0000 0100 0110 1000 000468 (displacement)
+0011 0100 0101 0110 0111 1000 345678 (base, from GR7)
0011 0100 0101 1010 1110 0000 345AE0
+1101 1100 1011 1010 1001 1000 DCBA98 (index, from GR10)
0001 0001 0001 0101 0111 1000 111578 (Effective Address)
5. Suppose an RX-type instruction is X'43007468' and that the contents of GR7 are again
X'12345678'. Then the Effective Address is
0000 0000 0000 0100 0110 1000 000468 (displacement)
+0011 0100 0101 0110 0111 1000 345678 (base)
0011 0100 0101 1010 1110 0000 345AE0 (Effective Address)
(No indexing cycle is needed, since the index register specification digit is zero.)
6. Suppose an RX-type instruction is X'43070468' and that GR7 still contains X'12345678'. Then
the Effective Address is
0000 0000 0000 0100 0110 1000 000468 (displacement)
+0000 0000 0000 0000 0000 0000 000000 (base)
0000 0000 0000 0100 0110 1000 000468
+0011 0100 0101 0110 0111 1000 345678 (index)
0011 0100 0101 1010 1110 0000 345AE0 (Effective Address)
In this example the values of the base and index register specification digits were interchanged
from those in example 5, so that the indexing cycle was required to compute the same Effec-
tive Address.

In situations where only one register is used to calculate an Effective Address (as above, where the
base digit was 0 and the index digit was 7), be careful not to call that register the base register,
even though it usually behaves like a base register in an RX-type instruction.32

Exercises
5.4.1.(1) Under what circumstances may GR0 be used as a base register? As an index register?

5.4.2.(3) + Assume the hexadecimal contents of the general registers are as shown:
C(GR0) = 12001028 C(GR4) = 8888000E
C(GR1) = 8902A020 C(GR5) = 12345678
C(GR2) = 4F1AAEA4 C(GR6) = 0FDE3B72
C(GR3) = FFFFFFF8 C(GR7) = 92837465
and GR8 through GR15 contain zeros. Now, compute the 24-bit Effective Address of each of
the following instructions, paying careful attention to instruction type: (1) X'9803206C', (2)
X'50F10EEC', (3) X'41133333', (4) X'7A341DA4', (5) X'91220166', (6) X'8F120FB0'.

5.4.3.(3) + Assume that the contents of the general registers are as shown below for GR0
through GR7, and that GR8 through GR15 contain zeros.

32 In the “Access Register” addressing mode, index and base registers participate differently in calculating Effective
Addresses: only base registers are used to select an Access Register.

Chapter II: System z 65

 C(GR0) = 00000044 C(GR4) = 41800000
C(GR1) = 000902AE C(GR5) = 00010000
C(GR2) = A20710FC C(GR6) = 00FFFF00
C(GR3) = FFFFFFFF C(GR7) = FF000000
Now, compute the 24-bit Effective Address of each of the following instructions: (1)
X'41726100', (2) X'920710FC', (3) X'7A333002', (4) X'5806016C', (5) X'43B00044', (6)
X'90EC126A', (7) X'86052E4D'.

5.4.4.(3) Suppose the contents of the general registers are as shown in Exercise 5.5.2 below. For
each of the following instructions, determine the Effective Address, paying careful attention to
instruction type: (1) X'58040404', (2) X'91628DBC', (3) X'44FF7D5C'.

5.5. Addressing Problems (*)

The Effective Address in the EAR has many uses, most often to address operands in memory; it
is also used for other purposes such as shifting and branching.

Certain instructions operating on groups of bytes require the address of the leftmost (lowest-
addressed) byte of the operand group be exactly divisible by the length of the operand. If this
condition is not satisfied, a program interruption for a specification exception occurs. In early
processors, operand alignment was required for almost all instructions, but the requirement was
relaxed soon after.33 Few instructions in modern processors require strict operand alignment.

When you use base-displacement addressing with 12-bit displacements, the only part of the
memory that can be referenced without using a base register is the area with addresses 0 to
4095 = X'FFF', so you will almost always use a base register to refer to operands in memory.
(We'll see in Chapter VI, Section 20 that instructions with signed 20-bit displacements make this
4K-byte limitation much less severe.)

You can't put your program into those first 4096 bytes 34 because that area of memory (and more)
is reserved by the CPU and the Operating System. This means that if you want to access a byte
in memory at address XX (where XX is greater than 4095), there must be a base register available
— one of registers 1 to 15. If a base register contains a base address, and XX lies between that
base address and the base address + 4095, then we say that XX is addressable. If there is no such
number in a register, then the byte at XX is not addressable by your program.

When we place a number in a register to address a 4096-byte region of memory, that register
provides addressability for the region. However, if the number itself must be brought from
another portion of memory that is not currently addressable, we are back where we started,
needing another number to provide addressability for the first number.

Fortunately, there are simple solutions to the problems of establishing addressability. The BASR
instruction is often used (as we will see soon), and the Assembler's address constants also allow us
to refer to other areas of our program. Modern processors provide new ways to minimize these
addressing problems: long displacements and relative addressing. We will turn to them in Section
20 after we have investigated the most often-used instructions.

Exercises
5.5.1.(3) + Suppose the general registers contain the values shown in Exercise 5.2.1. Which of
the following locations in memory (given in hexadecimal) are addressable through the use of
the base-displacement addressing technique? For each location that is addressable, derive an
addressing halfword that can be used to address it. (1) X'02ABCD', (2) X'000A4D', (3) X'001139',
(4) X'88888E', (5) X'02A010'.

33 Because many programs had to manage unaligned data items, extra instructions were needed to isolate and align the
required item. The processor designers were asked (urgently!) to remove the restriction wherever possible. The relax-
ation of the alignment requirement was called the “Byte-Oriented Operand Feature”; it soon was known as the
“BOOF”.
34 Unless you're writing your own operating system!

66 Assembler Language Programming for IBM System z™ Servers Version 2.00

 5.5.2.(3) + Suppose the contents of the general registers are as follows:
C(GR0) = 00010A20 C(GR8) = 8031B244
C(GR1) = 42319B7C C(GR9) = 00000010
C(GR2) = 91F0F002 C(GR10) = 723B94C1
C(GR3) = 1002340A C(GR11) = E931AB7F
C(GR4) = 00FF00FF C(GR12) = 00000E38
C(GR5) = D907C401 C(GR13) = 6B005000
C(GR6) = 12345678 C(GR14) = 80000000
C(GR7) = 992B42A3 C(GR15) = FFFFFFFF
For each of the following memory addresses, determine first whether or not that memory
location is addressable by a program using those registers. If it is addressable, determine an
addressing halfword (base-displacement halfword) that can be used to address the location. (1)
X'010A20', (2) X'FFFFFF', (3) X'6A0054', (4) X'31AB7E', (5) X'001234', (6) X'07D3C4', (7)
X'00A004', (8) X'31BB65', (9) X'9ABCDE', (10) X'07C401'.

5.5.3.(3) In Exercise 5.5.2, which locations are addressable through the base-displacement
addressing technique with indexing allowed? Derive an addressing halfword and the accompa-
nying index digit that (in an RX-type instruction) would make the locations addressable.

5.5.4.(3) + Suppose the contents of the general registers are as shown in Exercise 5.1.2 on page
63 (note that registers 8 through 15 contain zeros). For each of the following memory
addresses, determine an addressing halfword that can be used to address that memory position.
If no such addressing halfword exists, say so. (1) X'000EEB', (2) X'001040', (3) X'072000'.
How many solutions are there for address (1)?

5.5.5.(4) + In Exercise 5.5.1, which locations in memory are addressable through the base-
displacement addressing technique with indexing allowed? Derive an addressing halfword and
the accompanying index digit that (in an RX-type instruction) would make the locations
addressable. (Remember that Exercise 5.5.1 refers to Exercise 5.2.1.)

5.5.6.(1) Suppose a program can be put entirely within the first 4096 bytes of memory. Will it
use GR0 as a base register?

5.5.7.(2) Assume that the contents of the general registers are as shown in Exercise 5.5.2. For
each of the following SS-type instructions, compute both Effective Addresses (there are two
addressing halfwords in an SS instruction, as shown in Table 9 on page 53).
(1) X'D2078F1D57C4', (2) X'DCFFDCFF7000', (3) X'F26337390050', (4) X'D58DFE4FC016'.

5.6. Address Translation and Virtual Memory (*)

All models of System z support address translation, called Dynamic Address Translation (or
“DAT”). Address translation is invisible to application programs. It provides greater Operating
System flexibility in assigning programs to main memory, a heavily used resource. Address trans-
lation takes your program's “virtual” addresses and maps them invisibly into the “real addresses”
needed for references to “real” memory.

Without DAT, a reference to a byte at X'123456' addresses that byte in the physical or “real”
memory of the processor. When DAT is active, your reference to a byte (at your virtual Effective
Address X'123456') is translated into a “real” address (such as X'27D94FA') having no obvious
relation to your address; you can't determine the relation of your virtual addresses to the real
addresses to which they are mapped. The Operating System, working with the DAT facilities,
makes it possible for your program to operate as though it is addressing “real” memory; but only
the Operating System works with real addresses. This is why your addresses are called “virtual” —
they aren't real.

Address translation is simple in concept but complex in implementation. To illustrate, the virtual
(effective) address supplied by your program is divided into sections; for 31-bit addresses, they are
a segment index, a page index, and a byte index, as illustrated in Figure 22 on page 68.

Chapter II: System z 67

 11 8 12
┌──────────────┬─────────┬──────────────────┐
│ segment │ page │ byte │
│ index │ index │ index │
└──────────────┴─────────┴──────────────────┘
Figure 22. 31-bit Virtual Address

To use these indexes for calculating real addresses, the Operating System first constructs (in a pro-
tected area of real memory) two sets of tables, page tables and a segment table, and it places the
address of the segment table (for example, taken from Control Register 1) into an internal field.
Your virtual address is translated into a real address roughly as follows:
Step 1: The segment table address is retrieved and the segment index is added to it. The result
is the address of one of the entries in a list of segment tables.
Step 2: The specified segment table entry (which contains the address of one of the entries in
a list of page tables) is retrieved, and the page table index is added to it. The result is
the address of an entry in the specified page table.
Step 3: The specified entry in the page table is retrieved, and attached to the left (high-order)
end of the byte index. The result is the real address of a byte in main memory.

We will not show examples of translation, since it is invisible to your program.

This description covers only very basic aspects of translation, and does not cover 64-bit virtual
addresses. There are many other details of the process, and (because translation is very heavily
used) the processor has a lot of additional hardware to optimize the process.

Exercises
5.6.1.(3) Some processors use a technique called indirect addressing. If a bit in the instruction
(called the indirect-addressing bit) is nonzero, the CPU uses the Effective Address not to access
an operand, but to access a second instruction. The Effective Address of this new instruction
then becomes the operand address that points to the desired operand. (On some processors, if
the instruction at the “indirect address” had its indirect-addressing bit set, then the entire
process repeats until an instruction is found without the indirect-addressing bit set.) Can you
think of reasons why indirect addressing is not provided by System z?

5.6.2.(0) Another aspect of early addressing techniques (whereby instructions contained actual
operand addresses) was that the address portions of instructions often had to be modified. Find
a programming “old-timer”: ask for an explanation of address modification techniques on
processors such as the IBM 7090, and why the method used on System z is so clearly superior.

5.7. Summary
As noted earlier, Effective Addresses are used for many purposes; the most common is to refer to
an operand in memory. Almost always, the operand is referred to by its lowest-addressed byte;
and if the operand is a binary integer, that byte contains the most significant (high-order) byte of
the integer. So, references to “low-order” and “high-order” may need to distinguish clearly
between memory addresses, bit ordering, and numeric significance.

Terms and Definitions

address translation (“Dynamic Address Translation”, DAT)
The procedure used by the CPU to convert virtual addresses into real addresses.
addressability
A base register and a displacement provide an Effective Address allowing valid reference to a
byte in memory.

68 Assembler Language Programming for IBM System z™ Servers Version 2.00

 addressing halfword
A halfword containing a base register specification digit in the first 4 bits, and an unsigned
displacement in the remaining 12 bits. A key element of System z addressing.
base address
The execution-time contents of a base register.
base register
A general register used at execution time to form an Effective Address.
base register specification digit
The first 4 bits of an addressing halfword.
displacement
An unsigned 12-bit integer field in an addressing halfword used in generating Effective
Addresses.35
EAR (Effective Address Register)
A (conceptual) internal register used to hold Effective Addresses.
Effective Address
The address calculated from an addressing halfword, possibly with indexing.
index
The contents of an index register.
index register specification digit
4 bits of an RX-type instruction specifying a register with a value to be added to the Effective
Address calculated from an addressing halfword.
indexing
Computation of an Effective Address by adding a displacement to the contents of a base reg-
ister and an index register.
real address
The “true” address of a memory location.
virtual address
The address of a memory location that may physically reside at a different real address.

35 We will see in Section 20 that System z provides another form of base-displacement addressing with a signed 20-bit
displacement.

Chapter II: System z 69

70 Assembler Language Programming for IBM System z™ Servers Version 2.00
Chapter III: Assembler Language Programs

IIIIIIIIII IIIIIIIIII IIIIIIIIII

IIIIIIIIII IIIIIIIIII IIIIIIIIII
II II II
II II II
II II II
II II II
II II II
II II II
II II II
II II II
IIIIIIIIII IIIIIIIIII IIIIIIIIII
IIIIIIIIII IIIIIIIIII IIIIIIIIII

We have seen how the CPU executes instructions and evaluates addresses; now we'll see how we
write Assembler Language programs.
• Section 6 describes typical steps involved in preparing, assembling, linking, and executing pro-
grams written in Assembler Language.
• Sections 7 and 8 examine the components from which machine, assembler, and macro instruc-
tion statements are formed.
• Section 9 describes five major machine-instruction types and how we write their operands in
machine instruction statements.
• Section 10 introduces the key concept of addressability in Assembler Language programs, a
necessary step for any program executed on System z.

Chapter III: Assembler Language Programs 71

6. Assembler Language

6666666666
666666666666
66 66
66
66
66666666666
666666666666
66 66
66 66
66 66
666666666666
6666666666

The Assembler is the program most used in creating specific instruction sequences for execution
by the processor.

First, we describe how to write programs and see the steps leading to their execution. The con-
ventions and rules for using the Assembler are called “Assembler Language”, even though there is
little resemblance to what most people mean by “language”.

6.1. Processing Your Program

First, we consider the steps involved in running an Assembler Language program:
1. assembly
2. linking
3. loading and execution

6.1.1. Assembly
Assembly is represented schematically in Figure 23. The Supervisor places the Assembler in
memory to begin assembling your source program.

┌───────────────────────┐
│ System z │
├───────────────────────┤
┌─────────┐ │ ┌───────────┐ │ ┌────────┐
│ Your │ │ │ │ │ │ Your │
│ Source ├────┼──── │ Assembler ├─────┼──── │ Object │
│ Program │ ┌─┼──── │ ├─────┼─┐ │ Module │
└─────────┘ │ │ └───────────┘ │ │ └────────┘
│ └───────────────────────┘ │
┌───────────┴─────────┐ │ ┌─────────┐
│ Libraries of Macro─ │ └─ │ Your │
│ Instructions and │ │ Program │
│ other statements │ │ Listing │
└─────────────────────┘ └─────────┘
Figure 23. Simple view of Assembler processing

72 Assembler Language Programming for IBM System z™ Servers Version 2.00

 The Assembler reads the statements of your Assembler Language program, processes them — pos-
sibly with the help of some data in libraries of macro-instructions and other statements — converts
your Assembler Language program to machine language, and produces an object module con-
taining object code. Usually you will want a program listing showing your source program and
the generated object code, with additional information about the Assembler's processing and indi-
cations of errors it may have detected.

The Assembler converts the program from a form convenient for you (statements) to a form con-
venient for the processor (binary data and instructions), its machine language.

6.1.2. Linking
The Linker 36 combines your object module with any others needed for execution. The linking
step is sketched in Figure 24; the Linker is placed in memory and begins execution.

┌──────────────────────┐
│ System z │
├──────────────────────┤
┌────────┐ │ ┌──────────┐ │ ┌────────┐
│ Your │ │ │ │ │ │ Your │
│ Object ├─────┼──── │ Linker ├─────┼──── │ Load │
│ Modules│ ┌──┼──── │ ├─────┼─┐ │ Module │
└────────┘ │ │ └──────────┘ │ │ └────────┘
│ └──────────────────────┘ │
┌───────────┴──┐ │ ┌─────────┐
│ Libraries │ └─ │ Your │
│ of Object or │ │ Linker │
│ Load Modules │ │ Listing │
└──────────────┘ └─────────┘
Figure 24. Simple view of program linking

The output of the Linker is a load module.37 The load module is written to a storage device, and a
listing of information summarizing the linking process is created.

The Linker also accepts load modules as input, allowing you to update or modify existing load
modules without having to reassemble all its components.

6.1.3. Loading and Execution

At execution time, the load module produced in the linking step is “loaded” into memory. An
essential feature of this process is relocation, which we'll investigate in Chapter X, Section 38.
The portion of the Supervisor that loads and relocates load modules is called the Program Loader.
Like the Linker, it is a program that treats other programs as data.

After your program has been loaded into memory, the Supervisor transfers control to it by setting
the Instruction Address in the PSW to the address of the instruction where you want execution to
begin. Your program then does whatever processing you told it to do 38 and when it is finished it
returns control to the Supervisor.

36 We'll use “Linker” to mean any program (such as the Binder and Linkage Editor) that combines object module files
into executable files like load modules.
37 The output of a Linker has many many different names and forms, depending on the operating system and the
system Linker. For example, on System z the output of the z/OS binder can be a “load module” or a “program
object”; the output of the z/VSE Linker is a “phase”, and the output of the z/VM CMS loader is a “module”. We'll
use “load module” to mean a data set or file ready to be loaded directly into memory for execution.
38 Which may not always be what you intended!

Chapter III: Assembler Language Programs 73

 ┌────────────────────────┐
│ System z │
├────────────────────────┤
┌────────┐ │ ┌──────────┐ │
│ Load ├───┼───── │ Program │ │
│ Module │ │ │ Loader │ │
└────────┘ │ └─┬────────┘ │
│ │ Loads, and │
│ │ then passes │
│ │ control to │
│  your program │
┌─────────┐ │ ┌─┴────────┐ │ ┌─────────┐
│ Your │ │ │ Your │ │ │ Your │
│ Program ├──┼───── │Relocated ├──────┼── │ Program │
│ Data │ │ │ Program │ │ │ Output │
└─────────┘ │ └──────────┘ │ └─────────┘
└────────────────────────┘
Figure 25. Simple view of program loading and execution

The last two linking and program-loading steps can be combined by using a Loader instead of the
Linker and Program Fetch routines. The Linker or Loader reads and relocates your object
modules directly into memory, and combines them with any necessary additional object and load
modules from the “Libraries of Object or Load Modules”.

An Assembler Language program is “processed” twice: once by the Assembler at assembly time,
and once by the CPU when it is executed at execution time (or run time). The difference between
these two times is important: the Assembler produces object modules with machine language
instructions and data to be placed into memory later; your data is processed only when your
program is finally loaded and your instructions are executed.

Exercises
6.1.1.(1) Draw a diagram combining Figures 23 through 25, to show the relationships between
the inputs and outputs of processing your programs at each step.

6.2. Preparing Assembler Language Statements

You prepare Assembler Language programs in the form of statements. There are four types:
comment statements, machine instruction statements, assembler instruction statements, and macro-
instruction statements. All four can be used in creating programs.
1. Comment statements provide explanatory material in the program so it will be easier for you
and others to read and understand. They are displayed in the program listing, but are not
translated into instructions or data and do not appear in the object module.
2. Machine instruction statements are converted by the Assembler into machine language
instructions for the CPU to execute when your program is loaded into memory for execution.
3. Assembler instruction statements provide information to the Assembler. They can be as
simple as statements generating data or specifying a title for the top of each page of the
listing, or can be more complicated, such as statements telling the Assembler that certain reg-
isters may be used as base registers. Some Assembler instruction statements cause the
Assembler to generate machine language data; others do not.
4. Macro instructions provide a compact assembly-time notation for groups of statements. They
are a convenient way to specify sequences of other statements (all four types are allowed) in
which parts of the generated statements can be changed to suit your needs. Macro
instructions are a very powerful and useful feature of the Assembler Language.

74 Assembler Language Programming for IBM System z™ Servers Version 2.00

 The Assembler processes input records exactly 80 bytes long. Your records may not extend all
the way to 80 characters, but there must still be enough blank or other characters to extend its
length to 80. These 80-character records are often called “card-image” records.39

Statements occupy positions 1 through 71 of a line. Such positions are called “columns”.
Column 72 has a special meaning: if it is not blank, the next line is considered to be a continua-
tion of the line with the nonblank character in column 72, in such a way that the character in
column 16 of the second line is treated as following immediately after the character in column 71
of the preceding continued line.40 This is illustrated in Figure 26. These conventions — column 72
for the continuation indicator and column 16 where the statement continues — are almost always
used for machine instruction and assembler instruction statements.

Columns 73-80 may be used for any purposes (usually, for sequencing data).

┌── first character of a record last character of a record ──┐

 
1 10 20 30 40 50 60 70 80
....v....|....v....|....v....|....v....|....v....|....v....|....v....|....v....|
  
│ └── continue column (16) end column (71) ──┘│
└── start column (1) nonblank character if continued ─────────────┘

Figure 26. Assembler Language statement columns

Columns 1 through 15 of a continuation line must be blank. (A common error is to write char-
acters in column 72 accidentally, so that the following line is treated as a continuation line, and
processed in an unexpected way.)

Columns 73 through 80 are ignored by the Assembler. Since all 80 columns of the input record
appear on the listing, the last 8 columns are often used for identification or sequencing informa-
tion. 41

A comment statement is identified by an asterisk (*) in column 1. Any information may appear in
columns 2 through 71. Figure 27 on page 76 has examples of comment statements:

39 The choice of 80 characters goes back to the nearly universal use of “IBM cards”. For many years before and after
the introduction of System/360, programs and data were prepared on 80-column punched cards. So, we still say
“column” rather than something like “position”.
40 You can change these columns with the ICTL Assembler instruction statement. It allows other columns to be used
for the start, end, and continuation columns of a statement. The numbers given are the ones the Assembler uses if it
is not told otherwise. ICTL is almost never used, anyway; if you use ICTL to change those columns, other readers of
your program may be confused.
41 Even though IBM cards have 80 columns, early computers like the IBM 704 and 709 couldn't read the last 8
columns! Those processors had 36-bit words, so their card readers read alternate groups of 36 bits from the 12 rows
on a card into 24 words. This 72-column custom persists.

Chapter III: Assembler Language Programs 75

 1 10 20 30 40 50 60 70 80
....v....|....v....|....v....|....v....|....v....|....v....|....v....|....v....|

* This is a comment statement. It is not continued.

* This comment statement is correctly continued: its continuation X ←column 72

on this next line starts in column 16.

* This comment statement is also continued, but is an error: X

this continuation line has nonblank characters before column 16.

Figure 27. Comment statement examples

Figure 27 contains some entirely blank lines. They are often used to improve readability; the
Assembler copies them to the program listing, and they have no effect on your program.

Comment statements may be continued onto following lines, as shown in the figure above. This
is generally not a good practice; most programmers avoid column 72 in comment statements.

A common method for adding “blocks” of comments to a program is illustrated in Figure 28.

*********************************************************************
*
* This is a block of comments documenting the behavior of this
* program. Since we have not written any programs yet, this block
* only illustrates how you can include large amounts of descriptive
* text to your program to help readers and maintainers understand
* what the program does -- at least, what you intended it to do.
*
*********************************************************************
Figure 28. Block comments

Exercises
6.2.1.(1) For the Assembler you use, determine what rules apply to the columns of continued
statements after the first continuation.

6.3. Statement Fields

The machine instruction, Assembler instruction, and macro-instruction statements each have four
parts called fields: the name, operation, operand, and comment or remarks fields.42 An entry in the
operation field must always be present, and for certain statements an entry in some of the other
fields may or must be omitted.

If there is a name field entry in the statement, it must begin with a nonblank character in column
1. It is terminated by the first blank column after column 1. If no name field entry is desired,
column 1 must be left blank.

42 It's better to call this the “remarks” field, to avoid confusion with comment statements.

76 Assembler Language Programming for IBM System z™ Servers Version 2.00

 After the name field and separated from it by one or more blanks is the operation field entry; it
ends with the first blank after the start of the operation field. The operation field entry is some-
times called the “mnemonic” or “operation” or “operation mnemonic”. 43

After the operation field entry and separated from it by one or more blanks is the operand field
entry, which, like the name and operation field entries, terminates with the first blank column
detected after the start of the operand field entry, except for one special case (quoted strings)
described in the next section.

The rest of the input line is treated as remarks by the Assembler and is ignored. It does not influ-
ence the processing of the statement unless this field extends into column 72, indicating a contin-
uation on the next line. Except for the name field, there is no restriction on the columns where
the other three fields must start; they simply end with a blank column.

This allows free-field statements: you can arrange the information on the input lines of your
program as you like, but the fields must appear in the proper order. These rules are summarized
in Figure 29, where “┴” means “one or more blanks”.

column 1 end by column 71

 
Name─Field─Entry ┴ Operation ┴ Operands ┴ Remarks

usually required usually always

optional required optional

Figure 29. Statement fields for machine, assembler, and macro-instruction statements

Even though any number of blanks can be used to separate the fields of a statement, it is cus-
tomary to improve program readability by making all operation, operand, and remarks fields
entries start in the same columns. For example, if your name-field entries are eight or fewer char-
acters long, place your operation field entries in column 10; similarly, if the operation field entries
are eight or fewer characters long, start your operand field entries in column 19. Later examples
of program fragments will show how this can be done.

A good programming practice is to use the remarks field to tell the reader what the statement is
supposed to do, and why. (Program comments and remarks sometimes say the program “does”
one thing, while it actually does something different when the CPU executes it!)

Good Programming Practice

Your program's comments and remarks should help the reader (who may
be you!) understand what each statement and group of statements is
doing, and why.

The term “operand” can be confusing. Section 3.1 on page 43 stated that an operand is something
in a register or in memory that is “operated on” during the execution portion of the instruction
cycle. “Operand” is also used here to describe the components that make up the operand field
entry of a statement! It helps to remember that the first meaning applies to the execution step of
a job, while the second meaning applies only during the assembly step.
Figure 30 on page 78 illustrates a machine instruction statement in which entries appear in all four
fields.

43 Be careful not to call it the “opcode”! That term is properly used for the bits of an instruction that tell the CPU what
to do. Sometimes people use “opcode” to mean both the operation field entry of an instruction — the mnemonic —
and the machine instruction bits, so listen carefully. Which is meant will usually be clear.

Chapter III: Assembler Language Programs 77

 LOAD LR 7,3 Copy c(GR3) to GR7
Figure 30. A machine instruction statement

The operand field entry has two entries, “7” and “3”, separated by a comma. If the instruction is
executed in a program, it would cause the contents of general register 7 to be replaced by a copy
of the contents of general register 3.44
The assembler instruction statement in Figure 31 omits the name and comment field entries, and
causes the Assembler to put a “title” heading on each page of the program listing.

TITLE 'PROGRAM NO. 1'

Figure 31. An assembler instruction statement

Figure 32 shows an example of a macro-instruction statement in which only an operation field

entry appears.

RETURN
Figure 32. The macro-instruction statement R E T U R N

If the RETURN statement above had been prepared in the days of punched cards, the card 45
might look like this:

RETURN

 
000000000000000000000000000000000000000000000000000000000000000000000000000000
11111111111111111111111111111111111111111111111111111111111111111111111111111111
22222222222222222222222222222222222222222222222222222222222222222222222222222222
3333333333333333333333333333333333333333333333333333333333333333333333333333333
4444444444444444444444444444444444444444444444444444444444444444444444444444444
555555555555555555555555555555555555555555555555555555555555555555555555555555
66666666666666666666666666666666666666666666666666666666666666666666666666666666
77777777777777777777777777777777777777777777777777777777777777777777777777777777
88888888888888888888888888888888888888888888888888888888888888888888888888888888
99999999999999999999999999999999999999999999999999999999999999999999999IBM5081
Table 12. Punched-card image of a R E T U R N statement

The Assembler supports mixed-case characters, so you need not write symbols, operation field
entries, and most operand field entries using upper-case letters. (However, the Assembler treats
lower-case and upper-case letters as equivalent when they appear in symbols and operation field
entries; unlike some high-level languages, the Assembler is not case-sensitive except for characters
within quoted strings.) Thus, you could write Figure 32 as

44 The remarks in this statement are quite useless, because readers can see what the instruction does. Remarks should
explain reasons for doing something, like “Copy record count to GR7 for multiplication”.
45 The characters “IBM5081” in the bottom right corner of the “card” were called the “electro number”, the number of
the plate used for printing the cards. Number 5081 was used for cards with no other information than the row
numbers, zero through nine. The empty two rows at the top were called the “twelve” row and the “eleven” row. (This
card was also known as the “IBM Model 5081 Data Storage Device”.)

78 Assembler Language Programming for IBM System z™ Servers Version 2.00

 Return

with the same results.

Mixed Case Names: Be Careful!

The Assembler accepts mixed-case names, but processes them internally
as through they are all in upper case. Thus, a symbol like AbCdEfgh is
considered to be the same as the symbol ABCDEFGH.

6.3.1. What's in a Name Field? (*)

Many items can appear in the name field of an instruction statement, such as:
• the name of a machine instruction
• the name of a data area
• a symbol to be given a value without naming any part of the program
• a Labeled USING qualifier (described in Chapter XI, Section 39.4)
• in the Conditional Assembler Language, a variable or sequence symbol
• characters to be copied to the sequence field of the object module
• ... and some statement require the name field to be empty!
Some people call the name field entry a “label” when it is the name of a machine instruction, but
in other contexts this can be very misleading. It's too easy to start thinking of all name-field
symbols as “labels” when they're actually used for other purposes.

Exercises
6.3.1.(1) Suppose a program contains the machine instruction statement shown in Figure 30 on
page 78. During what part of the job processing will the statement be read by the Assembler?
During what part of the job processing will the assembled hexadecimal instruction be fetched
by the CPU?

6.3.2.(1) In what column should the remarks field of a machine instruction statement begin?

6.3.3.(1) In what columns may the operation field entry of a machine instruction statement
begin?

6.3.4.(1) Which field in an assembler instruction statement is required?

6.3.5.(2) + What types of statement may be written without an operation field? Without an
operand field? Without a remarks field?

6.3.6.(2) + Suppose the machine instruction statement in Figure 30 on page 78 had been
written so that column 1 was blank, and the characters “LOAD” began in column 2. How
would the fields of the statement be interpreted?

6.3.7.(2) What types of Assembler Language statements may be written without an operation
field? Without a comment field?

6.4. Writing Programs

While these basic rules are nearly complete, you will be able to write executable programs after we
cover a few necessary details.

A program is a sequence of Assembler Language statements. The input to the Assembler should
consist of

Chapter III: Assembler Language Programs 79

 1. a START statement,
2. the statements of your program, and
3. an END statement.

The START statement is written

progname START origin
The name-field symbol progname is the name of the program. It will usually have eight or fewer
letters. The origin operand is called the initial location or assumed origin of the program; its
value is used by the Assembler. For now, we will use zero for this initial location. Thus, the first
statement of a program should be something like
TEST START 0 First statement of program TEST
where TEST is the name of your program.

The last statement of the program must be an END statement telling the Assembler to stop
reading records. It is written
END progname Last statement of program
where the progname operand of the END statement should (for now) be the same as the progname
in the name field of the START statement. For our example, we would write
END TEST Begin execution at 'TEST'

The progname in the operand field of the END statement specifies the name of the instruction
where execution should start when the program is loaded into memory. The operand field entry
on the END statement may be omitted, but specifying it is a good programming practice, so we'll
write our sample programs this way.

The Assembler allows no symbol as the name-field entry in an END statement. Assembler Lan-
guage programs, unlike programs in many high-level languages, must not try to terminate exe-
cution by allowing control to reach the END statement. Doing so usually results in some form
of disaster, since the END assembler instruction statement only tells the Assembler to stop
reading records, and is not translated into executable instructions.

The START and END statements, when read by the Assembler, determine the beginning and end
of the statements to be assembled. The START statement may be preceded by a few types of
statements (such as TITLE and comment statements), but for now, assume it is the first state-
ment to be read. The END statement may not be followed by any other statement: it must be
last.

Some programmers like to start their programs with a CSECT (“Control SECTion”) statement
rather than START. It has the same effect, except that no operand field entry is allowed, so you
can't set the initial location or assumed origin value. We'll discuss control sections and the
CSECT instruction thoroughly in Chapter X, Section 38.

6.5. A Sample Program

Figure 33 on page 81 is a little program that prints my name. This set of records is typical of
those required on many System z systems. All statements begin in column 1 and end before
column 72. (The “Line n” comments are used only for this example; you don't need them for
your programs.)

80 Assembler Language Programming for IBM System z™ Servers Version 2.00

─────────────────────────────── 80 characters ────────────────────────────────
//JRETEST JOB (A925,2236067977),'J.EHRMAN' Line 1
// EXEC ASMACLG Line 2
//C.SYSIN DD * Line 3
Test Start 0 First line of program Line 4
Print NoGen Line 5
* Sample Program Line 6
BASR 15,0 Establish a base register Line 7
Using *,15 Inform the Assembler Line 8
PRINTOUT MyName,* Print name and stop Line 9
MyName DC C'John R. Ehrman' Define constant with name Line 10
END Test Last statement Line 11
/* Line 12
Figure 33. A complete Assembler Language program

The first 3 lines and the last are control statements for the Supervisor; they are not part of your
program, and are not read by the Assembler. They tell the operating system to run the Assem-
bler, Linker, and Program Loader, and how to pass your program's statements to the Assembler.
The information on these lines follows the rules of a Job Control Language for an operating
system. Line 1 (the JOB statement) marks the beginning of a job: a unit of work for the com-
puter separate from all other units. Additional information on the JOB statement provides
accounting data such as an account number and a user name.

Line 2 (the EXEC statement) requests that the following program be assembled, linked, and exe-
cuted; Line 3 indicates that records for the Assembler follow immediately. The last line (the “/*”
or “end-of-file” statement) tells the Operating System that no more records are given to the
Assembler.

The Assembler Language program is contained in the remaining lines:

• Line 4 is the assembler instruction statement defining the name of your program as Test and
starts a Control Section to contain the machine language data and instructions of your
program when it is executed by the CPU.
• Line 5 is an assembler instruction statement; it causes the Assembler not to print statements
generated by the PRINTOUT macro-instruction in Line 9. (More about PRINTOUT and other useful
macro-instructions in Section 6.6 on page 82.)
• Line 6 is a comment statement.
• Line 7 is a machine instruction statement.
• Line 8 is an assembler instruction statement. (Lines 7 and 8 are important: we'll discuss them
in Section 10.)
• Line 9 is a macro-instruction statement that causes some data to be printed, and then returns
control to the Supervisor.
• Line 10 is an assembler instruction statement. The Assembler converts the characters enclosed
in the apostrophes into an internal form representing the characters.
• Line 11 is an assembler instruction statement. It tells the Assembler that no further statements
will be processed for this program. The operand field entry Test tells the Linker where you
want your program to begin execution.

Exercises
6.5.1.(1) + Determine what control statements are required at your installation for the following
sequences of steps (if they are available): (1) assembling a program, (2) assembling and linking a
program, (3) assembling, linking, and executing a program, (4) assembling, loading, and exe-
cuting a program, and (5) linking and executing an object module created in a previous
assembly.

6.5.2.(1) At execution time, if control reaches the END statement, will that be the end of the
program?

6.5.3.(1) Examine the Assembler Language program in Figure 33. Which statements have
entries in the name field? In the operation field? In the operand field? In the comment field?

Chapter III: Assembler Language Programs 81

6.6. Basic Macro Instructions
For our sample programs, we need only very simple methods of reading 80-character “card-
image” records, printing strings of characters, displaying useful information, and displaying or
“dumping” areas of memory in hexadecimal format.

Your operating system may provide similar facilities already, but you should check to see how or
whether they differ from these. We will use these six macro-instructions, and show how they're
used in some programming examples.
PRINTOUT Print formatted information about data and registers
READCARD Read 80-byte card-image records
PRINTLIN Print lines of characters
DUMPOUT Dump memory in hexadecimal format
CONVERTI Convert decimal characters to a 32- or 64-bit binary integer
CONVERTO Convert a 32- or 64-bit binary number to decimal characters

The macro instructions and their operands are described in “Appendix B: Simple I/O Macros” on
page 1015.

6.7. Summary
The Assembler provides many facilities to simplify programming tasks.
1. It automatically resolves addresses into the base-displacement and other forms used by
System z. The Assembler determines the needed base and displacement so that correct Effec-
tive Addresses will be calculated at execution time.
2. Rather than remembering that operation code X'43' copies a byte from memory into the
right end of a general register, a mnemonic operation code gives a simple indication of what
the operation code does. (The term “operation code” is often abbreviated “opcode”.) The
opcode X'43' has mnemonic “IC”, which stands for “Insert Character”.
3. Symbols let you name areas of memory and other objects in your program.
4. Diagnostic messages warn you about possible errors and oversights.
5. The Assembler converts data from convenient external representations into internal forms.
6. It creates relocatable object code to be combined with other programs by the linker.
7. Using macro-instructions, you can define your own instruction names to supplement existing
instructions, and your own macro instructions can make use of previously defined sequences
of statements, including other macros!
8. It provides lots of other helpful information such as cross-references of symbols, registers, and
macros.

Terms and Definitions

Assembler
A program that converts Assembler Language statements into machine language, in the form
of an object module.
assembly time
The time when the Assembler is processing your program's statements, as distinct from the
time when the machine language instructions created from your Assembler Language
program are executed by the processor.

82 Assembler Language Programming for IBM System z™ Servers Version 2.00

code
An informal term for groups of Assembler Language statements.
execution time
The time when your program has been put in memory by the Program Loader and given
control. This may happen long after assembly time.
Job Control Language
The statements needed to tell your Operating System how to process your program through
the assembly, linking, and execution phases. “JCL” for short.
Linker
A program that converts and combines object modules and load modules into an executable
“load module” format ready for quick loading into memory by the Program Loader. The
term “Linker” can describe several programs:
Binder
The z/OS program that can generate load modules (and a newer form, program objects)
as well as place the linked program directly into memory.
Linkage Editor
The predecessor to the z/OS Binder; its functions are included in the Binder. A Linkage
Editor is used on z/VSE.
Loader
This can have several meanings:
• On z/VM systems, a program that can link object modules directly into memory for
execution, or generate a relocatable “MODULE”.
• On older OS/360 systems, a program that links object and load modules into
memory for execution; now called the “Batch Loader”.
load module
Our generic name for the output of a Linker; a mixture of machine language instructions and
data ready to be loaded directly into memory for execution.
macro instruction
A powerful means to encapsulate groups of statements under a single name, and then gen-
erate them (with possible programmer-determined modifications) by using the macro-
instruction name as an operation field entry.
mnemonic
A convenient shorthand for the name of an instruction. For example, the “Branch and Save”
instruction has mnemonic “BAS”.
object code
The machine language contents of an object module.
object module
The machine language information created by the Assembler, used as input to the Linker.
operand
(1) Something operated on by an instruction. (2) A field in a machine instruction statement.
origin
A starting value assigned by you (or by the Assembler) needed to calculate offsets and dis-
placements in your program. Because most programs are relocated, it's rarely necessary to
specify an origin.
Program Loader
The component of the Operating System that brings load modules into memory, makes final
relocations, and transfers control to your program.
relocation
A procedure used by the Linker and the Program Loader to ensure that addresses in your
loaded program are correct and usable.
statement
The contents of the records read and processed by the Assembler. There are four types:
comment statements, machine instruction statements, assembler instruction statements, and
macro-instruction statements.

Chapter III: Assembler Language Programs 83

 statement field
One of the four fields of an Assembler Language statement (other than a comment state-
ment). They are the name, operation, operand, and the remarks fields. Which fields are
required and/or optional depends on the specific statement.

Programming Problems
Problem 6.1.(2) + Write, assemble, link, and execute a short program (like the one in Figure 33
on page 81) that will print your name. Look through the printed output from the job, and
determine which parts were printed by the Assembler, the Linker, and the executed program. (If
your name contains apostrophes (like O'Brien), you must type a pair of them wherever you
want to print one, as in O''BRIEN.) Observe what is produced by the Assembler for each type
of statement.

Problem 6.2.(2) + Using your solution to Problem 6.1 as a template, write and execute a
program that will generate a noncontroversial, culturally-sensitive, nonpolitical message such as
Message = C'Hello, World!'

84 Assembler Language Programming for IBM System z™ Servers Version 2.00

7. Self-Defining Terms and Symbols

777777777777
777777777777
77 77
77
77
77
77
77
77
77
77
77

We now investigate two important features of the Assembler Language, self-defining terms and
symbols. Each has a numeric value. In a self-defining term, the value is constant and inherent in
the term, so you can think of them as different ways to write numbers. Self-defining terms are not
data! They are just numbers that can be written in any of several convenient forms; they all result
in 32-bit integer values. Symbols have values assigned by you and by the Assembler.

7.1. Self-Defining Terms

There are four46 basic types of self-defining term: decimal, hexadecimal, binary, and character. The
value of each is treated by the Assembler as a 32-bit two's complement number.
• A decimal self-defining term is an unsigned string of decimal digits. 12345, 98, and 007 are
examples of decimal self-defining terms. The size of a decimal self-defining term is determined
by the fact that 32 bits are allotted by the Assembler to hold its value during assembly.
Because it is unsigned, a decimal self-defining term must lie in the range from 0 to + 231 − 1
(2147483647). Thus, + 2147483647 and − 2147483647 are not valid decimal self-defining terms
because they are signed, even though their values can be correctly represented in 32 bits.
• A hexadecimal self-defining term is written as the letter “X”, an apostrophe, a string of
hexadecimal digits, and a second apostrophe. X'123456', X'FACED', and X'001B7' are examples
of hexadecimal self-defining terms. The value of a hexadecimal self-defining term must lie in
the range from 0 to + 232 − 1, or, between X'00000000' and X'FFFFFFFF'. If fewer than eight
digits are specified, the Assembler assumes that the omitted digits are high-order zeros. If the
high-order digit of an eight-digit hexadecimal self-defining term lies between X'8' and X'F', the
value of the term is negative.
Because hexadecimal terms represent just a string of bits, their value can be greater than
231 − 1, unlike decimal terms.
• A binary self-defining term is written as the letter “B”, an apostrophe, a string of binary digits,
and a second apostrophe. B'110010', B'0001', and B'1111111100001100' are examples of
binary self-defining terms. Because 32 bits are allotted for the value of a self-defining term, at
most 31 binary digits may follow the first 1-bit. (For example,

46 A fifth type of self-defining term, the Graphic type, requires invoking the Assembler with the DBCS option. Its use is
beyond the scope of this section, but we'll meet it again in Chapter VI, Section 26.4.

Chapter III: Assembler Language Programs 85

 B'00000000000000001000000000000000000000000' has 41 digits, but only 24 significant digits
follow the first 1.) If fewer than 32 digits are specified, the Assembler assumes that the
omitted digits are high-order zeros.
The value of a binary self-defining term must lie in the range from 0 to 232 − 1. The value of a
binary self-defining term is negative if the leftmost significant bit of the 32-bit digit string con-
tains a 1-bit.
We will see in Chapter 4 that embedded blanks can be used in decimal, binary, and hexadecimal
constants to improve readability. However, embedded blanks cannot be used in self-defining
terms of those three types.
• A character self-defining term is written as the letter “C”, an apostrophe, a string of up to four
characters (except for two special cases to be described momentarily), and a second apos-
trophe. Thus, C'A', C'...', and C'A•B' are valid character self-defining terms. (Remember
that we are using “•” to represent a blank.) This last example, in which a blank appears, is
the one exception to the rule mentioned in the previous section that stated that the operand
field is terminated by the first blank column after it starts: if the blank is part of a character
string enclosed in apostrophes, as in a character self-defining term, it doesn't terminate the field
but is part of the operand. A blank terminating the operand field must appear outside of a
character string enclosed in apostrophes.
The two special cases concern the apostrophe (') and the ampersand (&). Since apostrophes
are used to delimit the character string, we need a way to get an apostrophe into the generated
character string. (The ampersand has special uses in macro-instructions.) We represent a
single apostrophe or ampersand in a character string by a pair of apostrophes or ampersands.
A character self-defining term containing a single apostrophe or a single ampersand is written
C'''' or C'&&'. This can lead to cryptic but valid forms like C'''''''' (for the three charac-
ters ''', giving a term with value X'007D7D7D'), and and C'&&''&&' (for the three characters
&'&, giving a term with value X'00507D50'). A pair of apostrophes is entered as two characters,
and should not be confused with the quotation mark (″), which is a single character.47

Character self-defining terms use the EBCDIC character representation described next.

Exercises
7.1.1.(2) + Which of the following are valid self-defining terms? If you think a term is invalid,
explain why; otherwise, give the hexadecimal value of the term.
(1) 00000012345
(2) B'10101010101010101'
(3) X'0000B4DAD'
(4) X'B4DAD0000'
(5) +65535
(6) B'000000000001111000011110000111101'
(7) B'101011010001111000011110000111101'

7.1.2.(1) The maximum value of a decimal self-defining term is 231 − 1, while the maximum
value a binary or hexadecimal self-defining term is 232 − 1. Why are they different?

47 Unfortunately, people sometimes call the apostrophe or single quote a “quotation mark” or “single quotation mark”.
Calling a quotation mark a “double quote” or “″” doesn't help either, because it might be understood to mean a pair
of apostrophes.

86 Assembler Language Programming for IBM System z™ Servers Version 2.00

7.2. EBCDIC Character Representation
The value assigned to a binary, decimal, or hexadecimal self-defining term is clear, as they are
familiar bit patterns. But what value should we give to a character self-defining term? This
depends on the internal representation or code defined for characters. We could decide that the
value of C'A' should be the same as X'0A', or X'41', or X'74', or X'A1', or even X'C1'.

In System z the conventional character code is called the “Extended Binary Coded Decimal Inter-
change Code”, or EBCDIC for short. 48 Each character is represented internally by an eight-bit
number — two hexadecimal digits — as indicated in Table 13. The internal bit patterns that repre-
sent external characters are a matter of choice; any mutually agreeable set is about as good as any
other. The Extended BCD code, or EBCDIC, is the code defined by the designers of System/360
for communicating with character-sensitive components of the computer such as the CPU,
printers, graphic display devices, etc. We will see other important character encodings in Chapter
IV, Section 12.8, and again in Chapter VII, Section 26.

This table shows the EBCDIC representation used by the Assembler, “Code Page 037”. (There
are many other EBCDIC code pages used around the world.)

Table 13. Assembler Language EBCDIC character representation

Char Hex Char Hex Char Hex Char Hex
Blank 40 e 85 y A8 S E2
. 4B f 86 z A9 T E3
( 4D g 87 A C1 U E4
+ 4E h 88 B C2 V E5
& 50 i 89 C C3 W E6
$ 5B j 91 D C4 X E7
* 5C k 92 E C5 Y E8
) 5D l 93 F C6 Z E9
- 60 m 94 G C7 0 F0
/ 61 n 95 H C8 1 F1
, 6B o 96 I C9 2 F2
_ 6D p 97 J D1 3 F3
# 7B q 98 K D2 4 F4
@ 7C r 99 L D3 5 F5
' 7D s A2 M D4 6 F6
= 7E t A3 N D5 7 F7
a 81 u A4 O D6 8 F8
b 82 v A5 P D7 9 F9
c 83 w A6 Q D8
d 84 x A7 R D9

In Table 13 we see that the value associated with the character self-defining term C'/' is the same
as that of the hexadecimal self-defining term X'61', the binary self-defining term B'1100001', and
the decimal self-defining term 97. Similarly, the character self-defining term C'''' has the same
value as the hexadecimal self-defining term X'7D', and C'&&' has the same value as X'50'. Which
type of term you choose is largely a matter of context; in some places, certain types will be more
natural than others.

48 Occasionally it is even called BCD. That term is normally used to denote an older six-bit character code or even a
4-bit encoding of decimal digits; the eight-bit Extended BCD code is used to represent characters on System z.

Chapter III: Assembler Language Programs 87

 The value of a character self-defining term is determined by right-adjusting the EBCDIC codes of
the characters in a 32-bit field, and filling with zero bits at the left end if needed. Thus, the value
of C'A' is X'000000C1', and the value of C'ABC' is X'00C1C2C3'.49

The characters shown in Table 13 on page 87 are the portion of the EBCDIC character set used
in the Assembler Language (except in character self-defining terms and character constants, where
all 256 possible characters are allowed). The codes for other characters are defined in the
z/Architecture Principles of Operation. It is worth remembering that the EBCDIC code for a
blank space is X'40'.

Exercises
7.2.1.(2) + Which of the following are valid self-defining terms? If you think a term is invalid,
explain why; otherwise, give the hexadecimal value of the term.
(1) C'#@$'
(2) C'''''
(3) C'•A•B' (one leading blank)
(4) C'RUD'
(5) C'12'
(6) C'•••12' (three leading blanks)

7.2.2.(2) + Give (in hexadecimal) the value of each of the following character self-defining terms:
(1) C'&&', (2) C'75', (3) C'''', (4) C'C''', (5) C'0', (6) C'SDT'.

7.2.3.(3) Another widely used character representation is the United States of America Standard
Code for Information Interchange, or ASCII. Determine the ASCII representation of the char-
acters in Table 13 on page 87.

7.2.4.(2) + Give (in hexadecimal) the value of each of the following self-defining terms:
(1) C'''''''', (2) 1000, (3) B'01000', (4) C'&&''&&', (5) C',', (6) C'A=B'.

7.2.5.(3) + For each of the following values, display all four self-defining terms that may be used
to represent it. (1) 64, (2) 245, (3) C'&&', (4) X'405C', (5) X'F9F9F9F9',
(6) B'110001011101100111010001'.

7.2.6.(1) What EBCDIC character would be represented by the bit pattern in the byte illus-
trated in Figure 6 on page 43?

7.2.7.(1) Show the hexadecimal value of each of the following self-defining terms:

(1) B'110010110000010111010110'
(2) C'A&&B'
(3) 54721
(4) X'B00B00'

7.2.8.(1) Consider the 16 bits 1101000111000101:

1. Write them as four hexadecimal digits.

2. Assuming the bits represent an unsigned (logical) binary number, give its value.
3. Assuming the bits represent a signed binary number in the two's complement represen-
tation, give its value.
4. Write them as two EBCDIC characters.

7.2.9.(1) Give the hexadecimal value of these self-defining terms:

49 In some cases, you might want to use a different character set in character terms. It is possible that the Assembler
might assume that your characters are represented in EBCDIC, and generate the wrong value. If you specify the
TRANSLATE and COMPAT(TRANSDT) options, Assembler will use your chosen representation for character
terms. (See the High Level Assembler Programmer's Guide for details.)

88 Assembler Language Programming for IBM System z™ Servers Version 2.00

 1. B'110010111000010111011001'
2. C'R&&Z'
3. 51401

7.2.10.(2) + Give the value in hexadecimal of these self-defining terms:

(1) B'01110101100010'
(2) C'''+'
(3) 10010

7.3. Symbols and Attributes

Many programming problems can be greatly simplified by using symbols. If this were not so, we
might try to dispense with Assemblers and be content with producing programs consisting of
strings of hexadecimal digits; thus we would write the hex digits X'580064EC' instead of a machine
instruction statement containing symbols.

Symbols are more interesting than self-defining terms: they let you assign meaningful names to
parts of your program. You can give the name PLUS1 to an area containing the constant +1, and
the name READ to an instruction that reads data.

Three types of symbols are used in the Assembler Language: ordinary symbols, variable symbols,
and sequence symbols. The last two are used only in macro-instructions and in conditional
assembly, so we won't say more about them here.

There are two types of ordinary symbols: internal and external. External symbols are used during
linking to communicate with other programs (and are part of the object module, as we'll see in
Chapter X, Section 38), while internal symbols are used only during the assembly, and do not
appear in the object module. 50

For now, we assume that all symbols are internal symbols. A word of caution: if you have done
some programming in a high-level language, you may be inclined to think of symbols as variables.
They aren't; the differences are described in Section 7.7 on page 94.

A symbol is a string of letters or digits, the first of which must be a letter. The characters “$”,
“_”, “#”, and “@” are considered to be letters in the Assembler Language.51 These special charac-
ters are not allowed in symbols:
( ) + - * / = . , ' & blank

Early Assemblers restricted symbols to at most eight characters, which is why the “customary”
operation field of a statement begins in column 10. HLASM allows mixed-case symbols up to 63
characters long, but there is no difference between upper and lower case letters. Thus, NAME, Name,
and name all refer to the same symbol.

The following are all valid symbols.

A Agent086 A1B2D3C4 _The_End
#235 O0@H ApoPlexy The_Utter_Final_Bitter_End
James KQED Prurient EtCetera
$746295 Wonka ZYZYGY99 Close_Files

50 Internal symbols are added to the object module if you specify the Assembler's TEST option, but that option is little
used now. The ADATA option is preferable, because it generates a SYSADATA “side file” containing much more
useful information that can be used by other programs like debuggers.
51 If there's any chance your program might be sent (or read or printed) outside the United States, avoid the “national”
characters #, @, and $. They may look different in other countries, or may even have different EBCDIC representa-
tions. Other characters usable in Assembler Language symbols — those in Table 13 on page 87 — always have the
same EBCDIC representations.

Chapter III: Assembler Language Programs 89

 Note that the first character of the symbol OO@H must be the letter “O” and not the digit zero “0”.
(A good reason to avoid using symbols starting with the letter O!)

The following are not valid symbols, for the reasons given.
$7462.95 (decimal point not allowed)
Bond/007 (special character / not allowed)
Set Go (no blanks allowed)
Ten*Five (contains the special character *)
C'Wonka' (no apostrophes allowed)
2Faced (doesn't begin with a letter)
An_Absurdly_Long_Symbol_With_No_Use_Other_Than_To_Illustrate_Excessive_Symbol_Length (!)

Several numeric quantities called attributes are associated with a symbol. Symbols have six
primary attributes: value, relocation, length, type, scale, and integer.52 Of these, the value and
length attributes are most important; the rest will be described as needed. The length attribute is
especially useful, and we'll see how it's defined when we examine constant definitions in Section
11.
• The Assembler assigns numeric values to the attributes of a symbol when it encounters the
symbol as the name field entry in a statement. We say that a symbol has been defined when
numeric values have been given to its value, relocation, and length attributes. These three attri-
butes, like all other numeric attribute values, are always nonnegative.
• This terminology is clumsy: rather than the “numeric value of the value attribute” of a
symbol, we simply say the “value of the symbol”. Similarly, the “numeric value of the relo-
cation attribute” of a symbol is its “relocatability”. We say that a symbol whose relocation
attribute is nonzero is relocatable, and a symbol whose relocation attribute has a zero value is
not relocatable, or that it is absolute.53
• We call the “numeric value of the length attribute” of a symbol its “length attribute”. It
depends on the type of statement named by the symbol. Occasionally someone refers to the
“length” of a symbol when its length attribute is meant; but the length of a symbol might be
misunderstood to mean the number of characters in the symbol itself, which is rarely inter-
esting. The length attribute is different, and is very useful.
For example, while the symbol A is one character long, it could have length attribute 133!

Symbols are used mainly as names of places in the program. For example, in Figure 30 on
page 78, the symbol LOAD is the name of the instruction. Similarly, in the machine instruction
statement
GETCONST L 0,4(2,7)
the symbol GETCONST is the name of an area of the program containing a machine instruction. In
the Assembler instruction statement
TEN DC F'10'
the symbol TEN is the name of a word area of the program where the Assembler will place a
binary integer constant with decimal value 10.

In the macro-instruction statement

EXIT RETURN (14,12),T
the symbol EXIT names the area of the program containing the set of instructions generated by
the RETURN macro-instruction.

52 Conditional assembly supports additional attributes: Assembler, Count, Number, Defined, Opcode, and Program.
The Assembler, Opcode, and Type attributes have nonnumeric values.
53 A useful definition of the relocation attribute is that a symbol that names a place in a program is relocatable; details
are given in Section 7.6 on page 93. A convenient image is to think of the relocation attribute of a symbol as its
color: the Assembler assigns the same color to all symbols having the same relocation attribute, and no color to
absolute symbols.

90 Assembler Language Programming for IBM System z™ Servers Version 2.00

 No symbol can be given a value in a comment statement.

Remember: the attributes of the symbols, and the symbols themselves, exist only at assembly
time. They help in producing the object program; internal symbols and their attributes are dis-
carded when the assembly is complete.54

Exercises
7.3.1.(2) + Which of the following are valid symbols? If you think a symbol is invalid, explain
why.
(1) SuperBOY
(2) Captain Major
(3) KillerWhale
(4) Send400$Soon
(5) #@$!
(6) 4Hundred$Sent
(7) ?
(8) (Eight)
(9) @9AM

7.3.2.(2) Some Assemblers (for processors other than System z) allow you to define a symbol
as a string of alphanumeric characters at least one of which must be a letter (it needn't be the
first character). Can you think of any reasons why the designers of the Assembler Language
decided not to allow this form of symbol?

7.4. Program Relocatability

Understanding the value and relocation attributes of a symbol is usually not very important. You
can write lots of Assembler Language programs without ever having to know how and why the
Assembler uses these attributes. When things go wrong (and because things will go wrong), it is
worth understanding some basic features of value and relocation.

The most important part of the Assembler's task of converting a program from Assembler Lan-
guage statements to machine language code is determining the relative positions of all parts of
your program. To do this, the Assembler constructs an accurate model of the program as it will
eventually reside in memory when it is executed.

This model is necessarily incomplete, for two reasons:

1. The Assembler normally has no way to know where the program will eventually be placed in
memory by the Program Loader.
2. There is no way for the Assembler to know the relationship of the program it is assembling
to other programs that will be combined with it in the load module produced by the Linker.
Methods for handling the second reason will be treated when we discuss external linkages and
subroutines in Chapter X, Sections 37 and 38.

Because the Assembler cannot determine in advance what memory addresses will eventually hold
the program, it must produce a machine language program that will work correctly no matter
where it is placed at execution time. That is, the program must be relocatable. Thus, in building
its model of the final form of the program, the Assembler only needs to determine the relative
positions of the parts of the program it is assembling.

The Assembler doesn't know where the program will eventually be placed in memory, so it does
the next best thing:

54 This information can be saved in a SYSADATA “side file” when you specify the Assembler's ADATA option.

Chapter III: Assembler Language Programs 91

 1. It assumes that the program starts at some arbitrary (or programmer-specified) origin, and
generates instructions and data based on that assumption.
2. It includes enough information about its assumptions in the object module, so the Linker
and the Program Loader can tell (a) what starting location was assumed, and (b) what parts
of the program will contain or depend on actual memory addresses at the time the program is
executed.
3. By computing the difference between the program's assembly-time starting location assumed
by the Assembler, and its true starting address assigned at execution time by the Supervisor,
the Program Loader can supply (“relocate”) the necessary true addresses used at execution
time.

In practice, very few parts of a program depend on knowing actual addresses; these will almost
always involve the use of address constants; we'll introduce them in Section 12.2 on page 147.
Many programs can be written to contain no address-dependent information.

7.5. The Location Counter

To help clarify the differences between assembly and execution times, we will make a careful and
important distinction between locations and addresses.
• Locations refer to positions in the Assembler's model of the program at assembly time.
• Addresses refer to the positions in memory, at execution time, where the various parts of the
program reside.

Locations and Addresses

Locations are used at assembly time; addresses are used at execution time.

The relationship between locations and addresses is close; they differ at most by a single constant
value, the difference between the Assembler's assumed assembly-time starting location and the
Supervisor's assigned execution-time starting address. This difference is handled by the Program
Loader when it relocates the program just before execution, so we don't have to worry about this
at assembly time. 55
To assign locations to the various parts of your program as it is assembled, the Assembler main-
tains an internal counter called the Location Counter, or LC. The initial value of the LC is the
“initial location” or “assumed origin” specified on the START statement (see Section 6.4 on page
79); or, if no initial location is specified, the Assembler assigns an initial LC value of zero.
As the Assembler reads your program, it determines how many bytes will be required in the
program for the instruction or data generated for each statement. It adds this number to the LC,
and then reads and processes the next statement. In this way, the Assembler determines the
location and length of each part of the program.
It is important to understand the difference between the Assembler's Location Counter and the
CPU's Instruction Address. The LC is a counter used by the Assembler at assembly time to
determine positions within a program; it goes away when the Assembler is removed from memory
at the completion of an assembly. The IA is a part of the CPU's PSW, and contains the address
of the next instruction to be fetched at execution time; it is always in use whenever any program is
being executed.

55 The Assembler puts the assumed origin into the object module to help the Linker adjust addresses correctly.

92 Assembler Language Programming for IBM System z™ Servers Version 2.00

 Exercises
7.5.1.(3) + In the following program segment, determine (1) the value attributes of all symbols,
and (2) the LC value at the time each statement is read by the Assembler. The length of the
generated instructions and data are given in the comment field of each statement.
EX7_5_1 START X'5000' 0 bytes generated
BASR 6,0 2 bytes generated
BEGIN L 2,N 4 bytes generated
A 2,ONE 4 bytes generated
ST 2,N 4 bytes generated
DUMMY DS XL22 22 bytes generated
N DC F'8' 4 bytes generated
ONE DC F'1' 4 bytes generated
We will revisit this program fragment in Section 10.

7.6. Assigning Values to Symbols

Instructions and data are given names by writing symbols as the name field entry of the state-
ment. When the Assembler encounters such a symbol, it enters it into a Symbol Table containing
the program's symbols and their attributes.
1. The value attribute (or simply, the value) of the symbol is determined from the contents of
the LC at the time the statement was processed, before adding the length of the generated
instruction or data.
2. The relocation attribute will be nonzero, to indicate that the symbol is relocatable. (We will
see shortly how to define absolute symbols that are not relocatable.)
3. The length (in bytes) of the generated instruction or data is assigned as the value of the length
attribute (in most cases).

There are, of course, occasional minor exceptions to these general rules.

There is a simple test to determine whether an internal symbol is relocatable: add a constant to
the initial value of the LC, and re-assemble the program. If the value of the symbol increases by
exactly the same amount, then the symbol is relocatable. If the value doesn't change at all, the
symbol is absolute.

The names of instructions and data areas in a program are relocatable; these are the most frequent
uses of symbols. The numeric value of the relocation attribute of a symbol is assigned by the
Assembler, and can be determined from the Assembler's External Symbol Dictionary, another part
of the object module.

To illustrate how values are assigned to symbols, suppose that when the statement named
GETCONST (on page 90) is read by the Assembler, the value of the LC is X'0007B6'. Then the
symbol GETCONST would appear in the Symbol Table with value X'0007B6'; it would be relocat-
able; and because the statement specifies an RX-type instruction, the length attribute will be 4.
Before reading the next statement, the Assembler increments the LC by the length of the instruc-
tion, so that its value will then be X'0007BA'.

Similarly, if the sample statement named TEN (on page 90) was encountered when the LC value
was X'012D88', then the value of the symbol TEN would be X'012D88'; it would be marked as
relocatable; and its length attribute would be 4. The LC value after incrementing would be
X'012D8C'.

To define an absolute symbol, we use the “EQU” assembler instruction statement:

symbol EQU self-defining term
This statement causes the value of the self-defining term to be assigned as the value attribute of
the symbol. (More about the EQU assembler instruction is in Section 13.3.) Thus, the statement

Chapter III: Assembler Language Programs 93

 ABS425 EQU 425
defines the symbol ABS425 by assigning a value of 425 (X'000001A9'), a relocation attribute of
zero, and (for want of anything better) a length attribute of one. The symbol ABS425 is simply the
name of a number!

Absolute symbols give you great freedom and flexibility in writing your programs. We will find
many ways to use absolute symbols whose values do not change if the initial LC value is changed.

Exercises
7.6.1.(1) Why can a symbol not be given a value in a comment statement?

7.6.2.(1) The symbol TEN on page 89 will be assigned a length attribute of 4 by the Assembler.
What is the length of the symbol?

7.7. Symbols and Variables

In Assembler Language, we make some important distinctions in terminology. In high-level lan-
guages such as FORTRAN, COBOL, PL/I, and C, symbols are normally used to name variables:
you can assign new values to them as the program executes. Thus, you might write
BAD = GOOD + 7*(LOG(BETTER)/SQRT(BEST)) ; /* Assign new value to BAD */
and understand it to mean “evaluate the quotient of the results of the LOG and SQRT functions,
multiply that by 7, add the result to the current value of the variable GOOD, and assign the result as
the new value of the variable BAD.” Assembler Language doesn't work this way! The value of a
symbol is not the value of a variable of the same name.

Assembler symbols
Assembler Language symbols are not variables. There are no “variables”
in the Assembler Language we're describing!56

Some of the differences in the meanings of symbols in high-level languages and Assembler Lan-
guage are shown in Table 14.

Assembler Language High-Level Languages

Used only at assembly time Can be thought of as existing at execution
time
Names of places in a program Contain execution-time values
Contents of memory has a “value” Variable has a “value”
The name has a “location” value used by the The name is thought of as naming the value of
Assembler to lay out and organize the program a variable
Table 14. Differences between Assembler Language and high-level language symbols

We will have more to say about this in Section 13.8 on page 173.

56 The conditional assembly language does have variable symbols, but that topic is beyond what we're discussing now.

94 Assembler Language Programming for IBM System z™ Servers Version 2.00

Terms and Definitions
defined symbol
A symbol is defined when the Assembler assigns values to its value, relocation, and length
attributes.
EBCDIC
Extended Binary Code Decimal Interchange Code. Used to assign numeric values to charac-
ters. There are many EBCDIC encodings; they assign different values to some characters, but
all the alphabetic, numeric, and other characters used in the Assembler Language listed in
Table 13 on page 87 are invariant across EBCDIC encodings, except for the characters “$”,
“@”, and “#”.
Location Counter (LC)
A counter used by the Assembler at assembly time to build its model of the relative positions
of all components of an assembled program.
relocatable
A property of a program allowing it to execute correctly no matter where it is placed in
memory by the Program Loader.
relocation
Actions performed by the Linker and Program Loader to ensure that a program in memory
will execute correctly no matter where it is loaded. This may require assigning true execution-
time addresses to parts of a program.
self-defining term
One of binary, character, decimal, and hexadecimal. Its value is inherent in the term, and
does not depend on the values of other items in the program.
symbol
A name known at assembly time, to which various values are assigned. The values may be
absolute or relocatable (or even complexly relocatable, as we'll see in Section 8.3).
symbol attribute
Useful information about the properties of a symbol. Attributes include value, relocation,
length, type, scale, and integer. (Only the first three attributes are important for our current
needs.)

Chapter III: Assembler Language Programs 95

8. Terms, Operators, Expressions, and Operands

8888888888
888888888888
88 88
88 88
88 88
88888888
88888888
88 88
88 88
88 88
888888888888
8888888888

In this section we will see how to specify components of the operand field entry of various
instruction statements.

The operand field entry of a typical machine instruction statement is a sequence of operands sepa-
rated by commas. For example, a typical instruction statement might look like this:

symbol operation operand1,operand2,... optional remarks

where the name field symbol is often optional, and the operand field may specify zero to many
operands.

The operands are formed from expressions that are in turn formed by combining terms and opera-
tors.

8.1. Terms and Operators

The basic elements of an expression are terms. They can be any of the following items:
• aself-defining term
• asymbol
• aLocation Counter reference
• aliteral
• aSymbol Attribute reference
− Length
− Integer
− Scale
We will discuss Integer and Scale attributes later; while they aren't used frequently, they can be
very helpful in certain situations.

96 Assembler Language Programming for IBM System z™ Servers Version 2.00

 Terms
Length, integer, and scale attribute references to a symbol are always
absolute terms; a symbol can be either absolute or relocatable; literals
and Location Counter references are always relocatable. A self-defining
term is always absolute.

We have seen how to write symbols and self-defining terms. Literals are special symbols that
provide a convenient way to write constants, and we will discuss them in Section 12.6.
A Location Counter reference is written as a single asterisk; it has the attributes of the Assem-
bler's Location Counter, and a length attribute that depends on the type of statement where it is
used. The value of * as a Location Counter reference therefore changes during an assembly as the
LC value changes.
A symbol length attribute reference is written as a letter L followed by an apostrophe followed by
a symbol (or an asterisk, for a Location Counter reference).
L'SYMBOL or L'*
is an absolute term whose value is the length attribute of the term following the apostrophe.
The operators used for combining terms are + , − , *, and /, indicating addition, subtraction, mul-
tiplication, and division respectively. A term has no sign; however, + and − may be used as
unary or prefix operators, as in +5. In Assembler Language, the asterisk is therefore used in two
ways: to denote a Location Counter Reference and as the multiplication operator. The Assem-
bler can distinguish these two uses.

8.2. Expressions
An expression is an arithmetic combination of terms and operators. In the absence of unary plus
or minus signs or parentheses, an expression must begin and end with a term, and there must be
an operator between each pair of terms. To illustrate, two expressions are
GETCONST+X'4A' and X+L'X
The following expression uses all four types of self-defining term:
X'12'+C'.'-B'0001010001'+7

Parentheses may be used, as in ordinary mathematical use (and as in familiar procedural lan-
guages) to indicate groupings. In evaluating expressions, an expression in parentheses is treated as
a term. Thus
(A+2)*(X'4780'-JJ)
is an expression that is the product of two subexpressions, each of which has two terms and one
operator.

Syntactically, an expression may not contain two multiplication or division operators in suc-
cession, or an addition or subtraction operator followed by a multiplication or division operator.
For example:
*+2 valid because * is a Location Counter reference
-A, +A are valid uses of unary + and -
A++B, A--B, A+-B, A-+B are valid (second + and second - are unary operators)
A/+B, A/-B, A*+B, A*-B are valid (+ and - are unary operators)
A+/B, A-/B, A+*B, A-*B are invalid
A**B, A*/B, A/*B, A//B are invalid

Some syntactically valid expressions might not be evaluatable if either or both terms is relocatable
(to be described shortly).

Chapter III: Assembler Language Programs 97

 An easy way to determine the validity of expressions with sucessive operators is to parenthesize
each operator with its immediately following term, so that A++B becomes A+(+B); because the
unary + in (+B) is equivalent to B, A++B is evaluated as A+B. (See Exercise 8.2.3.)

Exercises
8.2.1.(2) What would you expect to be the result of A--B, A+-B, and A-+B?

8.2.2.(1) What is the value of the expression X'12'+C'.'-B'0001010001'+7?

8.2.3.(2) + Determine the syntactic validity of each of the following expressions; and if the
expression is valid, show its simplified form.
a. A+-+-B
b. A*--B
c. A-*-B
d. A---B
e. --A-++B

8.3. Evaluating Assembly-Time Expressions (*)

The rules for evaluating expressions are familiar, with one or two minor exceptions, so it's no
surprise that the Assembler evaluates 2+3 as 5.

Remember: we are describing the Assembler's evaluation of assembly-time expressions involving

the values of assembly-time symbols and other terms. This is entirely different from most high-
level languages, where an expression like A+B in a statement is evaluated at execution time, using
the values of the execution-time variables A and B.

The details of the rules can be rather complicated, so don't try to grasp everything on a first
reading. The examples on page 100 will help to illustrate the rules.
1. Each term (along with any preceding unary operator) is evaluated to word precision, 32 bits.
The relocation attribute of each term is noted, so that the relocation attribute of the entire
expression can be evaluated also, as described in rule 10 below.
2. Inner parenthesized subexpressions are evaluated first, using 32-bit two's complement arith-
metic. The resulting value is used in computing the rest of the expression. Thus in
(X'100'+2*(ABS425-420))+1
where ABS425 has value 425 (as defined on page 93), the subexpression (ABS425-420) would be
evaluated first. The value of the whole expression is X'0000010B', and is absolute.
3. Multiplications and divisions are done before additions and subtractions. Thus the value of
the expression just given would be evaluated as (X'100'+(2*(5)))+1 and not as
((X'100'+ 2 ) * ( 5 ) ) + 1 . Multiplication and division operators may not be combined, as in /*
and */.
4. Relocatable terms or subexpressions may not occur in multiplication or division operations.
5. Operations are performed in left-to-right order within a group of operations of the same pri-
ority. Thus 5*2/4 means the same as (5*2)/4, not 5*(2/4); similarly, 5/2*4 means the same as
(5/2)*4, not 5/(2*4).
6. Multiplications yield a 64-bit result, of which the rightmost 32 bits are kept, and the high-
order (leftmost) 32 bits are discarded. Significant bits can be lost if the product is too large.
7. Division always yields an integer result; the Assembler always discards remainders when eval-
uating expressions. Thus 5*2/4 has value 2, and 5*(2/4) has value zero. Division by zero is
permitted, and the result is simply set to zero.

98 Assembler Language Programming for IBM System z™ Servers Version 2.00

 8. Negative quantities are carried in two's complement representation.
9. When the expression has been completely evaluated, the result is in 32-bit two's complement
form.
10. The relocation attribute of the result is found as follows; assume that the symbol A is relocat-
able:
• If there is an even number of relocatable terms appearing in the expression and they are
paired (that is, they have the same relocation attribute appearing with opposite signs) so
that a change in the relative origin assigned to the program has no effect on the value of
the expression, then the expression is absolute. For example, A-A+2 is an absolute
expression with value 2.
• If there is one remaining unpaired term not directly preceded by a minus sign, then the
expression is simply relocatable, and it has the relocation attribute of the unpaired term.
For example, A+2 is a simply relocatable expression.
• If there is more than one remaining unpaired relocatable term, or if the remaining term is
preceded by a minus sign, the expression is complexly relocatable. Intentional use of
complexly relocatable symbols is extremely rare. For example, 2-A is a complexly relocat-
able expression. (Some later examples will show how complex relocatability can happen,
so don't worry if this seems obscure.)

In general, you can determine the relocatability of an expression roughly as follows: first, compute
the value of the expression. Second, add some constant to the initial value of the LC, which will
cause the values of relocatable symbols to change. Third, recompute the value of the expression
using the new values of the symbols. If the new value of the expression is identical to the old
value, the expression is absolute; if the values differ by the amount added to the LC, the
expression is simply relocatable; otherwise it is complexly relocatable.

To summarize the rules for combining terms, let A and R represent respectively an absolute and a
simply relocatable expression. The rules for combining terms are summarized in Table 15.

An expression of this form is

A+A, A-A, A*A, A/A absolute
R+A, R-A, A+R simply relocatable
R+R, A-R complexly relocatable
R*A, A*R, R/A, A/R, R*R, R/R forbidden
R-R absolute or complexly relocatable
Table 15. Expressions with absolute and relocatable terms

R − R is absolute only if both expressions have the same relocation attribute. Because this will
almost always be true, we assume (until further notice) that expressions of the form R − R are
absolute. We'll give a precise definition of the relocation attribute in Chapter X when we discuss
external symbols.

Machine instruction statement operands may never be complexly relocatable.

Exercises
8.3.1.(2) + Suppose R stands for an arbitrary relocatable expression, and A stands for an arbitrary
absolute expression. State which of the following expressions are and are not valid in machine
instruction statement operands.
(1) R+R (2) A+R (3) R+A (4) A+A (5) R-R (6) A-R (7) R-A (8) A-A
(9) R*R (10) A*R (11) R*A (12) A*A (13) R/R (14) A/R (15) R/A (16) A/A

8.3.2.(2) Rule 7 on page 98 states that the Assembler always discards remainders in evaluating
expressions. Does this mean that a program cannot compute a remainder? Explain.

8.3.3.(2) + The last row of Table 15 says that R-R can be complexly relocatable. How can the
difference of two simply relocatable symbols be complexly relocatable?

Chapter III: Assembler Language Programs 99

8.4. Examples
For these examples, we assume that
• ABS425 is an absolute symbol of value 425 (or X'000001A9'),
• the value of the Location Counter is X'00011D46',
• REL1 is a relocatable symbol of value X'00010A20',
• REL2 is a relocatable symbol of value X'00012345' having length attribute 6, and
• The Location Counter, REL1, and REL2 have the same relocation attribute.

1. 5*2/4 = 10/4, an absolute expression of value X'00000002'.

2. 16*16*16*16*16*16 is an absolute expression of value X'01000000'.
3. 6-ABS425 has value X'FFFFFE5D', and is absolute.
4. (REL2-REL1)/(ABS425-B'011111') is an absolute expression of value X'00000010'.
5. REL2+C'-'+*+L'REL2-* is a relocatable expression of value X'000123AB'.
6. 2*REL2-REL1 is an invalid expression, because a relocatable term (REL2) occurs in a multiply
operation. (If the Assembler was able to evaluate the expression, it would be simply relocat-
able, and have value X'00013C6A'.)
7. Even REL1*1 and REL1*0 (as well as REL1/1 and REL1/0) are invalid expressions, even though
their values are perfectly well defined.
8. (1+(1+(1+(1+(1+(1+(1+(1+2)*2)*2)*2)*2)*2)*2)*2)+1 is an absolute expression, and has
value X'200'.
9. *+6 is a relocatable expression of value X'00011D4C'.
10. (REL2-*)*L'REL2 is an absolute expression of value X'000023FA'. Note the two distinct uses of
the asterisk!

The example of a machine instruction statement in Figure 30 on page 78 could have been written
LOAD LR C'45'-(7*X'2A36')+ABS425*B'11111'-235,18/(Q-Q)+3
though the gain in clarity is not obvious. More reasonable usage is illustrated in the following
statements.
* EXAMPLE 8_4_1
R7 EQU 7
R3 EQU 3
LOAD LR R7,R3

There is a difference between

1. the notational convenience of the symbol R7 defined in the first EQU statement above and
intended to mean general register 7,
2. the definition of an absolute symbol R7 to have the value 7, and
3. the use of the symbol as an operand in the operand field entry of a machine instruction state-
ment where the use of register 7 is intended.

Example 8_4_1 is equivalent to the two below. (The second is considered poor style, for obvious
reasons.)
* EXAMPLE 8_4_2 * EXAMPLE 8_4_3
ZORCH EQU 3 R7 EQU 3
ZILCH EQU 7 R3 EQU 7
LOAD LR ZILCH,ZORCH LOAD LR R3,R7

Expressions can also be used to good advantage in EQU statements. For example, suppose we
need to define a symbol NWords whose value gives the number of words in a table, and we also
need a symbol NBits whose value is the number of bits in the same table. We could define the
symbols in the following way.

100 Assembler Language Programming for IBM System z™ Servers Version 2.00
* Example 8_4_4 EQU with expressions
NWords EQU 75 Table has 75 word entries
BitsWd EQU 32 Number of bits per word
NBits EQU NWords*BitsWd Number of bits in the table

Exercises
8.4.1.(2) What are the values of the symbols NWords, BitsWd, and NBits in Example 8_4_4
above?

8.4.2.(3) + The following short program segment contains instructions (whose purpose is of no
interest for this exercise) whose operand fields contain various expressions. For each expression,
determine (1) whether the expression is absolute or relocatable, and (2) the value of the
expression. The column headed “LOC” gives the hexadecimal value of the Location Counter
for each instruction.
LOC Statement
466 A L 4,B+X'1C'
46A BALR R6,0
46C B ST 4,C-A+X-2*(R6/2)
470 C SLL 5,2*C'-'-C'A'+2
USING B-2,R6-2
R6 EQU 9
474 X DS F Define Symbol X

8.4.3.(3) + Assume that the Location Counter, and symbols REL1, REL2, and ABS425 have the
value and relocation attributes defined in the examples on page 100. Determine the value and
relocation attributes of the following expressions.
(1) REL1+C'2'/2
(2) REL1-REL2+ABS425
(3) C'45'-(7*X'2A36')+ABS425*B'11111'-235
(4) (8/(REL2-REL1)/X'107C')+3
(5) ABS425/((REL2-REL1)/X'C701'+3)
(6) *+ABS425*(*-REL1-4900)

8.4.4.(2) Assuming that the symbols REL1, REL2, and ABS425 have the attributes defined on page
100, determine the validity of each of the following expressions. Explain why you think any
expression is invalid.
(1) -2+ABS425
(2) ((REL1))*2-2*((REL1))
(3) REL1+C'7592'*B'10110'+ABS425
(4) B'10221'+REL2
(5) ABS425*74239661-2
(6) +X'1875'
(7) -*+REL2
(8) **1

8.4.5.(3) Assume that the symbols A and B are simply relocatable with the same relocation
attribute, and that they have values X'00172B9E' and X'00173AA6' respectively. Determine the
value and relocation attributes of the following expressions.
(1) B-A
(2) A+C'.'
(3) (A+X'00FFF')-(B-B'1101011100001')
(4) (B-A)/10
(5) B+C'B'/(B+B'101'-B)

8.4.6.(3) + The symbols SAM and JOE are simply relocatable with the same relocation attribute,
and have values X'00174D0A' and X'0016FB63' respectively. The symbol BOB is absolute and has

Chapter III: Assembler Language Programs 101

 value X'000003E8'. First, determine the validity of each of the following expressions. Then
determine the value and relocation of each of the valid expressions.
(1) 2*BOB+2*SAM-2*JOE
(2) BOB+(SAM+BOB)-(JOE+BOB)
(3) 2*(SAM-JOE)/5
(4) SAM-(B'10000'*(X'0010'*(BOB-C'H')))
(5) (2*SAM-2*JOE)/5
(6) 2*(JOE-SAM)/(SAM-JOE)

8.4.7.(4) Can you think of any reasons why the designers of the Assembler Language did not
allow relocatable terms to appear in multiplications or divisions? Assuming that the final value
of the term must be either relocatable or absolute, what modifications would be needed to
allow such expressions, as in example 6 on page 100?

8.4.8.(1) The symbols A and B are relocatable, and have values X'00172B9E' and X'00173AA6'
respectively. Determine the value and relocation of these expressions:

1. B-A
2. A+C'.'

8.5. Machine Instruction Statement Operand Formats

The operand field entry of a machine instruction statement consists of a sequence of operands
separated by commas, and terminated by a blank not enclosed in apostrophes. For example, the
operand field entry of the LR machine instruction statement in Examples 8_4_1 through 8_4_3
contains two operands, expressions of value 7 and 3 respectively.

An operand of a machine instruction statement has only one of three possible formats:
expr expr1(expr2) expr1(expr2,expr3)
where “expr” is an abbreviation for “expression”, and the subscripts indicate only that each expr
can be different from the others. To repeat: operands of machine instruction statements have one of
these three formats.

The third operand format has two interesting features. First, the comma between the second and
third expressions does not terminate the operand; it merely separates the expressions within the
parentheses. Second, the first of the expressions within the parentheses, expr2, may sometimes be
omitted, so that
expr1(,expr3)
is a valid form of the third operand format. The Assembler will assume that the omitted
expression is absolute and has value zero. The format expr1(expr2,) is never valid.

Examples of the first expr format are

ABLE 2*(SAM-JOE)/5 X'6D' TWO+2 *

Examples of the second expr1(expr2) format are

ABLE(4) X'6D'(POINTER) P(*-*) (A-ST)(2+ST)

Multiplication is not implied in the last example!

Finally, examples of the third expr1(expr2,expr3) format are

0(255,12) 8(,3) X(Y-8,Z/2) (A-B)(A-B,(A-B))
Again, no multiplication is implied in any example.

Depending on the machine instruction, one or more operands may be required; for each operand,
one or more of the operand formats may be valid. Also, depending on the type of the instruction,

102 Assembler Language Programming for IBM System z™ Servers Version 2.00
 there may be restrictions on the value and relocation attributes of the expressions in an operand.
One of the most important restrictions is that all operands of a machine instruction statement
must either be absolute or simply relocatable; no complexly relocatable expressions are allowed.

For example, a typical RR-type instruction (as in the examples on page 100) has two operands:
each must be of the form
expr

For such RR-type instructions, the Assembler requires that the expressions must be absolute and
have value between 0 and 15.

Exercises
8.5.1.(2) + For each of the following operands, determine whether it is of the first, second, or
third type. If the operand is invalid, explain why.
(1) A+B(5)
(2) A+(B+(5))
(3) A+C'('(C')')
(4) A(C',C')
(5) 7+(X'BAD'/B'01101')
(6) (C'(')(C'),',(C'(,)'))
(7) 0-0(0,0)
(8) 0/0(,0*0)
(9) C'''(A)'*C'A('(C')'')'-X'C'*C'X)')

8.6. Details of Expression Evaluation (*)

While the rules for writing specific machine instruction statement operands will be covered in the
later sections as new instruction types are introduced, this view of the rules for valid expressions
(stated in the previous section) can be summarized in these diagrams.57
1. An operand can take one of three forms:
operand
┌──────────┼────────────┐
expr expr(expr) expr(expr,expr)
2. An expression can take any of these three items involving a “factor” (this shows how unary
+ and − signs are described):
expr
┌────────┼────────────┐
factor ±factor factor±factor
3. A factor can take any of these three forms (this shows how multiplication and division have
higher priority than addition and subtraction):
factor
┌─────────────┼─────────────────┐
primary primary*primary primary/primary
4. A primary is either a term or a parenthesized expression:
primary
┌───┴───┐
term ( expr )
5. Finally, a term in an expression is one of the following:

57 These five diagrams are pictorial representations of a notation known as “BNF”, which stands for either “Backus
Normal Form” (after John Backus, the leader of the team that created the first FORTRAN compiler in 1957), or
“Backus-Naur Form” (after John Backus and Peter Naur, who worked on defining the ALGOL language in
1958-1960.)

Chapter III: Assembler Language Programs 103

 term
┌────────┬───────────┼─────────┬─────────┐
Symbol Self─ Location Literal Symbol
Defining Counter Attribute
Term Reference Reference
┌───┼───┐
L' I' S'

We haven't yet described Literals and Symbol Attribute References; they will appear shortly.

The quantities “factor” and “primary” do not appear anywhere in the Assembler Language. They
are used here only to help clarify the precedence of multiplication, division, addition, subtraction,
and parentheses.

Terms and Definitions

absolute symbol
A symbol whose value behaves in expressions like a self-defining term. Its value does not
change if the assumed origin of the program changes.
complex relocatability
A property of a symbol or expression whose relocation attribute is neither absolute or simply
relocatable.
expression
A combination of terms and operators to be evaluated by the Assembler.
expression evaluation
The procedure used by the Assembler to determine the value of an expression.
Length Attribute Reference
A term whose value is the length attribute of a symbol.
operator
One of * (meaning multiplication), / (meaning division), + (meaning addition), or −
(meaning subtraction). (The Assembler does not support **, which is sometimes used to
mean exponentiation.)
simple relocatability
A property of a symbol or expression whose value changes by the same amount as a change
to the program's assumed origin.
Symbol Attribute Reference
A term whose value is that of a symbol's attribute. The three most important types of
Symbol Attribute Reference are length, scale, and integer.
term
A symbol, self-defining term, Location Counter reference, literal, or symbol attribute refer-
ence.

Programming Problems
Problem 8.1.(2) Write and execute some test cases with your Assembler to determine whether it
allows you to specify a Length Attribute reference of any term, not just for symbols and
Location Counter References. Are there any cases that don't work? (Some test cases you might
try are L'2, L'(*-10), L'*, L'ABS425, L'425, L'=F'1', and L'L'*.)

Problem 8.2.(2) What is the length attribute of an expression? Suppose A and B are absolute
symbols with value 5 and 3 respectively, and they both have length attribute 1. Determine the
value of each of the following expressions: (1) L'A*B, (2) A*L'B, (3) L'(A*B). Evaluate them on
your Assembler. This code fragment may help you start:

104 Assembler Language Programming for IBM System z™ Servers Version 2.00
A Equ 5
B Equ 3
C1 Equ L'A*B
C2 Equ A*L'B
C3 Equ L'(A*B)
Try some similar expressions and see what happens.

Chapter III: Assembler Language Programs 105

9. Instructions, Mnemonics, and Operands

9999999999
999999999999
99 99
99 99
99 99
999999999999
999999999999
99
99
99 99
999999999999
9999999999

We will now see how to write some machine instruction statements, with various instruction
formats and examples of actual code sequences. The instructions in Table 16 and their behavior
will be discussed in detail later, so don't worry now about learning the mnemonics, operation
codes, or descriptions.

Mnemonics are short abbreviations for a word or phrase describing the action of each operation
code. A mnemonic may be as simple as “A” meaning “Add”, or “BXLE”, meaning “Branch on
Index Low or Equal”. We will look at several classes of instructions, showing how their operands
are written. Abbreviations and notations used to describe operands such as “R1”, “S2”, “I 2”, etc.,
will be explained as we go along.

9.1. Basic RR-Type Instructions

Table 16 illustrates some common RR-type instructions, where “Op” and “Mnem” are abbrevi-
ations for “Operation Code” or “Opcode”, and “Mnemonic”.

Op Mnem Instruction Op Mnem Instruction

04 SPM Set Program Mask 05 BALR Branch And Link
06 BCTR Branch On Count 07 BCR Branch On Condition
0D BASR Branch And Save 0E MVCL Move Long
0F CLCL Compare Logical Long 10 LPR Load Positive
11 LNR Load Negative 12 LTR Load And Test
13 LCR Load Complement 14 NR AND
15 CLR Compare Logical 16 OR OR
17 XR Exclusive O R 18 LR Load
19 CR Compare 1A AR Add
1B SR Subtract 1C MR Multiply
1D DR Divide 1E ALR Add Logical
1F SLR Subtract Logical
Table 16. Typical RR-type instructions

106 Assembler Language Programming for IBM System z™ Servers Version 2.00
 1. Not all of the 64 available bit combinations between X'00' and X'3F' are used as actual oper-
ation codes. For example, IBM has promised not to use X'00' as an operation code. 58
2. There are many other RR-type instructions, and several other RR-type instruction formats.
The examples that follow generally apply to all such instructions.

9.2. Writing RR-Type Instructions

For most RR instructions, the operand field entry in a machine instruction statement is written
R1,R2
where the operands “R 1” and “R 2” designate registers.59 (Some instructions require one or both of
the operands to be even numbers, designating even-numbered registers.)

The numeric subscripts “1” and “2” in the quantities “R1” and “R 2” distinguish the operand
being referenced. Using the terms “first operand”, “second operand”, etc. consistently will help
you remember what actions are being performed by each instruction.

To explain the notation “R 1,R 2”, refer to the example of a machine instruction statement in
Figure 30 on page 78, where the operation and operand field entries were “LR” and “7,3”,
respectively. In this case, the “R1” operand is “7” and the “R 2” operand is “3”. The quantities
R 1 and R 2 must be absolute expressions between 0 and 15. Thus, we could just as well have
written
LOAD LR X'7',B'11'

For these basic RR-type instructions, the values of the operand field expressions are placed by the
Assembler into two adjacent hexadecimal digits, called the “operand register specification digits”
in the second byte of the instruction. This second byte was denoted “register specification” in
Table 6 on page 52. Table 17 shows the positions of the register specification digits.

opcode R1 R2
Table 17. RR-type instruc-
tion

For most RR instructions the R 1 operand specifies the register that at execution time contains the
“first operand”. Our notation “R 1” means a number specifying the R1 digit of an instruction; no
reference to general register register 1 (possibly denoted by GR1) is implied. You can of course
specify “1” as the value of the R1 operand!

We can now see the difference between (1) the “operands” of an instruction statement at
assembly time, and (2) the “operands” of a machine instruction at execution time. The operands
(first meaning) in the operand field entry of the instruction “LR 7,3” are the single characters 7
and 3, whereas at execution time the operands (second meaning) of the LR instruction will be the
data found in general registers 7 and 3. Table 16 on page 106 shows that the operation code
corresponding to the mnemonic LR is X'18', so the two-byte instruction generated by the Assem-
bler would be X'1873'.

Programming with RR instructions is easy. Suppose we wish to compute the sum of the contents
of general registers 2 and 14, subtract the contents of GR9 from the sum, and leave the result in
GR0. These statements will do the job.

58 X'00' has not been assigned as a valid opcode for two reasons. First, unused areas of memory are often set to zero
when programs are initialized; programs that try to execute “instructions” from those areas will stop immediately
with a program interruption for an invalid instruction. (Sometimes, a programmer will purposely insert a X'0000'
halfword in a program to force it to stop at an exact position so the contents of registers and memory can be veri-
fied.) Also, programs like debuggers sometimes use X'00' as “breakpoints” to halt instruction tracing at a specified
place.
59 Some instructions have only one or even no explicit operands!

Chapter III: Assembler Language Programs 107

 LR 0,2 Copy contents of GR2 to GR0
AR 0,14 Add contents of GR14 to GR0
SR 0,9 Subtract contents of GR9 from GR0
The instructions, their actions, and other properties will be described in subsequent sections.

Exercises
9.2.1.(2) + Which of the following are valid register operands for an RR-type instruction?
(1) 0, (2) B'1101', (3) X'11', (4) 4*(X'F2'−C'0')/5+X'E', (5) 4*(X'F2'−C'0')/3+X'E'.

9.2.2.(2) Which of the values in Exercise 9.2.1 are valid operands if the instruction operand
requires an even-numbered register?

9.3. Basic RX-Type Instructions

Table 18 shows examples of some frequently-used RX-type instructions. As in Table 16, not all
of the 64 available digit combinations between X'40' and X'7F' are used as actual operation
codes. Again, you needn't try to remember them here.

Op Mnem Instruction Op Mnem Instruction

40 STH Store Halfword 41 LA Load Address
42 STC Store Character 43 IC Insert Character
44 EX Execute 45 BAL Branch And Link
46 BCT Branch On Count 47 BC Branch On Condition
48 LH Load Halfword 49 CH Compare Halfword
4A AH Add Halfword 4B SH Subtract Halfword
4C MH Multiply Halfword 4D BAS Branch And Save
4E CVD Convert To Decimal 4F CVB Convert To Binary
50 ST Store 54 N AND
55 CL Compare Logical 56 O OR
57 X Exclusive O R 58 L Load
59 C Compare 5A A Add
5B S Subtract 5C M Multiply
5D D Divide 5E AL Add Logical
5F SL Subtract Logical
Table 18. Typical RX-type instructions

9.4. Writing RX-Type Instructions

In this and the following section we will introduce some basic concepts, using RX-type
instructions as examples.

The format of an RX-type instruction was shown in Table 7 on page 52. We now look at the
parts of the instruction in Table 19 and describe Assembler Language techniques for specifying
them.

opcode R1 X2 B2 D2
Table 19. RX-type instruction

108 Assembler Language Programming for IBM System z™ Servers Version 2.00
 As noted when we reviewed addressing in Section 5.3 on page 63, three components of an RX
instruction are used in computing an Effective Address: the index register specification digit X2,
the base register specification digit B2, and the displacement D2. The operand field entries may be
written in several ways, but they must yield values for the four needed quantities: R 1, X 2, B2, and
D 2. Usually, values for all of these items need not be explicitly given; the Assembler can make
assumptions about what to provide in cases where values are not explicitly given. When the
Assembler provides values for something, we say that the values were “specified by default” or
“specified implicitly”.

The operand field entry of RX-type instructions has the general form
R1,address-specification
where “address-specification” will be described next. The operand register specification digit R1 is
formed according to the same rules given above for the R1 and R 2 digits for RR instructions, and
must be an absolute expression with value between 0 and 15.

9.5. Explicit and Implied Addresses

For an explicit address, you supply the base and displacement; for an implied address, the Assem-
bler determines the base and displacement. (Section 10 will show you how it's done.)

Explicit and Implied Addresses

• Explicit: you specify the base and displacement.
• Implied: the Assembler calculates the base and displacement for you.
How this is done is explained in Section 10.

Suppose we wish to specify explicitly the values assigned to X2, B2, and D 2: then, we write the
second operand (the “address-specification”) as
D2(X2,B2)
which is the third of the possible operand formats described in Section 8.5 on page 102. The
instructions in examples 4, 5, and 6 of Section 5.4 on page 65 could be written as shown in
Figure 34, where the assembled form is on the left, and the Assembler Language machine instruc-
tion statement is in the center; the displacements have the same value in each instruction.

430A7468 IC 0,1128(10,7) D2=1128, X2=10, B2=7

43007468 IC 0,1128(0,7) D2=1128, X2=0, B2=7
43070468 IC 0,1128(7,0) D2=1128, X2=7, B2=0
Figure 34. RX Instruction with explicit operands

Compare the machine language form of these three instructions to the fields in Table 19 on
page 108.
The four possible forms of the second operand of an RX instruction are shown below, where we
use “S2” to mean an implied address (which need not necessarily refer to a symbol, as we'll see!).

Explicit Address Implied Address

Not Indexed D 2(,B2) S2

Indexed D 2(X 2,B2) S2(X 2)

Table 20. Operands of RX-type instructions

In the two cases where an explicit address is written, each of the quantities D2, X 2, and B2 must
be an absolute expression; X2 and B2 must have value less than 16, and D2 must have value less

Chapter III: Assembler Language Programs 109

 than or equal to 4095=X'FFF'.60 The not-indexed form of an explicit address implies X2=0, as
we saw earlier; both indexed addresses specify an index digit.
In the two cases where an implied address is written, the quantity S2 may be either an absolute or
a relocatable expression. This means that we can write instructions such as
L 0,ANSWER Operand forms are R1,S2
L 0,16 Operand forms are R1,S2
LA 2,25*40 Operand forms are R1,S2
and let the Assembler assign the proper base and displacement; this is the subject of Section 10.
Note that the second operand of the first statement is a symbol (that we assume is relocatable),
while the second operand of the other two statements is an absolute expression.
For the moment, suppose the Assembler has sufficient information so that the instruction
IC 0,BYTE Operand forms are R1,S2
is translated into the hexadecimal digits 43007468, as in Figure 34 on page 109. Then if the
index register is GR10, the instruction
IC 0,BYTE(10) Operand forms are R1,S2(X2)
is translated into the hexadecimal digits 430A7468. In the last example in Figure 34 on page 109
we could have written the second operand with an indexed implied address of the form S2(X 2), as
1128(7), where the S2 expression is absolute!
For example, it is common practice to load a small constant into a register using the LA (Load
Address) instruction:
LA 2,10 Put 10 in R2
and the operand 10 is an absolute implied address. This will almost never lead to difficulties; but
to be absolutely safe, you could write instead
LA 2,10(0,0) Put 10 in R2
and the operand now specifies an explicit address.

The only way the Assembler can decide among the four forms of address specification in Table 20
on page 109 is (1) by noting whether a left parenthesis follows the first expression (if not, the
address is implied), and (2) if there is a left parenthesis, by noting whether a comma appears
before the matching right parenthesis (if so, the address is explicit). There is of course no effect of
commas and parentheses in character self-defining terms.
It helps to remember that implied addresses almost always involve relocatable expressions, and
explicit addresses always involve absolute expressions. Sometimes we accidentally use a relocatable
expression where it should have been absolute, or an absolute expression where it should have
been relocatable. The Assembler usually (but not always) diagnoses such errors.
The most common form of address specification is an implied address, where the Assembler com-
putes the proper displacement for us. While we have now seen implied addresses in the context of
RX-type instructions, they are used in many other instruction types.

Exercises
9.5.1.(2) In Table 20 on page 109, use the rules of Section 8.5 to identify the format of each of
the four operands.

9.5.2.(2) + The following are examples of the second operand of an RX-type instruction (the
address-specification). For each operand, determine (1) whether the address is implied or
explicit, and (2) whether indexing is specified. Assume that the symbols A, B, C are relocatable
with the same relocation attribute, and that the symbol N is absolute.

60 In Section 20 we will introduce instructions with signed 20-bit displacements.

110 Assembler Language Programming for IBM System z™ Servers Version 2.00
 1. B+X'1C'
2. C-A+B-2(N/2)
3. 2*C'-'-C'A'+2(N+N)
4. B-A((B-A)/2,((B-A)*2))
5. C'A'+A(C','-99)
6. N+N(,N)

9.5.3.(2) Assume that each of the operands in Exercise 8.5.1 on page 103 is used in an RX-type
instruction. Using the rules in Section 9.5, determine whether the addresses are explicit or
implied.

9.6. Typical RS- and SI-Type Instructions

The examples of basic RS-type and SI-type instructions in Table 21 are quite varied in the way
you specify their operand fields.

Op Mnem Type Instruction Op Mnem Type Instruction

90 STM RS Store Multiple 91 TM SI Test Under Mask
92 MVI SI Move Immediate 94 NI SI AND Immediate
86 BXH RS Branch On Index High 95 CLI SI Compare Logical Imme-
diate
87 BXLE RS Branch On Index Low or Equal 96 OI SI O R Immediate
97 XI SI Exclusive OR Immediate 88 SRL RS Shift Right Single Logical
98 LM RS Load Multiple 89 SLL RS Shift Left Single Logical
8A SRA RS Shift Right Single 8B SLA RS Shift Left Single
8C SRDL RS Shift Right Double Logical 8D SLDL RS Shift Left Double Logical
8E SRDA RS Shift Right Double 8F SLDA RS Shift Left Double
BD CLM RS Compare Logical Characters BE STCM RS Store Characters Under
Under Mask Mask
BF ICM RS Insert Characters Under Mask
Table 21. Typical RS- and SI-type instructions

Some instructions (like “Shift Double”) require a register operand to be an even number.

9.7. Writing RS- and SI-Type Instructions

We will show the operand field formats for RS-type and SI-type instructions separately, as they
are quite different.

The RS-type instruction format is similar to RX-type format, except that the X2 field is replaced
by an R 3 field, so no indexing is performed when Effective Addresses are formed.

opcode R1 R3 B2 D2
Table 22. Typical RS-type instruction

The operand fields of Assembler Language instructions specifying RS-type instructions are shown
in Table 23 on page 112. There are two forms, one with a single “Rn” operand and the other
with two, indicated by RS-1 and RS-2 meaning one or two register operands respectively.

Chapter III: Assembler Language Programs 111

 Explicit Address Implied Address

RS-1 R 1,D 2(B2) R 1,S2

RS-2 R 1,R 3,D 2(B2) R 1,R 3,S2

Table 23. Operands of RS-type instructions

Examples of RS-type instructions with explicit and implied addresses are:

SRA 11,2 Explicit address (RS-1 form)
SLDL 6,N Implied address (RS-1 form)
LM 14,12,12(13) Explicit address (RS-2 form)
STM 14,12,SaveArea+12 Implied address (RS-2 form)
BXLE 4,1,Loop_3 Implied address (RS-2 form)

SI-type instructions are different. The I2 operand is contained in the second byte of the instruc-
tion, as in Table 24:

opcode I2 B1 D1
Table 24. Typical SI-type instruction

Table 25 gives the operand fields of Assembler Language statements involving SI-type
instructions:

Explicit Address Implied Address

SI D 1(B1),I2 S1,I 2

Table 25. Operands of SI-type instructions

Examples of SI-type instructions with explicit and implied addresses are:

MVI 0(6),C'*' Explicit S1 address
CLI Buffer,C'0' Implied S1 address

Exercises
9.7.1.(2) The following are operand fields that could be used in RS- and SI-type instructions.
Identify the type of instruction (RS-1, RS-2, or SI) for which they are valid, and the compo-
nents of the instruction to which each expression applies. State which expressions specify
explicit addresses and which specify implied addresses.

(1) 1(2),3
(2) 4,5(6)
(3) 7,8,9
(4) 10,11
(5) 14,15(16)
(6) 100,101

112 Assembler Language Programming for IBM System z™ Servers Version 2.00
9.8. Typical SS-Type Instructions
Table 26 shows some examples of popular SS-type instructions. The column headed “Len”
shows the number of length fields in the instruction.

Op Mnem Len Instruction Op Mnem Len Instruction

D1 MVN 1 Move Numeric F0 SRP 2 Shift And Round
D2 MVC 1 Move F1 MVO 2 Move With Offset
D3 MVZ 1 Move Zone F2 PACK 2 Pack
D4 NC 1 AND F3 UNPK 2 Unpack
D5 CLC 1 Compare Logical
D6 OC 1 OR F8 ZAP 2 Zero And Add
D7 XC 1 Exclusive O R F9 CP 2 Compare
DC TR 1 Translate FA AP 2 Add
DD TRT 1 Translate And Test FB SP 2 Subtract
DE ED 1 Edit FC MP 2 Multiply
DF EDMK 1 Edit And Mark FD DP 2 Divide
Table 26. Typical SS-type instructions

ED, EDMK, SRP, and the last six instructions in the right-hand column operate on data stored
in packed decimal format, which is different from the data formats used for the general register
and floating-point instructions. We'll learn about them in Chapter VIII.

9.9. Writing SS-Type Instructions

Most SS-type instructions specify two addresses, and may have one or two length fields depending
on whether you must specify the length of only one operand (type SS-1) or of both operands
(type SS-2). Their formats are shown in Tables 27 and 29.

As with explicit and implied addresses, you can also specify explicit and implied lengths in SS-type
instructions. When we use implied lengths the Assembler determines the values put into the
length fields of the instruction, often by using the length attribute of a symbol. Implied lengths
are very useful, and we'll see many examples.

This is the format of instructions with a single length field.

opcode L1 B1 D1 B2 D2
Table 27. Typical type SS-1 instruction with one length field

Addresses and lengths may be specified explicitly or implicitly, as summarized in the following
tables. First, we examine the single-length instructions.

SS-1 Explicit Addresses Implied Addresses

Explicit Length D 1(N 1,B1),D 2(B2) S1(N 1),S2

Implied Length D 1(,B1),D 2(B2) S1,S2

Table 28. Operands of type SS-1 single-length instructions

Chapter III: Assembler Language Programs 113

 When you write an instruction with an explicit length, you provide a “Length Expression” or
“program length”, denoted “N 1”. The Assembler generates object code with an “Encoded
Length” or “machine length” denoted by “L 1”. This seems strange: why are they different?

The Assembler generates the value of L1 by subtracting 1 from the value of N1 (unless N1 is
zero). We'll see why this is done when we discuss SS-type instructions starting in Section 24.

Some examples of SS-type instructions with a single length field are:

MVC 0(80,4),40(9) Explicit length and addresses
CLC Name(24),RecName Explicit length, implied addresses
TR OutCh(,15),0(12) Implied length, explicit addresses
XC Count,Count Implied length and addresses
where the symbol OutCh must be absolute. (This form is rarely used.)

SS-type instructions with two length fields have the format shown in Table 29.

opcode L1 L2 B1 D1 B2 D2
Table 29. Typical type SS-2 instruction with two length fields

Many more combinations of explicit and implied lengths and addresses are available when you
use SS-type instructions with two length fields. Some of the Assembler Language operand field
combinations are shown below.

SS-2 Explicit Addresses Implied Addresses

Explicit Lengths D 1(N 1,B1),D 2(N 2,B2) S1(N 1),S2(N 2)

Implied Lengths D 1(,B1),D 2(,B2) S1,S2

Table 30. Operands of type SS-2 two-length instructions

You can specify explicit lengths and addresses for either of the two operands; see Exercise 9.9.2.

As noted for SS-1 type instructions, the Encoded or machine lengths L1 and L 2 are one less than
the Length Expressions or program lengths N1 and N 2. We'll see these again in Chapter VIII.

Some examples of SS-type instructions with two length fields are:

PACK 0(8,4),40(5,9) Explicit lengths and addresses
ZAP Sum(14),OldSum(4) Explicit lengths, implied addresses
AP Total(,15),Num(,12) Implied lengths, explicit addresses
UNPK String,Data Implied lengths and addresses

The symbols Total and Num must be absolute for the third statement to be valid.

This SS-type instruction copies five bytes from a memory area named AREA to an area of memory
named FIELD:
MVC FIELD(5),AREA

Exercises
9.9.1.(2) + The following operands could be used in SS-type instructions. State the operand for
which they may be valid, for both SS-1-type and SS-2-type instructions, and whether a length is
explicit or implied. (Validity and form may depend in the relocation attribute of the symbols.)

(1) 1(2)
(2) 4(5,6)
(3) A(L'B)
(4) Line

114 Assembler Language Programming for IBM System z™ Servers Version 2.00
 (5) Line(80)
(6) XX(,5)

9.9.2.(2) + Make a table to show all possible combinations of explicit and implied addresses,
and implicit and implied lengths, for SS-2 type instructions.

9.10. Summary
When describing the fields of both machine instructions and assembler instruction statements, we
use notations like S2, B1, N, L 2, etc.
• Fields denoted S can be absolute or relocatable expressions, and are most often relocatable.
• Fields denoted B, D, I, L, N, and X must always be absolute expressions.

Terms and Definitions

Encoded Length
The contents of a Length Specification Byte; one less than the value of the Length
Expression (unless the Length Expression is zero, in which case the Encoded Length is also
zero).
explicit address
An address in which you specify the base register specification digit and the displacement as
absolute expressions.
explicit length
A length field that you specify explicitly.
implied address
An address where you expect the Assembler to assign a base register specification digit and a
displacement to an addressing halfword.
implied length
A length field completed by the Assembler based on its analysis of the operand.
Length Expression
A value you write in an SS-type instruction specifying the length of the operand(s).
machine length
An Encoded Length.
mnemonic
A character string representing an instruction, intended to be easier to remember than the
operation code of the instruction.
opcode
An abbreviation for operation code. Occasionally used when the term mnemonic is actually
meant.
operation code
The z/Architecture definition of an instruction's bit pattern to be decoded by the CPU to
determine what actions it should take.
program length
A Length Expression.

Chapter III: Assembler Language Programs 115

10. Establishing and Maintaining Addressability

11 00000000
111 0000000000
1111 00 00
11 00 00
11 00 00
11 00 00
11 00 00
11 00 00
11 00 00
11 00 00
1111111111 0000000000
1111111111 00000000

In Section 5 we saw how the CPU at execution time converts addressing halfwords into Effective
Addresses. Now we will see how the Assembler derives addressing halfwords from the values of
symbolic expressions at assembly time, and answer the question “How do we help the Assembler
create addressing halfwords?”

This important information is provided in the USING assembler instruction statement.

10.1. The BASR Instruction

The RR-type Branch and Save (Register) instruction with mnemonic BASR is frequently used to
generate a base address that provides addressability.61 For now, we consider what happens when
we write
BASR R1,0
where the second operand register specification digit R2 is zero. This instruction when executed
replaces the contents of the general register specified by R1 by the Instruction Address (IA)
portion of the PSW. This address will necessarily be the address of the instruction following the
BASR, because the IA was incremented by the BASR instruction's length (2 bytes) during the
fetch portion of the instruction cycle.

In this RR-type instruction (unlike many other RR-type instructions), the zero second operand
does not refer to general register zero! Instead, it means that only the described actions will occur
without any “branch”, as the “Branch and Save” name implies. (We'll see in Chapter X that
BASR is often used for branching, usually in subroutine linkages.)

Suppose the following short sequence of statements is part of a program that has been assembled
and placed in memory to be executed. While we are giving the Assembler Language statements in
Figure 35 on page 117, the assembled contents of memory will be hexadecimal machine language
data, as shown in Figure 36 on page 118. Suppose the Program Loader has relocated the
program so that the first instruction (the BASR) was placed at memory address X'5000'.

61 The BASR instruction should be used in place of BALR in most situations; the main difference is that BALR inserts
the ILC, CC, and Program Mask in the high-order 8 bits of the first operand register when executing in 24-bit
addressing mode. BALR and BASR work the same way in 31-bit and 64-bit addressing modes.

116 Assembler Language Programming for IBM System z™ Servers Version 2.00
 Address Name Operation Operand Remarks

* Fragment of a simple program

5000 BASR 6,0 Establish base address
5002 BEGIN L 2,N Load contents of N into GR2
5006 A 2,ONE Add contents of ONE
500A ST 2,N Store contents of GR2 into N
--twenty-two (X'16') additional bytes of instructions, data, etc.--
5024 N DC F'8' Word integer 8
5028 ONE DC F'1' Word integer 1
Figure 35. A simple program segment

For this and the following examples, the instructions following the BASR are intended just to
show how the Assembler creates addressing halfwords. Briefly, their actions are:
• L is the mnemonic for the RX-type (4-byte) machine instruction Load. It copies the contents
of a 4-byte (word) area of memory and puts it into a general register.
• A is the mnemonic for the RX-type (4-byte) machine instruction Add. It adds a copy of the
contents of a 4-byte (word) area of memory to the contents of a general register.
• ST is the mnemonic for the RX-type (4-byte) machine instruction STore. It replaces the con-
tents of a 4-byte (word) area in memory with a copy of the contents of a general register.
• DC ( Define Constant) is an Assembler instruction used to create constants. The two DC
statements create word binary integers in memory.

The leftmost column in Figure 35 shows the memory address of each instruction and data item.

For now, we'll ignore what the instructions actually do, and focus on how they are assembled.

Exercises
10.1.1.(2) Use the lengths of the instructions and constants in Figure 35 to calculate their
addresses in memory, and determine if the values in the figure are correct.

10.2. Computing Displacements

Now, suppose the program has begun execution. After the BASR has been executed, register 6
will contain X'00005002'. (Remember: BASR places the address of the next instruction into the
register designated by the R1 operand.) We can now use the address in register 6 as a base
address for the instructions following the BASR, so the base register specification digit in subse-
quent addressing halfwords should be 6.

We can determine the proper displacement in the L instruction at X'5002' by using two important
values: the known contents of register 6 (X'00005002') and the address of the word area named N.
Using these values, we can now compute a displacement:
X'00005024' − X'00005002' = X'022'

Then, the assembled machine language instruction (using opcode X'58' for the mnemonic L) will
be X'58206022'. When this instruction is executed, its Effective Address is
X'022' + X'00005002' = X'00005024',
the address of the word named N that we want!

If we continue this way for the rest of the statements, the “assembled” machine language
instructions and data will give the desired results at execution time. That is, after program loading
is complete, we want the memory areas starting at address X'5000' to contain the (hexadecimal)
machine language data shown under “Assembled Contents” in Figure 36 on page 118.

Chapter III: Assembler Language Programs 117

 Address Assembled Contents Original Statement

5000 0D60 BASR 6,0

5002 58206022 BEGIN L 2,N
5006 5A206026 A 2,ONE
500A 50206022 ST 2,N
----------------------------------
5024 00000008 N DC F'8'
5028 00000001 ONE DC F'1'
Figure 36. Simple program segment with assembled contents

Remember that when the Assembler processes the BASR statement and produces two bytes of
machine language code containing X'0D60', nothing is yet “in” register 6. It is only when this
machine language instruction is finally executed by the processor that the desired base address will
be placed in register 6.

So far, so good: we have constructed a sequence of instructions that will give a desired result if it
is placed in memory at exactly the right place. You might ask “What would happen if the
program is put elsewhere by the Program Loader?” So, let's suppose the same program segment
begins at memory address X'84E8', as in Figure 37.

Address Statement

84E8 BASR 6,0

84EA BEGIN L 2,N
84EE A 2,ONE
84F2 ST 2,N
--- the same 22 bytes of odds and ends ---
850C N DC F'8'
8510 ONE DC F'1'
Figure 37. Same program segment, at different memory addresses

After executing the BASR, register 6 contains X'000084EA'. To address the contents of the word
named N using register 6 as a base register, the necessary displacement is
X'0000850C' − X'000084EA' = X'022'

Similarly, the displacement necessary in the “A” instruction is

X'00008510' − X'000084EA' = X'026'

After completing the three addressing halfwords, the assembled machine language program would
appear in memory as shown in Figure 38.

Address Assembled Contents

84E8 0D60
84EA 58206022
84EE 5A206026
84F2 50206022
-----------------
850C 00000008
8510 00000001
Figure 38. Same program segment, with assembled contents

The identical machine language program is generated in both Figures 36 and 38. We see that so
long as the same fixed relationship is maintained among the various parts of the program segment
(there are 22 bytes between the ST instruction and the word named N), the program segment
could be placed anywhere in memory and still execute correctly. That is, the program is relocat-
able.

118 Assembler Language Programming for IBM System z™ Servers Version 2.00
 Indeed, we could have assumed that the program began at memory address zero (even though an
actual program would not be placed there) because the contents of register 6 after the BASR is
executed would be X'00000002', and the displacements would be calculated exactly as before.

10.3. Explicit Base and Displacement

Knowing what we need for the assembled program (the machine language instructions shown in
Figures 36 and 38), we now write the instruction statements with explicit addresses in their second
operands. Register 6 is the base register, and the displacements are those we just calculated. Then
we can write the program as in Figure 39, using an assumed origin of zero for the LC.
(Remember: we're describing locations at assembly time, not the execution time addresses we saw
in the previous examples.)

Location Name Operation Operand

0000 BASR 6,0

0002 BEGIN L 2,X'022'(0,6)
0006 A 2,X'026'(0,6)
000A ST 2,X'022'(0,6)
--------- 22 bytes ----------
0024 N DC F'8'
0028 ONE DC F'1'
Figure 39. Program segment with pre-calculated explicit base and displacements

This example has two shortcomings. First, calculating displacements in advance is tedious (espe-
cially in large programs), and certainly error-prone. Second, if the relative positions of the parts
of the program change in any way, we will be forced to recalculate some or all of the displace-
ments.

Thus, our first simplification is to find a way to let the Assembler compute the displacements just
as we did. Now, however, we can make good use of the values assigned by the Assembler to the
symbols BEGIN, N, and ONE. (As noted in Section 7.6 on page 93, the values of the symbols are
the values of the LC when the statement is processed.) Referring to Figure 39, the values
assigned to the three symbols will be the value of the assumed origin plus X'0002', X'0024', and
X'0028', respectively.

The key to this example is that when the program is executing, the base register (register 6) con-
tains the address of the instruction named BEGIN. We use this observation to rewrite the program
segment, as shown in Figure 40.

Location Name Operation Operand

0000 BASR 6,0

0002 BEGIN L 2,N-BEGIN(0,6) (N-BEGIN = X'022')
0006 A 2,ONE-BEGIN(0,6) (ONE-BEGIN = X'026')
000A ST 2,N-BEGIN(0,6) (N-BEGIN = X'022')
------- the usual 22 bytes -------
0024 N DC F'8'
0028 ONE DC F'1'
Figure 40. Program segment with explicit base and Assembler-calculated displacements

We have eliminated both of the shortcomings of the program segment in Figure 39: the displace-
ments were not calculated in advance, and adding (say) four more bytes of instructions or data
preceding the DC statements would not require the rest of the program to be rewritten. However,
we have created another nuisance, since every instruction containing a reference to a symbol must
now specify two extra items: the symbol BEGIN and the base register (6).

So, we need a way to make the Assembler do the rest of the work for us, after we have told it (1)
which base register to use, and (2) the value that will be in it when the program is executed.

Chapter III: Assembler Language Programs 119

10.4. The USING Assembler Instruction and Implied Addresses
The USING assembler instruction provides exactly the information we need. It is written
USING base_location,base_register
where “base_location” is almost always a relocatable expression. (The base_location is sometimes
called the “base”, but it easy to mistake this for the “base_register”.) The “base_register” operand
is an absolute expression between 0 and 15, specifying the register to be used as a base register.
(Zero is very rarely used.)

Thus, the statement

USING BEGIN,6
tells the Assembler to assume that register 6 may be used as a base register that at execution time
will contain the relocated address of the instruction named by the symbol BEGIN. The Assembler
can then calculate displacements relative to the location of BEGIN, and then use this assumption to
create addressing halfwords with base register specification digit 6 and the calculated displace-
ments.

We now rewrite the sample program segment of Figure 40 on page 119 to include the USING
statement in Figure 41.

BASR 6,0
USING BEGIN,6
BEGIN L 2,N
A 2,ONE
ST 2,N
-----------------------
N DC F'8'
ONE DC F'1'
Figure 41. Program Segment with USING Instruction

If the initial LC value is zero, the value of the symbol BEGIN will be X'0002', and the values of the
symbols N and ONE will be X'0024' and X'0028' respectively. To complete its derivation of the
addressing halfword of the ST instruction, the Assembler needs only to calculate the difference
between the location of the symbol N and the base_location of BEGIN specified in the USING
instruction:
X'0024' − X'0002' = X'022'
and this is the required displacement.

Similarly, the implied address of the operand ONE of the A instruction has value X'0028'; when
the base_location value is subtracted, we find the displacement is X'026', as before. We say that
the Assembler has resolved the implied addresses of the L, A, and ST instructions into base-
displacement form. Thus, the machine language generated from this set of statements would
appear exactly as in Figures 36 and 38. (Details about how the Assembler computes displace-
ments and assigns base registers is described starting in Section 10.8.)

If the attempted calculation

displacement = (operand value) − (base_location value)
yields a negative result or a value greater than 4095, the location referred to by the symbol is still
not addressable with this base register, and some other solution is needed.62

62 Section 20 describes long-displacement and relative-immediate instructions with a larger range of displacement values.

120 Assembler Language Programming for IBM System z™ Servers Version 2.00
 It is clear that the Assembler can make use of the information supplied by the USING statement
only for implied addresses. If you provide an explicit base and displacement, the Assembler
simply converts them to their proper binary form.

Two important features of the program segment in Figure 41 on page 120 should be noted.
1. The USING instruction does absolutely nothing about actually placing an address into a reg-
ister; it merely tells the Assembler what to assume will be there when the program is exe-
cuted.
That is, your USING statement is a promise to the Assembler that if it computes displace-
ments for you, everything will work properly when the program is executed. (It is very easy
to mislead the Assembler, as we'll see in Section 10.11 on page 129.)
2. If the BASR instruction had been omitted, the contents of register 6 at execution time is
probably unknown. There is no guarantee that correct Effective Addresses will be computed
when the program is executed.

Remember!
A USING statement is your assembly-time promise to the Assembler
that your program will obey that promise at execution time.

10.5. Location Counter Reference

The Assembler provides a convenient way to refer to the current value of the Location Counter,
the Location Counter Reference. The term * in an expression has the current value of the LC,
and is always relocatable.

We can rewrite the first two statements of our sample program as

BASR 6,0
USING *,6
with the same results as before. Remember that after the BASR instruction is assembled, the LC
will have a value corresponding to the location of the next byte to be assembled. Because BASR
will (at execution time) place the address of the following instruction into register 6, we can use a
Location Counter Reference to specify the base_location, and not have to use a symbol (such as
the symbol BEGIN in Figure 41 on page 120). to name the instruction following the BASR
instruction.

A common technique for specifying base registers in a program is to choose a base register, write
the statements
BASR reg,0
USING *,reg
at the beginning of the program, and then carefully avoid modifying that register. For simple pro-
grams, specifying and using base registers is very easy.

It's important to remember that while the value of “*” changes as your program is assembled, the
value used in the first operand of the USING statement does not: it has the value of the LC at
the time the USING is processed by the Assembler.

Exercises
10.5.1.(2) + A careless programmer inverted the order of his BASR and USING statements as
follows:
USING *,12
BASR 12,0
Why is this wrong? What would you expect to happen?

Chapter III: Assembler Language Programs 121

10.6. Destroying Base Registers
Suppose an error was made in writing the statement with the L instruction, such that it became
BEGIN L 6,N Load contents of N into GR2
The comment in the remarks field is correct; the instruction is wrong, because the first operand
was incorrectly written as 6 instead of 2.

The assembled program would then appear as in Figure 42.

Location Assembled Contents Statement

0000 0D60 BASR 6,0

USING BEGIN,6
0002 58606022 BEGIN L 6,N ←Wrong register!
0006 5A206026 A 2,ONE
000A 50206022 ST 2,N
---------------------------
0024 00000008 N DC F'8'
0028 00000001 ONE DC F'1'
Figure 42. Sample program segment with erroneous statement

This program would assemble correctly, since all quantities are properly specified. However, at
execution time, things go wrong quickly.

Suppose again that the program is placed in memory by the Program Loader starting at address
X'5000', so that when the L instruction is executed, register 6 contains X'00005002'. Now, the L
instruction copies a word from memory at the address given by the second operand into the reg-
ister specified by the first operand. However, the first operand in this case specifies register 6,
instead of register 2 as intended. When the Effective Address of the operand named N is calculated
during instruction decoding, register 6 contains the correct base address; but when the execution of
the L instruction is complete, register register 6 will contain X'00000008' and not X'00005002',
because the number at N was placed in register 6.

Now the fun begins. When the next instruction (A) is executed, the Effective Address calculated is
X'026' + X'00000008' = X'0000002E'
and not X'00005028', where the intended operand is found. In this case the Effective Address is
not anywhere within the program, but is somewhere among the predefined fixed fields at the low
end of memory; strange numbers will be added to register 2's initial (and unknown) contents.
Finally, the ST instruction will attempt to store a word at X'0000002A', which should cause a
storage protection exception. At this point, the program would stop.

This does not mean that if we accidentally destroy the contents of a base register, the CPU will be
able to detect the error. (See Exercise 10.6.1.) It is partly a matter of chance how much damage
such a program error can cause when the program is executed; indeed, when the CPU finally (if
ever) detects an error, all evidence pointing to the offending instruction may have been lost,
making error tracing difficult. (Register 6 may have been changed several times!) You must be
very careful to guarantee the integrity of the contents of base registers.

Remember also that the Assembler makes no checks for instructions that might alter the contents
of registers designated as base registers in USING statements.

Exercises
10.6.1.(3) + In the erroneous program in Figure 42, consider the possibility that the word at N
contained the decimal integer 20450. If the program began in memory at address X'5000', what
would be in that area of memory after the ST instruction is executed?

122 Assembler Language Programming for IBM System z™ Servers Version 2.00
10.7. Calculating Displacements: the Assembly Process, Pass One
Now, we'll examine more closely how the Assembler computes bases and displacements.

You can visualize assembly as making two passes over the program: that is, the Assembler
“reads” the program twice. On the first pass, the Symbol Table is built; on the second pass, data
in the Symbol Table is used to help generate the desired instructions and data.

First, you will remember that values are assigned to symbols by the Assembler as follows:
1. A statement is read and examined to determine its general character. It is also saved in a
temporary place so it can be read again during the second pass over the program.
2. If the statement will generate instructions or data, the Assembler adjusts the Location
Counter (if necessary) to satisfy alignment requirements, so that instructions begin on
halfword boundaries, words begin on word boundaries, etc.
3. If a symbol appears in the name field of the statement, it is entered into the Assembler's
Symbol Table, and (if it is not an EQU statement) is given the value of the Location
Counter. That is, the symbol is defined, as described in Section 7.6 on page 93. (Of course, it
will be an error if the symbol is already in the table with a value; this is called multiple or
duplicate definition.)
4. The rest of the statement is scanned; if any other symbols are encountered, they are entered
into the Symbol Table (if not there already), but numeric values are not assigned to their
attributes. That is, if the symbol is not yet defined, it remains “undefined”.
5. The length of the instruction or data to be generated from the statement is then added to the
Location Counter. No data or instructions are generated at this time, however.

This process is repeated for each statement, until the end of the program is reached. Because the
Assembler has made a complete scan or “pass” over the program's statements, this is called “Pass
One” of the assembly. At this point the Symbol Table contains all the symbols in the program,
whether or not they are defined.

The first assembly pass is sketched in Figure 43 on page 124, but the sketch is incomplete in
many ways. For example, an EQU statement lets you assign a value to a symbol, and that value
is taken from the expression in the operand field. Figure 43, however, only shows values being
assigned to symbols using the Location Counter. It also omits any description of macro-
instruction statements, and how symbols are treated in erroneous statements.

Chapter III: Assembler Language Programs 123

 ┌──────────────┐
┌─ ┤Read statement│
 │ and save it │
│ └──────┬───────┘
│ 
│ ┌─┴────┐yes ┌─────────┐
│ │ END ?├──── ┤to Pass 2│
│ └─┬────┘ └─────────┘
│ no
│ yes ┌──┴─────┐
├─────┤comment?│
 └──┬─────┘
│ no
│ ┌────┴──────┐ ┌───────────┐ ┌────────┐
│ │Instruction├──── ┤ symbol in ├─── ┤is it in│
│ │statement? │yes │name field?│yes │sym─tbl?│
│ └────┬──────┘ └┬──────────┘ └┬────┬──┘
│ │no no│ ┌────────┐ no│ │yes
│   │enter it├──┘ 
│ ┌───┴──────┐ │ └───┬────┘ ┌───┴───┐
│ │Undefined │ │  no│does it│
├────┤mnemonic: │ │ ├────────┤have a │
 │note error│ │  │value? │
│ └──────────┘ │ ┌────┴────┐ └───┬───┘
│ │ │set value│ yes│
│ ├─┤ from LC │ 
│ ┌────────┐  └─────────┘ ┌──────┴───┐
│ │enter in│ ┌──────┴───────┐ │note error│
│ │table, │ Y│symbol(s) in │ └──────┬───┘
│ │no value├─┤operand field?├────────────┘
│ └──┬─────┘ └──────┬───────┘
│  no
│ ┌──┴───────────────┴───────────────┐
└────┤increment LC by instruction length│
└──────────────────────────────────┘
Figure 43. Sketch of pass one of an assembly

Exercises
10.7.1.(2) In the following program segment, resolve the implied addresses into base-
displacement form, and fill in the four blank fields.
Loc Object Code Statement

5000 0DA0 BASR 10,0

5002 USING *,10
5002 41D0____ LA 13,SAVE
5006 4110____ LA 1,PARM
500A 4DE0____ BAS 14,SUB
500E 50______ ST 0,TBL(15)
- - -
512C SAVE DS 18F
5174 PARM DC A(TBL)
5178 TBL DS 10F
51A0 SUB STM 14,12,12(13)

124 Assembler Language Programming for IBM System z™ Servers Version 2.00
10.8. Calculating Displacements: the Assembly Process, Pass Two
The Assembler now begins a second pass over the program by retrieving the statements from their
temporary storage place. The Assembler creates machine language object code, converting
instruction mnemonics to operation codes and using data in the Symbol Table to evaluate all
expressions appearing in the statements.

The overall flow of the second pass of the assembly process is sketched in Figure 44. As noted
following Figure 43 on page 124 describing the first pass of the assembly, this is a very abbrevi-
ated description, so don't attach great significance to the precise sequence of processing actions
implied by the diagram.

┌───────────┐
┌── ┤Read, Print├─┬──────────────────────────────┐
 │ statement │  
│ └────┬──────┘ │ │
│  │ │
│ ┌───┴────┐yes │ │
│ │comment?├────┘ │
│ └───┬────┘ │
│ no │
│ ┌───┴────┐yes ┌─────────────────────────┐ │
│ │ USING ?├─── ┤enter data in USING Table├── ─┤
│ └───┬────┘ └─────────────────────────┘ 
│ no │
│ ┌───┴───┐yes ┌─────────────────────────────┐ │
│ │ DROP ?├─── ┤delete entry from USING Table├─┘
│ └───┬───┘ └─────────────────────────────┘
│ no
│ ┌──┴───┐yes ┌─────────────────────┐
│ │ END ?├─── ┤Create object module;│
│ └──┬───┘ │return to Supervisor │
│ │no └─────────────────────┘
│ 
│ ┌───┴────────┐yes ┌────────┐yes ┌───────┐
│ │machine ├─── ┤implied ├─── ┤compute│
│ │instruction?│ │address?│ │ value │
│ └───┬────────┘ └──────┬─┘ └───┬───┘
│ no no  
│ ┌───┴─────┐yes ┌───────┐ │ ┌────────┴────────────┐
│ │define a ├─── ┤convert│ │ │check USING Table for│
│ │constant?│ │ data │ │ │a valid displacement │
│ └───┬─────┘ └──┬────┘ │ └─┬───────────┬───────┘
│ no  │ OK none
│ ┌─────┴────┐ │ ├───┘ ┌───────┴──────┐
├─┤note error│ │  │addressability│
 └──────────┘ │ │ │ error │
│ ┌───────────────────┴──────┴─┐ └───────┬──────┘
└──┤Generate instruction or data├────────────┘
└────────────────────────────┘
Figure 44. Sketch of pass two of an assembly

When a USING statement is encountered, the Assembler enters the value and relocation attri-
butes of the first operand expression (the base_location), and the value of the second expression
(the base_register number), into a USING Table.

Figure 45 on page 126 shows an example of a USING Table with one entry. The abbreviations
“basereg” and “RA” denote respectively the base_register specified in the second operand of the
USING statement, and the relocation attribute of the base_location expression from the first

Chapter III: Assembler Language Programs 125

 operand of the USING statement. For now, the only importance of the relocation attribute is
that it indicates whether the symbol is relocatable (RA=01) or absolute (RA=00).

┌───────┬───────────────┬────┐
│basereg│ base_location │ RA │
├───────┼───────────────┼────┤
│ 6 │ 00000002 │ 01 │
└───────┴───────────────┴────┘
Figure 45. USING Table with one entry

When a subsequent instruction operand contains an implied address, the Assembler compares the
value and relocation attribute of that expression to each entry in the USING Table. If a matching
relocation attribute is found, and a valid displacement can be calculated from
displacement = (implied address value) − (base_location value)
then the Assembler inserts the computed displacement and the corresponding base_register digit
into the addressing halfword of the instruction. The Assembler has resolved the implied address
into base-displacement form, and the implied address is addressable.

For example, consider the second and third statements in Figure 41 on page 120. If the initial
LC value assigned to the program was zero, the USING Table would contain an entry for register
6, with an associated relocatable base_location value of X'00000002', the value of the symbol
BEGIN illustrated in Figure 45.

When the third statement in Figure 41 on page 120 is processed, the value of the implied address
is the value of the symbol N, or X'00000024'. The computed displacement is
X'00000024' − X'00000002' = X'022'
as we saw previously, so the completed addressing halfword is X'6022'.

Here is a way to summarize the description of operand address resolution: at assembly time, the
Assembler computes a displacement:
displacement = (operand_location) − (base_location)
while at execution time, the CPU reverses this computation:
(operand address) = displacement + (base address)

Assembler-calculated displacements
The Assembler at assembly time does the reverse of what the CPU does at
execution time.

It is important to give correct information in a USING statement because it specifies the intimate
connection between the base_location at assembly time and the base address at execution time.
Remember that the difference between assembly-time locations and execution-time addresses in a
relocatable program is only a single constant value,

Exercises
10.8.1.(2) + In the blank fields provided in the six instructions below, show the values and
addressing halfwords provided by the Assembler. Assume that the Location Counter values are
as shown in the column headed “LOC”.

126 Assembler Language Programming for IBM System z™ Servers Version 2.00
 Loc Object Code Statement

10A20 USING *,11

10A20 5830____ L 3,X
10A24 4A30____ AH 3,Y
10A28 10__ LPR 4,3
10A2A 9034____ STM 3,4,Z
10A2E 4240____ STC 4,W
10A32 4770____ BC 7,*+24
- - - - - -
10A76 W DS X
10A78 Z DS 2F
10A80 Y DC H'-72'
10A84 X DC A(Z-W)

10.9. Multiple USING Table Entries

You can create more than one entry in the USING Table, so it is possible to have more than one
valid resolution of an implied address into base-displacement form. Suppose we add another
USING statement to the program, as in Figure 46:

Location Name Operation Operand Remarks

0000 BASR 6,0

USING *,6 Original USING statement
0002 BEGIN L 2,N
USING *,7 Added USING statement
0006 A 2,ONE
000A ST 2,N
---------------------------
0024 N DC F'8'
0028 ONE DC F'1'
Figure 46. Program segment with second USING statement

For now, we ignore the fact that the contents of register 7 are unknown.

When the second USING is processed, the value of the Location Counter is X'00000006', so the
Assembler makes a second entry in the USING Table, as shown in Figure 47.

┌───────┬───────────────┬────┐
│basereg│ base_location │ RA │
├───────┼───────────────┼────┤
│ 6 │ 00000002 │ 01 │
├───────┼───────────────┼────┤
│ 7 │ 00000006 │ 01 │
└───────┴───────────────┴────┘
Figure 47. USING Table with multiple entries

When the next statement

A 2,ONE
is processed, two possible valid resolutions are available for the implied address specified by the
symbol ONE:
• If register 6 is used as a base register, the displacement is
X'00000028' − X'00000002' = X'026'
and the addressing halfword would be X'6026' (as in Figure 42 on page 122).

Chapter III: Assembler Language Programs 127

 • If register 7 is used as a base register (again, ignoring the fact that its run-time contents are
unknown), the Assembler determines that the displacement is
X'00000028' − X'00000006' = X'022'
and the addressing halfword would be X'7022'. (Similarly, the ST instruction could have an
addressing halfword X'701E'.)

The Assembler must make a choice: which of the two valid resolutions should be selected for the
completed machine language instruction?

The Assembler uses these resolution rules:

1. Find all USING table entries whose relocation attribute matches that of the implied address
to be resolved.
2. Choose the base register that leads to the smallest displacement.
3. If more than one base register provides the same smallest displacement, choose the corre-
sponding highest-numbered register.

Thus, the assembled program would appear as shown in Figure 48 below:

Location Assembled Contents

00000 0D60
00002 58206022 Based on register 6
00006 5A207022 Based on register 7
0000A 5020701E Based on register 7
-----------------
00024 00000008
00028 00000001
Figure 48. Assembled contents when two USINGs are active

At this point, you could (correctly) observe that this program is seriously flawed, because the con-
tents of GR7 at execution time could be “anything”. When the A and ST instructions are exe-
cuted, their operand addresses are likely to cause errors (whether or not they are detected
immediately!).

The important lesson in this example is that the Assembler has no way of knowing that the infor-
mation supplied in the statement
USING *,7
may not be valid. It can only trust that you have provided correct base_location and base_register
data it can use to resolve implied addresses.

10.10. The DROP Assembler Instruction

It is also possible to delete entries from the USING Table. The DROP instruction tells the
Assembler to remove the information corresponding to a given register. Its general form is
DROP register
where the “register” operand specifies the USING Table entry to be deleted.

For example, if the statement

DROP 6
was inserted after the third statement, the L instruction named BEGIN in Figure 47 on page 127,
the initial USING Table entry for register 6 would be deleted, and the USING Table would
appear as in Figure 49 on page 129:

128 Assembler Language Programming for IBM System z™ Servers Version 2.00
 ┌───────┬───────────────┬────┐
│basereg│ base_location │ RA │
├───────┼───────────────┼────┤
│ │ empty │ │
├───────┼───────────────┼────┤
│ 7 │ 00000006 │ 01 │
└───────┴───────────────┴────┘
Figure 49. USING Table after D R O P statement

Another form of the DROP statement is

DROP
with no operand! This will cause all USING Table entries to be deleted. While this might seem
odd, it's useful: if you have reached a part of your program where no valid base registers will be
available at execution time, DROPping all the USINGs will avoid unexpected or unintended
resolution of implied addresses in later parts of your program.

Exercises
10.10.1.(1) + A frustrated programmer wrote the statements
DEAD EQU 101
DROP DEAD
How would you expect the Assembler to deal with this impertinence?

10.10.2.(3) + For each statement of the following program segment, show what will appear in
the USING Table following each USING and DROP statement. Then, use that information to
show the assembled machine language object code produced from the program segment.
Assume the program segment begins at location X'4000'.
BASR 9,0
USING *,9
L 4,*+54
BASR 10,0
USING *,10
L 3,*+52
DROP 9
L 2,*+48
DROP 10
L 1,10(0,9)
What would be found in register 1 after the last instruction is executed? How does it depend
on the address where the instructions are loaded into memory?

10.11. Addressability Errors

Addressability errors have many causes. These examples show some of the ways they can arise.
1. An operand value is larger than any USING Table base location value.
BASR 6,0
USING *,6
L 2,*+5000
Suppose the value of the Location Counter after the BASR instruction is X'002468'. This
means that the value of the operand *+5000 is
X'002468' + X'1388' = X'0037E0'
and that the calculated displacement (for register 6) would be
X'0037E0' − X'002468' = X'1388'

Chapter III: Assembler Language Programs 129

 which is too large for a 12-bit displacement field. This means the operand is not addressable
with 16-bit addressing halfwords.
2. An operand value is smaller than any USING Table base_location value. Again assuming
the value of the LC after the BASR instruction is X'002468':
BASR 6,0
USING *,6
L 2,*-32
In this case the operand value is X'002448', leading to a negative calculated displacement,
X'FFFFFFE0'. This means the operand is not addressable with 16-bit addressing halfwords.
3. The USING Table is empty. Suppose a second DROP statement is added after the A
instruction in the program shown in Figure 46 on page 127, specifying register 7:
DROP 7
Then, the remaining entry in the USING Table would be deleted, and the USING table
would appear as in Figure 50 below.

┌───────┬───────────────┬────┐
│basereg│ base_location │ RA │
├───────┼───────────────┼────┤
│ │ empty │ │
├───────┼───────────────┼────┤
│ │ empty │ │
└───────┴───────────────┴────┘
Figure 50. USING Table after second D R O P statement

Because there are no entries left in the USING Table, there is no way for the Assembler to
resolve the implied addresses of any following instructions, and an addressability error would
be noted for those statements.

Exercises
10.11.1.(3) + Suppose these instructions are assembled and then executed in a program:
B BASR 6,0
USING *,6
L 2,B
What (if anything) would you expect to appear in GR2?

10.12. Resolutions With Register Zero (*)

Although USING statements specifying absolute base_locations are rare, they are allowed; abso-
lute implied address expressions follow the same resolution rules as relocatable expressions. In
most cases, there is no entry in the USING Table with an absolute base address, so the Assem-
bler proceeds as though a hidden or implied
USING 0,0 Assembler's implicit USING
is always present. You can think of the USING Table appearing like this:

┌───────┬───────────────┬────┐
│basereg│ base_location │ RA │
├───────┼───────────────┼────┤
│ 0 │ 00000000 │ 00 │ Assembler's hidden USING-Table entry
├───────┼───────────────┼────┤
│ ─ │ etc. │ ── │
└───────┴───────────────┴────┘

130 Assembler Language Programming for IBM System z™ Servers Version 2.00
 Thus, an implied address such as
LA 3,1000 Implied address = 1000 = X'3E8'
would be resolved to the addressing halfword X'03E8', with base register zero.

In the example in Figure 34 on page 109, we saw an instruction with an absolute implied S2
operand:
43000468 IC 0,1128

The generated object code shows that the second operand was resolved with base register zero.

Now, suppose you wrote a USING statement with an absolute base address:
USING 400,9 Base Address = 400 = X'190'
LA 3,1000 Implied address = 1000 = X'3E8'
so the USING Table would look like this:

┌───────┬───────────────┬────┐
│basereg│ base_location │ RA │
├───────┼───────────────┼────┤
│ 0 │ 00000000 │ 00 │
├───────┼───────────────┼────┤
│ 9 │ 00000190 │ 00 │
├───────┼───────────────┼────┤
│ ─ │ etc. │ ── │
└───────┴───────────────┴────┘

The Assembler follows its usual resolution rules, and finds that there are two valid resolutions
with addressing halfwords X'03E8' and X'9258'. Since the latter provides the smallest displace-
ment, the Assembler chooses the resolution with base register 9! Fortunately, the Assembler will
issue a diagnostic message whenever a USING with an absolute operand appears to overlap with
its implicit USING 0,0 statement.

If the original resolution using base register zero is required no matter what other USINGs are
active, the operand should be written explicitly, as
LA 3,1000(0,0) Explicit displacement=1000, base=index=0

Thus, we add one further resolution rule when absolute implied addresses have not been resolved
according to the three previous rules:
4. If no previous resolution has been completed, and the implied operand is absolute and has
value between 0 and 4095, use General Register 0 as the base register and the value of the
implied address expression as the displacement.

This behavior is used often in Assembler Language programs. If any implied address has absolute
nonnegative value, a valid displacement can always be computed only if that value does not
exceed 4095.63

According to the rules for evaluating expressions, attempting to compute a displacement for a
relocatable symbol using an absolute base_location would require that the displacement be reloc-
atable, which is invalid. That is, a valid displacement cannot be calculated from
(absolute) displacement = (relocatable operand) − (absolute base_location) (??)

Similarly, an absolute implied address cannot be resolved into base-displacement form using a reg-
ister whose base_location is relocatable, since a valid displacement cannot be computed from
(absolute) displacement = (absolute base_location) − (relocatable operand) (??)

63 Section 20 shows how to use a much larger range of displacement values with long-displacement instructions.

Chapter III: Assembler Language Programs 131

 It is possible (but not recommended!) to specify USING statements with register zero as the base
register,64 but the Assembler will always assign a base address of zero to register zero.

Exercises
10.12.1.(1) + The Assembler tries to resolve absolute implied addresses into an addressing
halfword containing a zero base digit, and a displacement of the value of the implied address.
Do you think this is desirable? Would you prefer that the Assembler diagnose absolute implied
addresses as an error?

10.13. Summary
In summary, the ordinary USING statement provides two major features:
1. A base_location relative to which the Assembler can calculate displacements.
2. A base_register to be used in addressing halfwords of implied addresses whose displacements
were calculated as being addressable with this register.

The information conveyed in a USING statement is only, and no more than, a promise that you
make to the Assembler. You are asserting that if it uses the base_location and base_register speci-
fied in your USING statement to calculate addressing halfwords at assembly time, then the CPU
will calculate correct Effective Addresses at execution time.

The rules for resolving implied addresses into base-displacement form can be difficult to
remember, and forgetting them can sometimes lead to programming errors that are difficult to
correct.65

USING Resolution Rules

1. The Assembler searches the USING Table for entries with a relo-
cation attribute matching that of the implied address (which will
almost always be simply relocatable, but may be absolute).
2. For all matching entries, the Assembler checks to see if a valid dis-
placement can be derived. If so, it will select as a base register the
register that yields the smallest displacement.
3. If more than one register yields the same smallest displacement, the
Assembler will select the highest-numbered register as a base register.
4. If no resolution has been completed, and the implied address is abso-
lute, try a resolution with register zero and base zero.

A minor addition to these rules will apply when we discuss instructions with long 20-bit signed
displacements in Section 20.
The relocatability attribute of any given symbol almost always has a single value; it won't matter
if we ignore “complex relocatability” situations for now, because they don't affect addressability.
However, it is not unusual for programs to use many different relocatability attributes to correctly
describe its symbols.
In Chapter XI we will see powerful extensions to the USING statement — Labeled and Dependent
USINGs — that give you much greater control over USING resolutions.

64 When we discuss Dummy Control Sections in Section 39, we will see that there can be times when specifying a zero
base register is a reasonable practice.
65 Some programmers note that “USING” is part of “confusing”.

132 Assembler Language Programming for IBM System z™ Servers Version 2.00
10.13.1. How the Assembler Helps
The Assembler simplifies many programming tasks:
1. It automatically resolves addresses into the base-displacement and other forms used by
System z. The Assembler determines the needed base and displacement so that correct Effec-
tive Addresses will be computed at execution time.
2. Rather than remembering that operation code X'43' places a byte from memory into the
right end of a general register, a mnemonic operation code IC (“Insert Character”) gives a
simple indication of what the operation code does.
3. Symbols let you name areas of memory and other objects in your program.
4. Diagnostic messages help you find possible errors and oversights.
5. The Assembler converts data from convenient external representations into internal forms.
6. It creates relocatable object code to be combined with other programs by the linker.
7. It provides lots of other helpful information such as symbol and register cross-references.
8. Using macro-instructions, you can define your own instruction names to supplement existing
instructions, and your macro instructions can make use of previously defined sequences of
statements, including other macros!
9. The High Level Assembler provides an optional summary of all USING Table activity, in
the form of a USING Map. If you specify USING(MAP) as part of the parameter string when
you invoke the High Level Assembler, it will display all USING and DROP activity for the
entire program.

Exercises
10.13.1.(3) Some older assemblers let you redefine symbols in EQU statements. Thus, you
could write
A Equ 6 Define a value for A
- - - Write statements using A's value
A Equ 32 Define a new value for A
- - - Statements using A's new value
How would the assembler's treatment of the Symbol Table be changed? What would happen if
any symbol could be redefined?

Terms and Definitions

addressability
The ability of the Assembler to calculate a displacement and assign a base register to an
implicit addressing expression, using information in the USING Table.
addressability error
The inability of the Assembler to derive an addressing halfword for an implicit operand.
base_location
The first operand of a USING instruction at assembly time.
base_register
The second operand of a USING instruction at assembly time.
DROP assembler instruction
An instruction telling the Assembler to eliminate one or more entries from its USING Table.
Symbol Table
A table used by the Assembler to hold the names, values, and attributes of all symbols in a
program.
USING statement
A promise to the Assembler that addressing halfwords can be derived correctly from the
base_location and base address information provided in the instruction.

Chapter III: Assembler Language Programs 133

 USING Table
An internal table used by the Assembler to hold information provided in USING
instructions.

Programming Problems
Problem 10.1.(1) Write and assemble a program segment like the one in Figure 41 on
page 120, with the following additional statements:

1. Following the last DC statement, place an Assembler instruction statement with the mne-
monic END in the operation field.
2. Replace the dotted line that means “twenty-two additional bytes” with an Assembler
instruction statement with DS in the operation field and 22X in the operand field.
3. Preceding the first statement place an Assembler instruction statement with the mnemonic
START in the operation field, and X'5000' in the operand field.

Assemble the program, and save the Assembler's listing. Then, replace the X'5000' operand in
the START statement with the X'84E8', and re-assemble the program, saving the second listing.
Verify that the assembled machine language program is the same in both listings, and that the
same bases and displacements are calculated by the Assembler for all instructions that require
them. If time and budget permit, do the same for the programs in Figures 39 and 40.

134 Assembler Language Programming for IBM System z™ Servers Version 2.00
Chapter IV: Defining Constants and Storage Areas

IIIIIIIIII VV VV
IIIIIIIIII VV VV
II VV VV
II VV VV
II VV VV
II VV VV
II VV VV
II VV VV
II VV VV
II VV VV
IIIIIIIIII VVVV
IIIIIIIIII VV

The three sections of this chapter treat the DC (Define Constant) and DS (Define Storage) assem-
bler instruction statements, and methods used to define data and storage areas in Assembler Lan-
guage programs.
• Section 11 describes the Assembler's basic data definition instruction, DC.
• Section 12 discusses the most often-used data types, introduces the powerful constant-
referencing mechanism provided by literals, and the LTORG instruction to control their
location in your program.
• Section 13 demonstrates methods for defining and describing data areas in ways that simplify
data manipulation problems, including the very useful DS, EQU, and ORG instructions.

Chapter IV: Defining Constants and Storage Areas 135

11. Defining Constants

11 11
111 111
1111 1111
11 11
11 11
11 11
11 11
11 11
11 11
11 11
1111111111 1111111111
1111111111 1111111111

In the preceding sections we used the DC assembler instruction to create constants in the
program. Now we'll describe basic rules for defining constants of any type.

System z supports a very rich variety of data types, and various lengths and precisions can be
specified for most of them. Among the “native” data types the Assembler supports are:
1. Fixed-point data (two's complement binary), signed and unsigned
• doubleword precision (64 bits)
• word precision (32 bits)
• halfword precision (16 bits)
• byte precision (8 bits)
2. Logical data (binary and hexadecimal)
• doubleword (64 bits)
• word (32 bits)
• one byte (8 bits)
• varying-length (1 to 256 bytes)
3. Address-valued (3, 4, and 8 bytes)
4. Character data (1 to 256 bytes) in EBCDIC, Graphic (Double-Byte), ASCII, and Unicode
formats. 66
5. Decimal data (sign-magnitude representation)
• zoned decimal (1 to 16 digits)
• packed decimal data (1 to 31 digits)
6. Floating-point data (sign-magnitude representation in binary, hexadecimal, and decimal
formats)
• short precision (4 bytes)
• long precision (8 bytes)
• extended precision (16 bytes)

66 We'll investigate some non-EBCDIC character data types in Section 27.

136 Assembler Language Programming for IBM System z™ Servers Version 2.00
 Data for each of these types is defined using the DC (“Define Constant”) assembler instruction,
with many options for each type.

Be Careful!
The DC instruction doesn't really define an unchangeable constant value,
because you can change it at execution time. (It's only constant if you
don't change it!) The instruction might better be called “Define Data
with Initial Value”. We'll see that literals can help you define what
appear to be “true constants” In Section 13.9 on page 174.

You will usually write values in data definitions in the external representation most convenient for
you. The Assembler then converts the data into the internal form used by your program, the
CPU, and other devices.
As indicated in previous examples, a DC assembler instruction statement may have name, opera-
tion, operand, and remarks field entries; the operation and operand field entries are required.

11.1. Defining Constants

We'll start with the F-type constant we saw in several earlier examples. The assembler instruction
statement
DC F'8'
creates a word binary integer constant (X'00000008'), placed on a word boundary. In this state-
ment, four items were specified or implied:
1. The type of desired conversion from the external form you wrote in the statement, to an
internal representation. For type F, the decimal value is converted to a two's complement
binary integer.
2. The nominal value of the constant, the decimal value 8.
3. The length of the constant, which for type F is implicitly four bytes.
4. The alignment in memory of the constant, implicitly on a word boundary for type F.

Some other types of conversion, and the letters that specify the types, are character (C), binary
(B), hexadecimal (X), halfword binary integer (H), and address constant (A and Y). Here are
examples of some of these types:
DC H'8' halfword binary integer
DC C'/' character constant
DC X'61' hexadecimal constant
DC B'01100001' binary constant
The last three constants are each one byte long, and contain identical bit patterns.

Important to remember
The binary, character, and hexadecimal self-defining terms use the same
notation as constants of those types. It can be easy to forget that a self-
defining term is just a number, while the operand of a DC statement
defines an initial value in storage.

Exercises
11.1.1.(1) Constants of types B, C, and X are written in a form very much like self-defining
terms of the same types, as in
DC B'11010001',C'J',X'C5'
Constants with decimal values are written as (for example) F-type constants, as in

Chapter IV: Defining Constants and Storage Areas 137

 DC F'8'
Why do you think the designers of the Assembler Language made this choice, rather than
allowing you to write this constant in the simpler form
DC 8 ? Alternative to F'8' ?

11.2. DC Instruction Statements and Operands

The operand field entry contains one or more operands separated by commas. An operand of a
DC statement has four parts, with no spaces between them:
1. a duplication factor (if omitted, it defaults to 1)
2. a letter (or pair of letters67) specifying the type of representation
3. zero to four modifiers
4. the nominal value of the constant, enclosed in a pair of delimiters. The delimiters are either
apostrophes or parentheses, depending on the type of the constant.

Of these four parts, only the second (the type) and fourth (the nominal value) are required. In the
example above, F'8' specifies type F and nominal value 8.

The three important modifier types are length, scale, and exponent. 68 Only length will be discussed
here.

DC Operands
This may help you remember the order of of the fields: duplication factor
(d), type (T), modifiers (m), and nominal value (V), where the required
type and value are specified in capital letters: dTmV

The nominal value part of the operand is specified in different ways for different constant types.
For F-type constants, the value is written as a string of decimal digits, preceded by an optional +
or − sign and followed by an optional decimal exponent. For B-type constants, the value is
expressed as a string of binary digits, so F'110' and B'110' are quite different.
The constant type also determines what conversion from external to internal representation should
be performed: the internal representations of F'110' (binary word), X'110' (hexadecimal con-
stant), E'110' (short floating-point), Z'110' (zoned decimal), and P'110' (packed decimal) are dif-
ferent, even though they all have the same nominal value.

11.2.1. Blanks in Nominal Values

Some constant types delimited by apostrophes (like F'8') let you put blank spaces between the
digits to improve readability. For example, you can write either
DC F'12345678'
or
DC F'12 345 678'
We'll see more examples as we investigate various data types.

67 We'll discuss type extensions in Section 12.8.

68 HLASM supports another constant modifier and attribute, “Program”. It is used almost entirely in conditional
assembly macro-instruction statements.

138 Assembler Language Programming for IBM System z™ Servers Version 2.00
11.3. Boundary Alignment
Many constant types have “natural” boundary alignments. For example, the F-type constant is
naturally word-aligned. Other constant types don't have a natural alignment; Table 32 on
page 153 (Section 12.5) and Table 33 on page 158 (Section 12.8) summarize default alignments
for many common data types.

There is an important relationship between boundary alignment and the presence of a byte-length
modifier, which helps you align constants and data properly.69 This will be discussed shortly, in
Section 11.4.

By default, the Assembler initializes the Location Counter to zero. If you specify an initial LC
value at the start of the program, the Assembler rounds it up (if necessary) to a multiple of eight
to ensure that the program begins on a doubleword boundary. 70 Then, if a constant must fall on a
specific boundary, the Assembler only needs to be sure that the Location Counter is divisible by
the proper power of two (such as 2, 4, or 8) at the location of the leftmost byte of the constant.

The Linker and Program Loader respect this assumed alignment for the beginning of the
program. This guarantees that data and instructions will be aligned on the desired boundaries
when the program is loaded into memory for execution.

Suppose that after a sequence of instructions has been processed, the value of the LC is X'00012E'
(on a halfword boundary). If another machine instruction is assembled at this point, it would
begin on this halfword boundary between two word boundaries. But if the next statement is
instead
DC F'8'
the Assembler must place it on a word boundary to force the desired alignment.
Generating the four bytes of this constant beginning at the halfword-aligned location X'00012E'
could be incorrect, because instructions referring to word constants normally expect the address to
be on a word boundary. To avoid alignment errors, the Assembler automatically skips enough
bytes to obtain the desired alignment. The LC would be increased to X'000130' (now word-
aligned) before the word constant is assembled. The LC has value X'000134' after the constant is
processed; it would be X'000132' if automatic alignment was not done.

Automatic alignment is not performed (bytes are not automatically skipped) if:
1. it isn't needed: that is, the LC happens to fall on the desired boundary; or
2. the type of constant specified doesn't require alignment, such as types C, B, or X (among
others); or
3. a length modifier is present.

You can tell the Assembler to do no boundary alignment even if the constant type normally
requires it.71

69 We'll see in Section 17.5 that constants can also have bit-length modifiers, but here we use the term “length modifier”
to mean “byte length modifier”.
70 HLASM provides the SECTALGN option to let you specify even more restrictive boundaries. See the High Level
Assembler Programmer's Guide for details.
71 For details, consult the High Level Assembler Programmer's Guide for the NOALIGN option. However, few pro-
grams use this option.

Chapter IV: Defining Constants and Storage Areas 139

11.4. Length Modifiers
Length modifiers let you specify (within limits) a constant's exact length in bytes.72 When used,
we say that an explicit length was specified.

A length modifier is written immediately following the letter specifying the data type, in the form
Ln or L(expr)

The quantity “n” is an unsigned, nonzero decimal self-defining term, and “expr” is a positive
absolute expression enclosed in parentheses. The length modifier specifies the constant's length.
Any symbols appearing in the length modifier expression must be defined before they are used in
the length modifier expression, so that it can be evaluated immediately.73 For example, the state-
ments
DC FL3'8'
and
DC FL(2*4-5)'8'
both cause the three-byte constant X'000008' to be assembled at the location specified by the
Location Counter; no boundary alignment is performed. In practice, length modifiers are used
mostly with constants of types C and X, and very rarely with type F and other normally-aligned
constants.

Because alignment is automatic only

(1) when the length is implied (that is, when no length modifier is given), and

(2) for constant types for which alignment is the default action,

the two statements

DC F'8'
and
DC FL4'8'
define the same constant, but the first is automatically aligned and the second is not.

When a symbol appears in the name field of a DC assembler instruction statement, boundary
alignment affects the symbol's value. Suppose the value of the LC is X'00012E' when each of the
statements in Figure 51 is encountered.

Explicit DC FL4'8' Explicit length = 4 bytes, not aligned

Implied DC F'8' Implied length = 4 bytes, word aligned
Figure 51. Implied and explicit length specifications

Because no boundary alignment is performed for the first constant, the value of the symbol
Explicit will be X'00012E'. For the second constant, two bytes must be skipped to achieve the
required word alignment. If we refer to the constant using the symbol Implied, the symbol will
have the value of the location of the first byte of the constant, X'000130'.

Symbol definition
When a symbol is defined, it is given its value after bytes are skipped for
boundary alignment.

72 It is also possible to specify a constant's length in bits, using a bit-length modifier. They have specialized uses; we will
describe them in Section 17.5 on page 257.
73 Sometimes the Assembler will let you define symbols after they are used in length modifier expressions, but it's safest
to make sure they're defined before they're used in length modifiers.

140 Assembler Language Programming for IBM System z™ Servers Version 2.00
 As a general rule, the Assembler never automatically assigns the location of skipped bytes as the
value of a symbol.74 This includes cases where a byte must be skipped to ensure that an instruc-
tion begins on a halfword boundary. When bytes are skipped to achieve alignment of a following
constant or instruction, the Assembler will insert bytes containing all zero bits into the bytes
skipped.
Proper boundary alignments can be important: some instructions require aligned operands. Also,
operand misalignment can affect the performance of your applications, because the CPU may
need to bring more data from memory than your instruction actually requires.

Exercises
11.4.1.(2) What data is generated by these constants?
(1) DC FL1'-127'
(2) DC FL2'+128'
(3) DC FL3'-99,+99'
(4) DC FL1'+127'

11.4.2.(1) + For these constants:

(1) DC F'11',FL3'12',FL3'13'
(2) DC F'21',FL2'22',FL2'23'
(3) DC F'31',FL4'32',FL3'33'
on what boundaries are the constants 13, 23, and 33 aligned?

11.5. Duplication Factors and Multiple Operands

A duplication factor (sometimes called a multiplicity, replication, or repetition factor) specifies the
number of times the constant or constants in the operand will be duplicated; it is written imme-
diately preceding the letter specifying the constant type. It may be either an unsigned decimal self-
defining term, or a nonnegative absolute expression enclosed in parentheses. Any symbols
appearing in the duplication factor expression must be defined prior to their use in the duplication
factor.75 For example, both
Three8s DC 3F'8' Duplication factor 3
and
Three8s DC (5/2+1)F'8'
are equivalent to writing the three statements
Three8s DC F'8' Three statements
DC F'8'
DC F'8'

You can write more than one operand in the operand field entry of a DC instruction, so you will
get the same result by writing
Three8s DC F'8',F'8',F'8' Three operands

Duplication factors apply only to operands, not to statements.

For example, if you write

DC F'7',2F'4',3F'9'

74 You can find ways to do it if you like, but there's no real value in doing so. (Why refer to something so uninter-
esting?)
75 Sometimes the Assembler will let you define symbols after they are used in duplication factor expressions, but it's
safest to make sure they're defined before they're used in duplication factors.

Chapter IV: Defining Constants and Storage Areas 141

 the Assembler generates six word-length, word-aligned constants: one with value 7, two with
value 4, and three with value 9.

There are occasionally important uses for DC statement operands with a zero duplication factor.
In such a case, the Assembler first skips as many bytes as necessary to properly align the constant
specified by the operand, and then generates no data for that operand. This means that the
Location Counter is not further incremented for that operand, after alignment (if any). Thus we
could generate a word-aligned 4-byte constant with a statement like
DC 0F'0',FL4'-1'
or even
DC 0F,FL4'-1'

Zero duplication factors are discussed further in Section 13.2 on page 160.

11.6. Multiple Nominal Values

For almost all constant types, the nominal value may actually be a sequence of values separated
by commas, as in
Three8s DC F'8,8,8' One operand, 3 nominal values

This is equivalent to
Three8s DC 3F'8' One operand, duplication factor 3
and
Three8s DC F'8',F'8',F'8' Three operands

Which format you use is largely a matter of taste and convenience. For example, you could
specify a table of constants with a statement such as:

TABLE DC F'1,2,3,4,5,6,7,8,9,10'
Figure 52. Multiple constants

Each generated constant is a word integer, aligned on a word boundary.

In cases where multiple constants are specified, any symbol in the name field (in this example,
TABLE) is given the value and Length Attribute associated with the first constant generated.

Exercises
11.6.1.(2) A meticulous programmer determined that 10 9 is the largest power of ten that will fit
in a word binary integer, and wanted to define a constant of that value. To ensure that he
wrote the constant with the correct number of zeros, he wrote the statement
TEN_to_9 DC F'1,000,000,000'
What would be generated? What would you recommend?

11.6.2.(1) What will be generated by this constant?

DC 2F'1,-1'

142 Assembler Language Programming for IBM System z™ Servers Version 2.00
11.7. Length Attributes
Although its many benefits will become clear later, we noted in Section 7.3 on page 89 that the
Length Attribute of a symbol can be very useful. Its value is determined by the statement in
which the symbol is defined.
1. The Length Attribute of a symbol naming an instruction is the length of the instruction.
Thus, the Length Attribute of the symbol LOAD in
LOAD LR R7,R3 (from Example 8_4_1 on page 100 in Section 8.4.)
is 2, and the Length Attribute of the symbol BEGIN in
BEGIN L 2,N (from Figure 35 on page 117)
is 4.
2. If a symbol is the name of a DC statement, its Length Attribute is the length of the first
generated constant, ignoring duplication factors. Explicit lengths and Length Attributes may
be assigned with a length modifier; otherwise the Length Attribute is the implied length.
Thus, the three symbols in
Implied DC F'8' (from Figure 51 on page 140)
Explicit DC FL4'8'
Three8s DC 3F'8'
all have Length Attribute 4.
3. If the symbol names a DC statement whose first operand contains multiple values, the sym-
bol's Length Attribute is the length of the first generated constant, as noted for the symbol
Three8s above. Similarly, the Length Attribute of the symbol TABLE in
TABLE DC F'1,2,3,4,5,6,7,8,9,10' (from Figure 52 on page 142)
is 4, even though the statement defines constants occupying 40 bytes.
4. If the symbol names a DC statement with more than one operand, the Length Attribute
assigned to the symbol is determined from the first operand only, according to the previous
rules. Thus,
TwoCons DC F'2',FL2'-2'
would assign 4 as the Length Attribute of TwoCons.
5. A symbol defined in an EQU statement to have the value of a self-defining term is assigned a
Length Attribute of 1. Thus, the symbol ZILCH in
ZILCH Equ 7 (from Example 8_4_2 on page 100 in Section 8.4.)
has Length Attribute 1. (The EQU assembler instruction is described further in Section 13.3
on page 162.)

11.8. Decimal Exponents (*)

Some numeric constants can be simplified by using either a decimal exponent or an exponent
modifier. When you want to generate a constant with several trailing zeros, both forms let you
omit the trailing zeros.

11.8.1. Decimal Exponents

A decimal exponent is written as part of the nominal value of the constant. Following the
numeric portion, write the letter E followed by a signed or unsigned integer. For example:
F100A DC F'1E2' Generates X'00000064'
F100B DC F'1000E-1' Generates X'00000064'
F1000 DC F'1E3' Generates X'000003E8'
FBillion DC F'1E9' Generates X'3B9ACA00'

Chapter IV: Defining Constants and Storage Areas 143

 11.8.2. Exponent Modifiers
An exponent modifier is written following the constant's type, and following any other modifiers.
For example:
F100A DC FE2'1' Generates X'00000064', aligned
F100B DC FE-1'1000' Generates X'00000064', aligned
F100C DC FL4E2'1' Generates X'00000064', unaligned
F1000A DC FE3'1' Generates X'000003E8', aligned
F1000B DC FL3E3'1' Generates X'0003E8', unaligned
FBillion DC FE9'1' Generates X'3B9ACA00', aligned

You can write constants with both an exponent modifier and a decimal exponent in the nominal
value; the power of 10 applied to the numeric portion of the nominal value is the sum of the two.
For example:
F100A DC FE1'1E1' Generates X'00000064'
F100B DC FE-1'1E3' Generates X'00000064'
F1000A DC FE-7'1E10' Generates X'000003E8'
FBillion DC FE5'1E4' Generates X'3B9ACA00'

We'll see more about scale and exponent modifiers in Section 32.3, on page 574.

Exercises
11.8.1.(2) Show the constants generated by these statements, indicating which are aligned by
default and which are not.
(1) DC FE1'2E3'
(2) DC FE-1'5E5'
(3) DC FL2E2'1E2'
(4) DC FL4'8E1'

11.8.2.(1) Rewrite the intended constant in Exercise 11.6.1 on page 142 using (a) a decimal
exponent and (b) an exponent modifier.

11.8.3.(2) + In following program segment, determine the values assigned to the Location
Counter in the last four statements. Then complete the “Object Code” column for the four
statements with spaces provided.
Loc Object Code Statement

000000 Ex11_8_3 START 0

000000 05F0 BALR 15,0
000002 USING *,15
000002 __________ L 2,X
000006 __________ A 2,Y
00000A __________ S 2,Z
00000E __________ ST 2,RESULT
000012 PRINTOUT RESULT,*
000038 DUMMY DC 0CL16'GARBAGE'
______ X DC F'2'
______ Y DC F'15'
______ Z DC F'3'
______ RESULT DC F'0'

144 Assembler Language Programming for IBM System z™ Servers Version 2.00
Terms and Definitions
boundary alignment
The Assembler's action in incrementing the Location Counter so that its value is adjusted to
the boundary required by an instruction or by a constant operand.
constant type
A letter specifying the internal data representation for a generated constant.
decimal exponent
A letter E attached at the end of the digits of a numeric constant, followed by a positive or
negative integer giving the power of ten by which the value of the digits is multiplied.
duplication factor
The number of times a constant operand should be assembled.
exponent modifier
A modifier specifying a positive or negative power of ten to be multiplied by the nominal
value of a constant.
length modifier
A modifier specifying the exact length to be used for a constant, rather than its default length.
modifier
A value following the constant type, specifying other information about the constant's
Length, Scale, and Exponent.
nominal value
The value you write between delimiters or value separators to specify the assembled value of
a constant.

Chapter IV: Defining Constants and Storage Areas 145

12. Basic Constants

11 2222222222
111 222222222222
1111 22 22
11 22
11 22
11 22
11 22
11 22
11 22
11 22
1111111111 222222222222
1111111111 222222222222

We now use the general rules of the previous section to describe seven basic constant types used
in many programs — F, H, A, Y, C, B, and X — and the useful form of constants called “literals”.

12.1. F-Type and H-Type Constants

We saw the F-type constant in earlier examples, so we will just summarize its properties here.
The implied length is four, and the default alignment is to a word boundary. If an explicit length
is specified, no alignment is performed and the length may be between 1 and 8 bytes. The
nominal value of the constant is an optionally signed string of decimal digits. Thus, you can write
DC FL1'-10' Generates X'F6', not aligned
DC FL8'-10' Generates X'FFFFFFFFFFFFFFF6', not aligned

The H-type constant is similar to type F, specifying two's complement binary integer conversion
to a 16-bit integer in two bytes aligned on a halfword boundary. Thus
DC H'-10'
places the constant X'FFF6' on the next available halfword boundary. If an explicit length is
given, there is no difference between constants of types F and H, so that FL3'8' and HL3'8'
produce identical results.

As we saw in Section 11.8, a decimal exponent can be specified in the nominal values in F- and
H-type constants. It is written as the letter E followed by an optionally signed decimal integer, as
in
DC F'-43E+6' −43×10**6, generates X'FD6FDF40'

The decimal exponent specifies the power of ten by which the preceding value is multiplied. You
could define a table of the first six powers of ten with either of the following two statements:

Powers10 DC F'1,10,100,1000,10000,100000'
Powers10 DC F'1E0,1E1,1E2,1E3,1E4,1E5'
Figure 53. F-type constant with decimal exponent

146 Assembler Language Programming for IBM System z™ Servers Version 2.00
 To improve readability, you can insert blanks among the digits of F-type and H-type constants
(remember: not in decimal self-defining terms!):

Powers10 DC F'1, 10, 100, 1 000, 10 000, 100 000'

In practice, decimal exponents are used mainly in floating-point constants, which we'll discuss in
Chapter IX.

You may sometimes want to create unsigned or logical binary integer constants, as described in
Section 2.6 on page 25. You can define such integers by preceding the nominal value of the
constant with the letter “U”, as in these examples:
DC F'U2147483648' X'80000000' +2**31
DC H'U65535' X'FFFF' +2**16−1
DC F'U4294967295' X'FFFFFFFF' +2**32−1
DC H'1,U2' X'00010002' Mixed signed and unsigned
DC H'-1,U32768' X'FFFF8000' Mixed signed and unsigned
No signs are allowed either before or after the “U”.

Exercises
12.1.1.(1) + In Exercise 11.6.1 on page 142, our friend wanted to define a word binary integer
constant with value 10 9. Help him by rewriting the constant with a decimal exponent.

12.1.2.(1) + Suppose you modified your table of powers of 10 to generate the first six negative
powers, as in
Powers10 DC F'1E-0,1E-1,1E-2,1E-3,1E-4,1E-5'
What values will be generated?

12.1.3.(2) Suppose you need a halfword constant with value 1/2, so you write
Half DC H'5E-1'
What do you think will be generated?

12.1.4.(1) What will be generated if you write

DC F'2147483648' ?

12.1.5.(2) What would happen to the Location Counter values in Figure 35 on page 117 if
there were now 24 bytes (instead of 22 bytes) between the ST instruction and the first DC
instruction?

12.1.6.(2) + Show the object code generated for these statements:

DC F'-2147483620'
DC H'-32594'
DC F'+2147483260'

12.2. A-Type Address Constants

The type A address constant, sometimes called an “adcon”, has great power and broad applica-
bility in Assembler Language programs. An address constant is written differently from the other
types we have considered because the nominal value is delimited by parentheses, as in A(10),
rather than by apostrophes. Address constants are particularly useful because the nominal value

Chapter IV: Defining Constants and Storage Areas 147

 within the parentheses may be any expression, either absolute or relocatable.76 Understanding
relocatable address constants involves considering Linker and Program Loader processing, as we
will see in Section 39.

A special case where the nominal value of an A-type constant contains a Location Counter Refer-
ence is described in Section 13.6 on page 169.

A-type and F-type constants have similarities: a length of four bytes and word boundary align-
ment are implied. An explicit length suppresses alignment; thus A(10) and F'10' are equivalent
operands, as are AL4(10) and FL4'10'. The major difference is that you can write expressions as
the nominal value of constants like A(X'00012E') and A(1+C'.'). In some contexts, these may be
much more natural or convenient than the equivalent F-type constants F'302' and F'76'.

A-type address constants are especially useful when we want to define word-aligned constants
with types not ordinarily aligned by the Assembler. For example, if we need a word containing
1-bits in the rightmost 12 positions and zeros elsewhere, we could write
DispMask DC A(X'FFF') X'00000FFF'
If we had written this DC's operand field as XL4'FFF' instead, we can't guarantee it will be word
aligned, even though the same four bytes are generated. Similarly, a word containing the
EBCDIC representation of the letter A could be written
AConst DC A(C'A') X'000000C1'
This is easier to read than F'193', even though the same constant is generated. A constant like
Word DC A(C'WORD') X'E6D6D9C4'
can be used as a word-aligned “character” constant.

Using such expressions can greatly simplify programming tasks. For example, you can define con-
stants using operands such as
Con425 DC A(ABS425)
where the symbol ABS425 may have been defined in an EQU statement (as in Section 7.6 on page
93) to have a known value. We will see that this technique can provide clarity and simplicity in
your programs.

Address constants let you define an area that will contain the actual address of a byte in memory
when the program is executed. For example, suppose we have written a program that requires
the address of the word integer constant with value 8, in Figure 51 on page 140. We can define
the necessary address constant with the statement
Con8Addr DC A(Implied)

Exercises
12.2.1.(2) Show the generated constant for each of these address constants:

1. A(X'213'+C'*'-B'11')
2. A(92*X'F')
3. A(5*C'0'/C' ')

76 The name “address constant” can be somewhat misleading, because the generated data need not be an address!

148 Assembler Language Programming for IBM System z™ Servers Version 2.00
12.3. Y-Type Address Constants
Y-type address constants bear the same relationship to A-type adcons as H-type constants bear to
F-type constants, except that relocatable Y-type adcons are almost never used. The Y-type adcon
has an implied halfword length and alignment, and is identical to the A-type adcon if an explicit
length is specified. For example, the operands H'10' and Y(10) in DC statements define identical
2-byte constants, and the operands YL1(10), AL1(10), HL1'10', and FL1'10' all generate X'0A'.

If we assume that the symbol Implied is relocatable (as in Figure 51 on page 140), then the
statement
BadCon DC Y(Implied)
would fail at linking time, because 3 or more bytes will be required to hold the execution-time
address of Implied.

The main use of Y-type constants is for symbolically-defined constants such as

DC Y(ABS425)
or
DC Y(C'A')
where the equivalent of a halfword integer is desired. Y-type constants are most often used this
way: to create a halfword value depending on an absolute expression.

Other address constant types are V, S, and Q. V-type constants are very similar to A-type con-
stants, and will be treated when we discuss external subroutines in Chapter X. Q-type constants
will be described when we examine external data structures. The S-type constant generates an
addressing halfword that need not be part of an instruction: the value of the operand expression is
resolved into base-displacement form. We'll defer these types to later sections.

Exercises
12.3.1.(1) What hex data will be generated by these constants?
DC Y(C'A')
DC Y(X'F'*C'B')
DC Y(B'101'*729/C'&&')

12.3.2.(3) An S-type address constant is occasionally useful. It has a length of two bytes, which
may be implied or explicit. It is almost always aligned on a halfword boundary. The unusual
property of this constant is that
S(expression) or S(expression(expression))
is resolved into an addressing halfword. For the first (implied address) format, sufficient USING
information must be available to the Assembler so that it can resolve the expression into base-
displacement form.
Assuming that A is a relocatable symbol and that N is an absolute symbol, determine the
validity of each of the following constants:
(1) S(A+N), (2) S(A(N)), (3) S(N(7)), (4) S(7(N)), (5) S(N).
For which of these constants will the result depend (a) on USING information, and (b) on the
values of the symbols?

Chapter IV: Defining Constants and Storage Areas 149

12.4. Constants of Types C, X, and B
Constant types C, X, and B differ in an important way from types F, H, A, and Y: no defaults
are assumed for either length or alignment. For example, the five bytes required to store the con-
stant generated by the statement
DC C'12345'
will be placed by the Assembler at the next available location given by the current value of the
LC. If a particular boundary alignment is desired, we use a DC or DS statement with zero dupli-
cation factor, as we'll see in Section 13.2 on page 160.

We write these three constant types almost the same way we write character, hexadecimal, and
binary self-defining terms, but the limits on length and value are different. Self-defining terms are
restricted to the range between − 231 and + 231 − 1 while much longer constants can be defined
with the DC instruction. 77 For example, you can define constants as shown in Figure 54.

CharCon DC C'This is a long character constant'

Digits DC X'8462AFCB975310'
ManyBits DC B'0010111011100011001111011010001011101001'
Figure 54. Character, hexadecimal, and binary constants

Note that blanks can be used to separate groups of digits in hexadecimal and binary constants
(but not in self-defining terms!) to improve readability. Thus we could write

Digits DC X'84 62AF CB97 5310'

ManyBits DC B'0010 1110 1110 0011 0011 1101 1010 0010 1110 1001'

The data generated for character (type C) constants is converted to 8-bit bytes using the EBCDIC
representation shown in Table 13 on page 87. Blank characters are part of the nominal value, of
course! The special rules concerning the apostrophe and ampersand in character self-defining
terms also apply to character constants: for each ampersand or apostrophe to appear in the gener-
ated constant, a pair of ampersands or apostrophes must appear in the nominal value between the
delimiting apostrophes. For example:
DC C'''' Generates X'7D'
DC C'&&' Generates X'50'
DC C'&&&&&&''' Generates X'5050507D'

In Section 7 we noted that the value of a character self-defining term is determined by right-
adjusting the term in a 32-bit binary field. However, a character constant is generated by starting
at the left end of the character string, and encoding the necessary characters byte by byte. We
sometimes say that each byte of a C-type constant contains a character, but it is more precise to
say that it contains the 8-bit encoding used to represent the character internally.78

Unlike F- and H-type constants, the implied length of C-, X-, or B-type constants is not a fixed
number. Because no length modifier is present, the two constants
Star1 DC C'*' Implied length = 1
and
Star2 DC C'**' Implied length = 2
have implied lengths as shown. The Assembler determines the minimum number of bytes needed
to hold the nominal value of the constant, and assigns that as the implied length of a symbol
naming the constant.

This rule also applies to continued constants. For example, in

77 Remember: decimal self-defining terms are always nonnegative!

78 Character representations have many encodings: some are 8, 16, or 32 bits long, and others vary between 1 and 4
bytes! We'll meet some of them in Section 26.

150 Assembler Language Programming for IBM System z™ Servers Version 2.00
ManyChar DC C'An example of a very long string of characters intende*
d to illustrate the length attribute of a constant that *
extends over many lines.'
the symbol ManyChar has length attribute 134; you certainly don't want to count the characters in
each line manually (and possibly make a mistake). It's much easier to use the Assembler's
Length Attribute, as in L'ManyChar, and know it's correct.

If we write a statement like

CharData DC 0C'Characters'
the zero duplication factor means that no data will be generated. (We'll discuss this in Section
13.2.) However, the symbol CharData will have Length Attribute 10, the length of the nominal
value. This method of assigning a Length Attribute to a symbol without necessarily reserving
space is often useful.

We will see in Section 27 that the Assembler can generate character constants in other representa-
tions such as ASCII and Unicode.

Exercises
12.4.1.(1) + What are the implied lengths of the constants in Figure 54 on page 150?

12.4.2.(2) How many input lines would be needed to write an Assembler Language statement
that defines a B-type constant with an implied length of 100 bytes?

12.4.3.(1) How can you specify multiple values in a single operand of a C-type constant?

12.4.4.(2) A four-byte area of memory contains the digit pattern X'4040405C'. What is repres-
ented by that pattern? (You should be able to describe two different possibilities.)

12.4.5.(2) Suppose you define the constant

DC 4C' '
What is its value if these 4 bytes are thought to represent a binary integer?

12.4.6.(1) + What is generated for these constants?

(1) DC B'11110001'
(2) DC B'000011111'
(3) DC X'0123456'

12.4.7.(2) What constants are generated from these statements:

1. DC C'A''B&&C'
2. DC C'''A&&B''''C'
3. DC C'ABCF'''

12.4.8.(1) + A programmer wanted to generate 16 bytes of EBCDIC characters representing the

16 possible values of a hexadecimal digit, and wrote
EBCHex DC X'F0',X'F1',X'F2',X'F3',X'F4',X'F5',X'F6',X'F7',X'F8',X'*
F9',X'C1',X'C2',X'C3',X'C4',X'C5',X'C6'
Can you save some effort for him, and write this in a simpler way?

12.4.9. What constants are generated by these statements? Explain any differences.

Chapter IV: Defining Constants and Storage Areas 151

 A DC 5X'0'
B DC XL5'0'
C DC 5X'7'
D DC XL5'7'
E DC 5C' '
F DC CL5' '
G DC 5C'*'
H DC CL5'*'

12.4.10. For each of the following sets of statements, the value of the Location Counter is
X'000743' when the Assembler encounters the first statement. Give the value and length attri-
butes of all symbols (but not the generated object code).
(1) A DC AL3(A)
B DC A(8)

(2) C DC C'DS C''&&'''

D DC C'D DC C''DC'''

12.4.11.(1) + The constant

DC CL4'345'
generates which of these constants?

1. X'00000345'
2. X'00000159'
3. X'F3F4F540'
4. X'00F3F4F5'

12.5. Padding and Truncation

The Assembler must decide what to do if
1. a constant is too large to fully occupy the number of bytes allocated for it (whether an
explicit length modifier or the default length is used), so some (possibly significant) bits must
be truncated, or
2. a constant is too small, so the generated value must be padded to fit in the allotted space.

Some examples are given in Table 31, with the generated constants. Most of the padded con-
stants could have been fit into smaller fields, if you needed desperately to save a few bytes.

Truncation Padding
Value too large Assembled Value Value not too large Assembled Value
H'65537' X'0001' (with error!) H'2' X'0002'
FL1'+300' X'2C' (with error!) FL3'-6' X'FFFFFA'
CL3'SMITH' X'E2D4C9' (C'SMI') CL3'S' X'E24040'
XL2'56789' X'6789' X'56789' X'056789'
BL1'100100100' X'24' (B'00100100') B'101' X'05' (B'00000101')
AL2(X'789AB') X'89AB' A(X'789AB') X'000789AB'
YL1(X'124') X'24' Y(X'124') X'0124'
Table 31. Examples of truncated and padded constants

152 Assembler Language Programming for IBM System z™ Servers Version 2.00
 For all of the constants on the left, some part of the value must be truncated to make it fit in the
allotted space, since there is an implied or explicit length in each case. For all these constant
types except C, excess information is dropped at the left end of the constant, and the rightmost
portion is assembled. For character constants, the excess is trimmed off the right end, as in the
CL3'SMITH' example above, generating C'SMI'. Truncated F- and H-type constants are considered
errors by the Assembler.

For the constants on the right side of Table 31 on page 152, more space is allotted either explic-
itly or implicitly than is needed to hold the significant bits of the given constants. For types H
and F, the assembled value is simply the rightmost part of the two's complement representation
in which the sign bit has been extended to the left. In the character constant CL3'S', the single
letter “S” has been padded on the right with two EBCDIC blanks (with representation X'40') to
fill out the constant to the required length of three bytes, generating C'S••'.79

As mentioned in Section 12.4 on page 150, no default length is assumed for constants of types C,
X, and B. In the absence of explicit lengths, the Assembler uses just enough bytes for the con-
stant to ensure that no information is lost, and no more. Thus the lengths of the three constants
in Figure 54 on page 150 are 33, 7, and 5 bytes respectively; no information is lost, and no
padding was required.80

Table 32 summarizes some of the rules for writing operands in DC instructions. A complete set
of rules is given in the High Level Assembler Language Reference. (We'll discuss V-type address
constants in Chapter X.)

Type H F Y A V B C X
Maximum Length 8 8 2 4 4 256 256 256
Implied Length 2 4 2 4 4 * * *
Implied Alignment 2 4 2 4 4 none none none
Value Specified by dec dec absexpr expr symbol bin char hex
Delimiters Used ' ' ' ' ( ) ( ) ( ) ' ' ' ' ' '
Truncation, Padding left left left left left left right left
Multiple Values yes yes yes yes yes yes no yes
Note: * The implied length is the minimum number of bytes required to contain the data.
Table 32. Truncation/padding rules for some D C operands

Section 12.8 on page 157 shows some type extensions that let you write longer constants with
stricter default alignments.

Exercises
12.5.1.(2) + What will the Assembler generate for these two statements? Will the results be dif-
ferent? If so, why?
DC CL2'ABC'
DC AL2(C'ABC')

12.5.2.(2) + Show what will be assembled for each of the following DC statement operands:
(1) F'1000', (2) H'1000', (3) B'1000', (4) XL1'1000', (5) CL1'1000', (6) AL1(1000),
(7) YL3(1000). Describe the boundary alignment of each.

12.5.3.(2) + What will be generated for these constants?

79 Remember that we use the • character to represent a blank space.

80 I trust you completed Exercise 12.4.1 before reading this sentence!

Chapter IV: Defining Constants and Storage Areas 153

 (1) DC B'011110001'
(2) DC B'111100010'
(3) DC X'01234'
(4) DC XL2'012345'

12.5.4.(2) The statement preceding Table 31 on page 152 says that some of the constants can
be fit into smaller fields. Which ones cannot?

12.6. Literals
We often define data meant to be used only as a constant: it should not be modified during
program execution. In the sample program in Figure 35 on page 117, the two quantities in the
words named N and ONE are defined by DC instructions, but we expect the symbol ONE to mean
that the contents of that word retains the value + 1 throughout program execution. 81

Literals are a simple and convenient way to simultaneously define constants and refer to them. A
literal is a special kind of symbol: the contents of the storage area named by the literal is defined
by the “symbol” itself.

A literal is written as an equal sign (=) followed by characters conforming to the rules for a single
operand of a DC instruction. These are examples of literals:
=F'1' =C'LongLiteral' =BL2'111101'
=H'1' =CL7'BLANK&&' =X'765432A'
=A(1) =F'1,2,3,4' =AL3(5,X'D7'/C'.')

Literals may be used in most places where symbols are permitted, with the following exceptions:
1. The Assembler indicates an error if an instruction obviously tries to store into or otherwise
modify a constant defined by a literal: thus,
ST 7,=F'1'
is invalid, even though it's easy to modify “constants” created by the DC assembler instruc-
tion statement without any assembly-time indication. (This error detection at assembly time
is what makes literals “more constant” than the “constants” defined by DC statements.)
2. A literal may not be specified in an address constant, so that A(=F'1') is invalid.
3. Multiple operands may not be specified, but multiple values may; thus
LM 1,2,=F'1,2'
is valid, but both
LM 1,2,=F'1',=F'2'
L 1,=H'1',=H'2'
are not, because a literal must be a single operand.
4. The duplication factor may not be zero.
5. The alignment and length of the data described in the literal are implied by the constant type,
so that this L instruction,
L 2,=X'2B'
that copies 4 bytes from memory to GR2, will copy unpredictable data into the rightmost
three bytes of GR2 because we can't know precisely where the Assembler will place the
literal, and what might be in the three bytes following the single byte X'2B'.

81 You can even write statements like

ONE DC F'137'
but this won't make your program easier to understand; and it's even more misleading if your program stores varying
values into the word area named ONE.

154 Assembler Language Programming for IBM System z™ Servers Version 2.00
 This statement is entirely equivalent to
L 2,X2B
- - -
X2B DC X'2B' (Not aligned!)
- - - Three more (mystery) bytes
except that the symbol X2B is not needed when the literal =X'2B' is used.
6. A reference to a literal is always a relocatable implied address (as defined in Section 9.5 on
page 109).
7. A literal may be indexed in RX-type instructions, so that
L 0,=F'1,2,3,4,5'(9)
is valid, and is exactly equivalent to
L 0,FiveInts(9)
- - -
FiveInts DC F'1,2,3,4,5'
If the value of the index in GR9 is 8, the L instruction will put the integer 3 in GR0.
8. You may refer to a portion of a literal, as in
IC 0,=F'1'+3
but this is considered a very poor programming practice.
9. In most situations, you can use the Assembler's L' Attribute Reference notation in an
address constant to refer to the Length Attribute of a literal. (Note that this does not violate
rule 2 above!)

LitLen DC A(L'=C'This is a message') Generates X'00000011'

which is equivalent to
Message DC C'This is a message' Named character constant
MsgLen DC A(L'Message) Length attribute of 'Message'
Figure 55. Length attribute reference to two constants, one a literal

The “message” character string is 17 bytes long, but we rarely refer to the Length Attribute of
a literal.

We'll make frequent use of symbol length attribute references in Chapters VII and VIII.

After reading this apparently long list of restrictions, you might think that literals are fairly useless.
We will see that they can be extremely helpful in writing clear and readable programs, and that
these restrictions make good sense.

To illustrate a typical use of a literal, you could rewrite the program segment in Figure 35 on
page 117:
BASR 6,0
USING BEGIN,6
BEGIN L 2,N
A 2,=F'1'
ST 2,N
---------
N DC F'8'

Here, you didn't need to define a constant and create a symbol ONE to refer to it.

As literals are encountered in scanning the source program, the Assembler forms a separate
internal table containing the literals, with duplicates eliminated. Eliminating duplicates saves space
and lets you use literals without generating duplicate constants. The constants from the Assem-
bler's literal table are placed into the program at an appropriate location, and the Assembler then

Chapter IV: Defining Constants and Storage Areas 155

 assigns addressing halfwords to instructions that reference the literals, just as it does for references
to symbols.

The area of the program where the Assembler deposits its collection of literal constants into your
program is sometimes called a literal pool.

Though the Assembler eliminates duplicate literals, those containing references to the Location
Counter, as in
L 2,=A(*)
L 3,=A(*)
are not eliminated, because Location Counter values may vary for each occurrence.

For the added ease of referring to constants using literals there is a corresponding loss in your
ability to specify exactly where the constant is located, since this is normally determined by the
Assembler. The LTORG instruction gives you some control.

Exercises
12.6.1.(2) What data is generated by the literal =AL3(5,X'D7'/C'.') ?

12.6.2.(2) What data is generated by the literal =CL7'BLANK&&' ?

12.6.3.(1) + Write and assemble a short program containing the statements

DC 2A(*)
T DC 2A(*-T)
and examine the generated object code; describe the differences.

12.6.4.(2) + In Figure 55 on page 155, the constant named Message is followed by the word-
aligned A-type constant named MsgLen. How many bytes might be skipped before the A-type
constant?

12.7. The LTORG Assembler Instruction

The LTORG assembler instruction statement lets you control the placement of constants gener-
ated by literals. It may have a name-field entry, but no operand field entry. The Assembler aligns
the LC at the next doubleword boundary, 82 defines the name-field symbol (if any), and then
places its collection of literal-defined constants into the program. The order in which they appear
is determined by the Assembler; don't make any assumptions about ordering.

After dumping the contents of its literal table, the Assembler clears the table. Excessive use of
LTORG instructions in a program with many literals might cause duplicate constants to be
defined. For example,
L 0,=F'1'
LTORG
L 1,=F'1'
LTORG
will cause two identical constants to be generated.

The literals in the literal pool are generated in decreasing order of alignment. Thus, a word literal
like =F'4' will be generated ahead of a halfword literal like =H'2'. This rule applies not only to
literals with implied alignment, but to literals whose length is a power of two. Thus, the literal
=X'00000004' will be generated in the same group as =F'4'.

82 Or quadword boundary, if the value of the SECTALGN option specifies an alignment stricter than doubleword. See
the High Level Assembler Programmer's Guide for further information.

156 Assembler Language Programming for IBM System z™ Servers Version 2.00
 This alignment difference can sometimes be surprising. These two constants, though identical, will
be aligned differently:
L 2,=FL4'4' Explicit length 4, word aligned
L 2,FL4Const Explicit length 4, not word aligned
- - -
DS F,X Align LC off a word boundary
FL4Const DC FL4'4' Unaligned constant X'00000004'
Though rarely a problem, it's worth remembering the difference.

In the absence of any LTORG instructions, the Assembler will generate any accumulated literals
at the end of the assembly, so you will need to ensure they are addressable.

We will use literals in many places.

Remember:
A literal is treated by the Assembler as a special symbol with the addi-
tional effect of causing it to reserve a storage area containing the specified
constant.

While the Assembler tries to diagnose instructions appearing to modify a literal, it's easy for your
program to modify them by writing into the area where they're stored. (In fact, a program can
modify almost anything that's not memory-protected!) You should think of literals as “intended”
constants, not as immutable values.

12.8. Type Extensions

As the System z processors have evolved since System/360 was introduced in the mid-1960s,
many enhancements and additions have been made to the instruction set and the data types they
use.

An important enhancement with z/Architecture was the expansion of the 32-bit general registers
to 64 bits, as illustrated in Figure 9 on page 45. To support 64-bit data types, the Assembler
extended several existing data types to provide 64-bit constants. Among these are the F-, A-, V-,
and Q-type constants. This is done by adding a type extension letter following the constant type.

With a “D” type extension, these constants may be up to 8 bytes long, and by default are aligned
on doubleword boundaries. For example:
DC FD'-1' X'FFFFFFFFFFFFFFFF'
DC AD(C'ABC') X'0000000000C1C2C3'
DC FD'U1E15' X'00038D7EA4C68000'

We will see many examples of these doubleword constants when we describe instructions using
the 64-bit general registers.

Other type extensions are used for character constants. Many other character representations are
now widely used, including ASCII and Unicode. Like EBCDIC, ASCII characters (defined with
type extension “A”) are one byte long, while the Unicode characters (with type extension “U”)
generated by HLASM are two bytes long. For example:
DC C'ABC' X'C1C2C3' EBCDIC by default
DC CE'ABC' X'C1C2C3' EBCDIC always
DC CA'ABC' X'414243' ASCII always
DC CU'ABC' X'004100420043' Unicode

Chapter IV: Defining Constants and Storage Areas 157

 The “E” type extension means that the generated constant must use the EBCDIC representation
even if the Assembler's TRANSLATE option 83 requests translation of C-type constants to a dif-
ferent encoding. We'll see more about specialized character sets in Section 27.

Other type extensions are used for floating-point data; we'll learn more about them in Chapter
IX.

Table 33 summarizes some rules for writing operands in DC instructions with operand type
extensions. A complete set of rules is given in the High Level Assembler Language Reference.

Type FD AD VD QD CA CE CU
Maximum length 8 8 8 8 256 256 256
Implied length 8 8 8 8 * * *
Implied alignment 8 8 8 8 none none none
Value specified by dec expr symbol symbol char char char
Delimiters used ' ' ( ) ( ) ( ) ' ' ' ' ' '
Truncation, padding left left left left right right right
Multiple Values yes yes yes yes no no no
Note: * The implied length is the minimum number of bytes required to contain the data.
Table 33. Truncation and padding rules for some D C operands with extended types

Terms and Definitions

address constant
A field into which a value is inserted by the Assembler, the Linker, or the Program Loader.
Typically, an address.
adcon
Abbreviation for “address constant”.
literal
A special symbol with the side effect of defining a constant referenced by that symbol.
literal pool
A set of literal-generated constants grouped together by the Assembler. A program may
contain multiple literal pools.
padding
Adding extra bits or bytes to a constant so that it will fill the space allotted to it.
truncation
Removing bits or bytes from a constant so that it will fit in the space allotted to it.
type extension
A second letter following the constant type, providing additional information about the con-
stant's length or representation.

83 See the High Level Assembler Programmer's Guide for details.

158 Assembler Language Programming for IBM System z™ Servers Version 2.00
13. Data Storage Definition

11 3333333333
111 333333333333
1111 33 33
11 33
11 33
11 3333
11 3333
11 33
11 33
11 33 33
1111111111 333333333333
1111111111 3333333333

In this section we examine methods for defining data areas and data structures that simplify pro-
grams manipulating the data, and describe the useful assembler instruction statements DS, EQU,
and ORG.

13.1. Storage Areas: The DS Assembler Instruction

A storage area is often needed in a program that need not be initialized to contain a value, as
done by the DC instruction. This can be done with the DS (“Define Storage”) assembler instruc-
tion; it is almost identical to the DC instruction, except that no data is generated: space in the
program is allocated, but not initialized. The rules for writing the operand field entry are the same
for DC and DS, except that a nominal value (and its enclosing delimiters) is optional for DS.
Thus the statements
DS F Define word storage
and
DS F'8' Define word storage
both cause the Assembler to reserve a four-byte area on a word boundary, but no constant is
assembled, even though a nominal value is specified in the second statement. Specifying a value
in a DS statement is useful in statements such as
DS C'Message' Define storage for characters
because it will reserve an area whose length is determined from the length of the nominal value (7
bytes, in this case). Large blocks of storage may be reserved:
FW100 DS 100F Define storage for 100 words
This reserves 100 words and assigns the symbol FW100 to the location of the first. The statements
AREA1 DS 80C
AREA2 DS CL80
both define storage areas 80 bytes long, but the Length Attributes of the symbols AREA1 and
AREA2 are 1 and 80 respectively, which may be very useful in a program. The length attribute of
the symbol AREA1 is 1 byte; the length of the area it names is the product of the duplication factor
(80) and the length attribute (1).

In the absence of either a constant or an explicit length for types B, C, and X,

Chapter IV: Defining Constants and Storage Areas 159

 DS B and DS C and DS X
each assigns an implied length of one byte and reserves a single byte.

Exercises
13.1.1.(2) Suppose the value of the Location Counter is X'012345' when the following three
statements are read by the Assembler:
X DS AL(4)
Y DS A(4)
Z DS AL4
What is generated by these statements? What are the value and Length Attributes of the
symbols X, Y, and Z?

13.2. Zero Duplication Factor

A zero duplication factor may be specified for operands of DS and DC instructions. First,
boundary alignment implied by the storage type is performed if necessary. If a name field symbol
is present, the aligned value of the LC is assigned as its value; the symbol's Length Attribute is
determined from the operand. No space is reserved. Thus a DS or DC instruction with a zero
duplication factor can be used to force boundary alignment.

For example, the two sets of statements

WORD DS 0F
DC C'WORD'
and
DS 0F
WORD DC CL4'WORD'
both serve to define a four-byte character constant on a word boundary named by the symbol
WORD which would not in general have been the case if
WORD DC C'WORD'
or
WORD DC CL4'WORD'
had been specified.

If a zero duplication factor is used in a DC instruction, it behaves just as would the corresponding
DS instruction. However, when bytes are skipped to perform alignments required by DS state-
ments, the Assembler does not put zeros into the skipped bytes, while skipped bytes are zeroed
when aligning DC instructions if the preceding statement generated instructions or data.

Because constants with zero duplication factors do not advance the Location Counter (except for
possible boundary alignment), they have many uses. For example, suppose we must define a
storage area to hold a (U.S.) ten-digit telephone number:

PhoneNum DS 0CL10 Define 10-byte area for full number

AreaCode DS CL3 Space for area code
Prefix DS CL3 Space for prefix
Local_No DS CL4 Space for local number
Figure 56. Describing fields of a (U.S.) telephone number

This way we can refer to the entire field using the symbol PhoneNum, or to each component by its
name.

Suppose we are writing a program that scans Assembler Language statements, and we want to
give names to the fields of the statement. We'll assume that
1. name-field symbols begin in column 1,

160 Assembler Language Programming for IBM System z™ Servers Version 2.00
 2. mnemonics start in column 10 and are 5 or fewer characters long,84
3. operands start in column 16 and are less than 20 characters long,
4. remarks lie within columns 36 and 71,
5. column 72 is the continuation column, and
6. columns 73-80 contain sequencing data.
Then, we can name each of the fields of an 80-byte area named Statemnt that contains the state-
ment and assign appropriate Length Attributes, as shown in Figure 57.

Statemnt DS 0CL80 Define 80-column record area

Name DS 0CL8 Define name-field symbol
DS CL9 Reserve space for name-field symbol + blank
Mnemonic DS 0CL5 Define 5-character mnemonic field
Mnemopnd DS 0CL25 Define both mnemonic and operands
DS CL6 Reserve space for mnemonic + blank
Operand DS 0CL19 Define 19-character operand field
DS CL20 Reserve space for operand field + blank
Comment DS CL36 Allocate 36 columns for comments
Continue DS C Define continuation-indicator column
Sequence DS CL8 Define sequencing columns
Figure 57. Describing fields of an Assembler Language statement

• The first DS statement defines Statemnt to be 80 characters long, but reserves no space.
• Similarly, the second DS defines an 8-byte Name field beginning at the same location.
• The third DS then causes the Location Counter to be incremented by 9 bytes, so that the
symbol Mnemonic has a value corresponding to “column 10” of the record.
• Because we might refer to the mnemonic and the operands together, the symbol Mnemopnd has
the same location, but its length of 25 bytes includes both fields.

The rest of the definitions are similar.

We make this (apparently additional) effort because a program containing these declarations can
now refer to the desired fields by name. For example, we can use the symbol Operand instead of
the expression Statemnt+15 to refer to the start of the operand field. While this may not seem an
important difference, consider what modifications would have to be made to the program if the
Mnemonic field is changed to be six characters long: every statement in the program containing a
reference to expressions like Statemnt+15 would have to be found and changed.

By using this technique, only the DS statements need changing before the program is reassem-
bled; the statements referring to the various fields in our Assembler Language “statement” need
not be changed. Another big advantage of this style of definition is that the symbols have useful
Length Attributes; we will see in Chapters VII and VIII how instructions can make good use of
that information.

As another example, suppose we wish to reserve space for three words that are also regarded as a
single group of twelve bytes named FWGroup. We can do this with these statements:

DS 0F Align to word boundary

FWGroup DS 0XL(3*4) Define start of 3-word group
DS 3F Reserve space for the three words
Figure 58. Define a group of words

84 But: many newer mnemonics can be as many as 8 (or more!) characters long, so you may want to adjust your
column positions appropriately. Similarly, the names of some macro instructions we use (like PRINTOUT) are at most 8
characters long.

Chapter IV: Defining Constants and Storage Areas 161

 Exercises
13.2.1.(2) Assemble the statement in Figure 57 on page 161 to verify the locations and lengths
of each field. (Remember to add an END statement.)

13.2.2.(3) + Assume the Assembler's Location Counter is X'345' when it reads each of the fol-
lowing sets of statements. For each symbol, give its value and Length Attribute.

• J DS 3H
K DS 1X
L DS 0F
• P DC C'A''B'
Q DC 2C'ABA'
R DC 2A(C'.')
• T DS XL2'234567'
V DC 4Y(37)
W DC 0F'1,2'

13.2.3.(2) + For each of the following, assume that the Location Counter value is X'345' when
the initial statement is processed by the Assembler. Give the value and Length Attributes of the
symbol A.

1. A DC F'2'
2. DS 0H
DC C'*'
A DC C'Asterisk'
3. DC 0F'1'
A DC 0XL27'0'
4. A DC A(A)
5. DS 19H
A DC X'12345'
6. DC 3CL4'ABCDE'
A DC C'A&&B'
7. DS CL400
A DC F'12,34,56'

13.3. The EQU Assembler Instruction

Two other assembler instruction statements are often useful in defining and describing data areas,
EQU and ORG. When we write
symbol Equ expression
the Assembler assigns the attributes of the expression in the operand field (including value, reloc-
atability, and length) to the symbol in the name field.

The EQU instruction reserves no storage and generates no data or machine language; it only
defines a symbol by assigning it an assembly-time value. EQU is a powerful tool for simplifying
and understanding programs.

Suppose a program needs a storage area of 75 words, and a word integer constant whose value
gives the number of words reserved. The two statements
NItems DC F'75' Number of words
Table DS 75F Table of words

162 Assembler Language Programming for IBM System z™ Servers Version 2.00
 define the necessary items. However, if we decide to change the table size, both statements must
be changed before re-assembling the program. If we had written instead
TblSiz Equ 75 Define table size
NItems DC A(TblSiz) Number of words
Table DS (TblSiz)F Table of words.
then only the EQU statement would have to be modified before re-assembling. If we also want to
refer to the word in the “middle” of the table, we can write
MidTbl Equ Table+(TblSiz/2)*4
where the factor 4 is the length of each table entry. This illustrates using EQU to define a relocat-
able symbol.

A better programming practice is to use the length attribute of Table as in L'Table, instead of 4.
Here is why: Suppose we can save space in the program by defining halfword table entries
instead of words. If we define the symbol Table as
Table DS (TblSiz)H Table of halfwords.
the position of the new table's middle item will still be determined correctly, because the length
attribute of Table is now 2 instead of 4.

You cannot use EQU instructions to assign more than one value to a symbol. 85 For example, the
second statement in this example is invalid:
X Equ 5 Define X
- - -
X Equ 10 Invalid duplicate definition

Exercises
13.3.1.(1) + Why is the Length Attribute of the symbol MidTbl equal to 4?

13.3.2.(2) A programmer wished to conserve space in his program. He needed both a halfword
and a fullword binary constant of value +8. He wrote the statements
FW8 DC F'8'
HW8 Equ FW8+2
and referred to the halfword value with the symbol HW8. Can you think of any circumstances in
which this might be unsafe?

13.3.3.(2) Suppose the definition of the symbol Midtbl had been written in the following forms:
MidTbl Equ Table+TblSiz*4/2
MidTbl Equ Table+4*TblSiz/2
MidTbl Equ Table+TblSiz/2*4
MidTbl Equ Table+(TblSiz/2)*4
Are these equivalent? Why and why not? Why would you choose one in preference to the
others?

13.3.4.(2) Describe the differences among the following statements. (It may help to assemble
them!) (See Exercise 11.7.1 also.)

85 Some very early assemblers let you use multiple EQU statements to change the value assigned to a symbol. For
System z assemblers, the values of ordinary symbols are not changed at assembly time. Symbols whose values may
be re-assigned at assembly time are called variable symbols; they are used in conditional assembly and macros.

Chapter IV: Defining Constants and Storage Areas 163

 A1 Equ 5
A2 DC F'5'
A3 Equ A2
A4 Equ =F'5'
A5 Equ A1

13.3.5.(2) An EQU statement like

NFS Equ 135
is sometimes described by saying (a) it assigns a constant to NFS, (b) it assigns an assembly-time
constant to NFS, or (c) it assigns the name NFS to a constant. Which of these descriptions is
preferable, and why? What would be a better one?

13.3.6.(3) What would you expect to happen when the Assembler encounters the following
three statements?
A Equ B
B Equ C
C Equ A

13.3.7.(2) What would you expect to happen when the Assembler processes each of the fol-
lowing pairs of statements?
ABLE Equ 2
BAKER Equ ABLE+2

BAKER Equ ABLE+2

ABLE Equ 2

13.3.8.(2) + For each of the following two sets of statements, assume that the Location Counter
value is X'01DBC5' when the first statement is encountered. Determine the value, relocatability,
and Length Attributes of all symbols.

1. ST DS 0CL8
W DS 2F
X DS 2F
2. P DS 0F
Q DS 0H
R DC 4X'0'
S Equ *

13.3.9.(5) Suppose the symbols A and B have absolute values, and were defined by complicated
expressions whose values are not immediately evident. Write a set of EQU statements that will
set the value of the symbol MaxOfA_B to the greater of A and B, or to either if they are equal.

13.3.10.(2) Suppose the symbol A has value X'291B' in each of these sequences of statements.
Give the value and Length Attribute of the symbol B.

1. A Equ *
X DS 3H
B DS 0F
2. A Equ *
B DC CL3'Okay'
3. A Equ *
F DC F'11,22'
X DC X'123'
B Equ X-A

164 Assembler Language Programming for IBM System z™ Servers Version 2.00
13.3.11.(3) + In each of the following sets of statements, give the value and Length Attribute of
each symbol, assuming that the Location Counter value is X'12345' when the first statement of
each set is read by the Assembler.

1. A DS F
B DS 2H
C DS 2CL2
2. F DC A(F)
G DC 3AL3(F,G,H)
H DC Y(*-F,275)
3. P DC 2C'3&&'
Q DC 2A(C'3&&')
R DS 3XL3'FEDCBA93'
4. X DC 0FL5'5,10,20'
Y DC FL3'5,10,20'
Z DC 2C'5,10,20'

13.3.12.(3) Assuming the same statements as in the previous exercise, show the hex data values
assembled for the constants having these names: F, G, H, P, Q, and Y.

13.3.13.(2) + In each of the following sets of statements, give the value and Length Attribute of
each symbol, assuming that the Location Counter value is X'01DBC5' when the first statement
of each set is read by the Assembler.

1. STR DS 0CL8
W DS 2F
X DS 2F
2. P DS 0F
Q DS 0H
R DC 4X'40'
S EQU *-P

13.3.14.(3) + For each of the following sequences of statements, assume that the value of the
LC is X'125' when the first statement is encountered. For each sequence, give the value and
Length Attributes of all symbols, the assembled machine language constants (in hex) and their
locations, and the LC value after the last statement in the sequence.
1. A DC F'-17'
B DC H'33'
2. D DC FL4'+17'
C DC H'-33'
3. E DC C'ABCDEFGH'
F DC F'1000'
4. G DS 2H
H DC A(X'129E')
5. J DS 0H
K DS 0X
L DS 0F
M DC 0FL6'15'
N DC F'-1000'
6. P DC 3C'A''B'
Q DC 2A(C'A''B')
7. R DS 100F
S DS 10CL80
8. AB DC F'900',HL5'2147483650',H'1'

Chapter IV: Defining Constants and Storage Areas 165

 9. BC DC 3XL2'7',0CL3'ABCD',B'1'
CD DC H'16383',H'-16383'
10. DE DS 2F,0D,2CL6
EF Equ *,L'DE
11. T DC X'CAB'
V DC 2B'101011100'
W DC (V-T)CL(W-T+2)'CAB'
12. Y DS H
X DC (X-Y)AL(X-Y)(X-Y)
13. Z DC CL2'ZZ'
ZZ DC (ZZ-Z)A(ZZ-Z)

13.3.15.(2) + You are given a number N in the range 0 ≤ N ≤ 14 and you must use it to
assign a pair of symbols REven and ROdd to an even-odd pair of 32-bit general registers, respec-
tively. Write EQU statements to assign the symbols.

13.3.16.(3) In Exercise 13.3.14, some expressions may be difficult for an Assembler to resolve.
Which do you think they are, and why?

13.3.17.(2) + Suppose a symbol A can take values 0 or 1. Write an EQU statement to define a
symbol E whose value is 1 if A is zero, and 0 if A is 1.

13.3.18.(3) + Syppose a symbol A can take any value. Write an EQU statement to define a
symbol E whose value is 0 if A is zero, and 1 if A has any other value.

13.4. EQU Instruction Extended Syntax (*)

HLASM supports an Extended EQU Syntax, allowing you to specify up to five operands.
symbol Equ expression1,expression2,expression3,expression4,keyword

which we understand to mean

symbol Equ value,length,type,program-attribute,assembler-attribute

We have been using only the first operand, expression1. The second and third operands let you
override default values for the length and type attributes.
length (expression2)
Assigns a new Length Attribute to symbol, overriding the Length Attribute assigned from
expression1.
type (expression3)
Assigns a type attribute to symbol. If no type operand is present, the Assembler assigns
type U (“Unknown”)
program-attribute (expression4)
Assigns a programmer-defined “Program Attribute” to symbol.
assembler-attribute (keyword)
A four-character Assembler-defined keyword providing additional information about the
expected behavior of symbol.
The High Level Assembler Language Reference describes the operands in detail. (The last three
operands are used mainly for conditional assembly, so we won't discuss them further here.)

The most common use of the Extended EQU statement is to assign specific Length Attributes to
symbols. For example, you could write
InRec DS XL80
OutRec Equ *,L'InRec Length attribute = 80

166 Assembler Language Programming for IBM System z™ Servers Version 2.00
 that defines the location of OutRec and its Length Attribute. Note that even though the Length
Attribute of the Location Counter Reference * would otherwise default to 1 in an EQU state-
ment.

Exercises
13.4.1.(2) + Assuming that the symbol Result is at location X'2000', give the value and Length
Attributes of each symbol.
Result DS XL133
Pfx Equ Result,24
Prod Equ Pfx+L'Pfx,12
Cost Equ Prod+L'Prod,8
Desc Equ Cost+L'Cost,60
Fill Equ Desc+L'Desc,(L'Result-L'Pfx-L'Prod-L'Cost-L'Desc)
LFill Equ L'Fill

13.5. The ORG Assembler Instruction

The ORG instruction lets you modify the Location Counter. Like EQU, it generates no
instructions or data. The statement
ORG expression
sets the LC to the value of the expression in the operand field of the statement. The relocatability
attribute of the expression must match that of the LC.

We can use the ORG statement to rewrite the data area described in Figure 57 on page 161, as in
Figure 59. Note that none of the DS statements uses a zero duplication factor.

Statemnt DS CL80 Define 80-column record area

ORG Statemnt Reset to start
Name DS CL8 Define name-field symbol
ORG Name+9 Move to 'column 10'
Mnemonic DS CL5 Define 5-character mnemonic field
ORG Mnemonic Back up the LC
Mnemopnd DS CL25 Define both mnemonic and operands
ORG Mnemonic+6 Move back to 'column 16'
Operand DS CL19 Define 19-character operand field
ORG Statemnt+35 Move forward to 'column 36'
Comment DS CL36 Allocate 36 columns for comments
Continue DS C Define continuation column
Sequence DS CL8 Define sequencing columns
Figure 59. Describing fields of an Assembler Language statement using O R G instructions

After these statements have been processed, the LC will have the value of the expression
Statemnt+80, and we can continue assembling as though the LC had never been adjusted by the
ORG statements.

Now, suppose we want to check for possible comment statements by defining Column1 as a new
field, so we add the statements
ORG Statemnt Back to 'column 1'
Column1 DS CL1 To check for asterisks
at the end of Figure 59. Any statements following the last statement in the figure would begin
assembling at Statemnt+1, which is undoubtedly not what you intended.

To rectify such a mistake, you can do either of two things. First, you could place the statement
ORG Statemnt+80 Move LC to end of Statement field

Chapter IV: Defining Constants and Storage Areas 167

 after all the other statements. A second way is to write
ORG , Set LC to its highest value
The Assembler interprets the missing, or null, operand (indicated by the comma) to mean that the
LC should be set to the highest value it has attained so far in the assembly.

This example assumes that Statemnt+80 is the highest location at this point in the assembly; if
not, other instructions and data might be assembled in the wrong places. This possible error is
one reason why the technique shown in Figure 57 on page 161 is generally preferred.

The ORG instruction also supports an extended form:

ORG expression,boundary,offset
The Assembler first sets the LC to the location given by “expression”, then rounds it up to the
next higher “boundary” (it must be a power of two between 2 and 4096), and then adds the value
of “offset” to determine the final LC setting. For example, suppose the current value of the LC is
X'12345'. If we write
ORG *+4,8,-3
the Assembler first adjusts the LC to X'12349', then rounds it up to the next doubleword
boundary X'12350', and finally subtracts 3, setting the LC value to X'1234D'.

In practice, ORG statements are used infrequently. Their usual applications are to construct data
areas that share storage or “overlay” one another, as in Figure 59 on page 167.86

Exercises
13.5.1.(2) The programmer mentioned in Exercise 13.3.2 wanted to be as cautious as possible,
and changed his constant definitions to
FW8 DC F'8'
ORG FW8+2
HW8 DS H
Is this better than the technique used in Exercise 13.3.2? Why or why not?

13.5.2.(2) A programmer didn't know about using a null operand in an ORG statement to reset
the LC to its highest value. In trying to do this, he observed that * represents the value of the
LC, and therefore wrote
Here Equ *
ORG AnyWhere Assemble somewhere elsewhere
- - -
* Equ Here Set LC back to 'Here'
What is wrong with this technique? Solve his problem without using an ORG statement with a
null operand.

13.5.3.(3) + In each of the three following code segments, the symbol A has value X'982E'.
Determine the value and Length Attributes of the symbol B.
A DS 29H
B Equ A+L'A
A DS 7CL5
ORG A+10
B DS 2D

86 In higher-level languages, the overlaying of one data definition on another is sometimes called a “union” or a
“redefinition”.

168 Assembler Language Programming for IBM System z™ Servers Version 2.00
 A DC 0CL40'*'
DS 5CL8,3CL3
B DS 3F

13.5.4.(3) With the same assumptions as in Exercise 13.5.3, determine the value, length, and
relocatability attributes of the symbol B.
A DC FL7'8'
ORG A+2
DC HL7'8'
ORG
B DC HL5'-8'
A Equ *
ORG A+4*L'A
DS (C'*')CL(C'*')'*'
B Equ *

13.5.5.(3) Using suitable DC and ORG statements, find a way to cause the Assembler to assign
the location of some skipped bytes as the value of a symbol SKIP3. For example, three bytes
are skipped in
DC F'1',X'2',F'3'

13.5.6.(2) Suppose a programmer wrote the statement

ORG Set LC to its highest value
without a comma to separate the operation and comment fields. What do you expect will
happen? Why?

13.5.7.(3) In the instruction sequences illustrated in Figure 57 on page 161 and Figure 59 on
page 167, suppose you placed the statement
StmtLen Equ *-Statemnt
following the last statement (with name-field symbol Sequence). What value is assigned to the
symbol StmtLen? What value should be assigned to StmtLen?
A bonus question: how could you induce the Assembler to detect the difference between the
actual and desired values assigned to StmtLen?

13.6. Parameterization
We have seen how we use EQU statements to define quantities such as table sizes, string lengths,
and duplication factors; these quantities are assembly-time constants, so they are not part of the
data whose values may be changed at execution time. The following examples illustrate this.
1. EQU is often used to set a value for defining several storage areas. For example, if you need
to process multiple records having the same length, you could define
RecLen Equ 80 Define record length
InRec DS CL(RecLen) Space for input record
- - -
OutRec DS CL(RecLen) Space for output record
- - -
WorkRec DS CL(RecLen) Space for record work area
Then, if the length of the record areas must be changed, you need to modify only the EQU
statement and reassemble the program.
2. Suppose a table of five words is stored starting at FTable, and we need to copy the last word
of the table into general register 5. We could do this by writing
L 5,FTable+16 Get last word of FTable

Chapter IV: Defining Constants and Storage Areas 169

 but we have mixed the data definition (the fact that the word at FTable+16 is indeed the last
in the table!) with the processing of the data by the L instruction. The “+16” term is a
hidden data description.
This program fragment will be easier to understand and modify if we write something like the
following:
NWords Equ 5 Number of words in Table
L 5,LastWord Get last word of Table
- - -
FTable DS (NWords)F Define name and space for Table
LastWord Equ FTable+(NWords-1)*4 Define last word
We can now change the length of the table by modifying the EQU statement, without
changing the instructions that reference the data. There was nothing in the expression
FTable+16 clearly relating it to the number of words in the table. Indeed, if the number of
words in the table is less than five, FTable+16 refers to data beyond the end of the table!
3. In Figure 58 on page 161, we might need to change the number of words in the group
named FGroup. By defining a symbol NWords giving the number of words, we can rewrite the
example:
NWords Equ 5 Five-word group this time
DS 0F Align to word
FGroup DS 0XL(4*NWords) Length of group
Words DS (NWords)F Reserve space for Words
4. Suppose we want to define a table containing a number of character strings, all of the same
length. Suppose also that our program processes these strings, without knowing in advance
either how many there will be or how long they will be. Let NST and STL be symbols whose
values specify respectively the number of strings and the length of each. Then we can reserve
storage space for the data with the statement
Strgs DS (NST)CL(STL) NST strings each of length STL
Then, if we need the addresses of the first and last strings in the block of data, we can define
the constants
AFirst DC A(Strgs) Address of first string
ALast DC A(Strgs+STL*(NST-1)) Address of last string
Similarly, if we need halfword integer constants containing the length of each string and the
number of strings, we can define these Y-type address constants:
HWStL DC Y(STL) Length of a string
HWNSt DC Y(NST) Number of character strings
Having written the program to make all its references to the data counts and lengths through
these constants, we can finally assign values to the symbols NST and STL by defining two
EQU statements:
NST Equ 219 Number of data strings
STL Equ 43 Length of a data string

As a final example of symbolically-defined data areas, suppose we have written our own Assem-
bler, and have a routine which prints symbol-table information at the end of an assembly. Each
line to be printed contains (1) a single carriage-control character to control vertical printer
spacing, (2) a symbol up to 8 characters long, (3) a 4-character field for the symbol's length attri-
bute, (4) a 2-character relocatability attribute field, (5) a 4 or 5-character field for the number of
the statement in which the symbol was defined, and (6) the rest of the line contains 4 or
5-character fields giving the numbers of the statements whose operand fields refer to the symbol.
The fields are to be separated by spaces. In addition, we are to write the definition of the print
line so it will work with printers that accept 121 or 133 characters (both are common print-line
lengths).

First, we will define the symbols LineLen to give the line length (121 or 133), and StNoLen to give
the number of characters needed to print a statement number (4 or 5). Then, space is reserved for

170 Assembler Language Programming for IBM System z™ Servers Version 2.00
 the “fixed” parts of the line. Finally, we divide the amount of space remaining in the line by the
width needed for each reference entry, to determine the number of entries that will fit.

LineLen EQU 133 Assume 133-character print line

StNoLen EQU 4 Assume 4-character statement numbers
*
StLine DS 0CL(LineLen) Start of line
StCC DS C Carriage control character
StSymb DS CL8,C Symbol and trailing space
StLenAt DS CL4,C Length attribute and a space
StRA DS CL2,C Relocatability attribute and a space
StDefn DS CL(StNoLen),C Space for defining statement number
* Number of entries that will fit on rest of line
NXrefs EQU ((StLine+LineLen-*)/(StNoLen+1))
* Define space for references on rest of line
StRefs DS (NXrefs)CL(StNoLen+1) That's all
Figure 60. Describing an Assembler symbol cross-reference listing line

The program that uses this print line definition will probably need a constant containing the
number of cross-reference entries in the line, so we should also define a constant like
MaxRefs DS Y(NXrefs) Maximum number of references
to be used while the line is being formatted by the program.

This symbolic technique is important for several reasons.

1. The dependence of individual instructions and constants on the number and length of the
data items is more evident when we examine them.
2. If any change must be made to such EQU-dependent quantities, only one statement — the
defining EQU statement — needs to be changed, and the Assembler will re-calculate all the
other quantities depending on it.
3. Statements using the EQU-defined symbols will appear in the Assembler's symbol cross-
reference listing.

Experience shows that

Programs are simpler when the definition of data objects is cleanly sepa-
rated from the instructions that manipulate those objects.

Exercises
13.6.1.(2) Suppose the example above that defines the group of words named FGroup was
written
NWords Equ 5 Five-word group this time
FGroup DS (NWords-1)F Space for group
LastWord DS F Reserve space for LastWord
Determine if this definition gives the same or different results.

13.7. Constants Depending on the Location Counter

We often define address constants with the name of a data item, particularly when we need to
provide that address to another program, as in
DC A(MyData) Address of “MyData”

While it's rare to need the address of a position in a program, as in

DC A(*) This address

Chapter IV: Defining Constants and Storage Areas 171

 we often need the offset of one part of a program relative to another. For example, sometimes it
is useful to define constants whose values depend on one another in some regular way. For
example, suppose we need a table of 32 bytes containing the binary values 31, 30, 29, ..., 2, 1, 0.
We can define the table with an A-type constant:
DownTbl DC 32AL1(DownTbl+31-*)

When the first byte is to be generated, * has the same value as the symbol DownTbl, so the
expression in the constant has value 31. The Assembler does not generate 32 copies of this con-
stant: when a Location Counter Reference appears in an expression in the nominal value of
A-type and Y-type constants, the expression is re-evaluated before generating each constant.

As each byte is generated, the value of * increases by 1 because the explicit length modifier speci-
fies length 1. Thus the last (32nd) byte will be at DownTbl+31, and the expression will evaluate to
0 as desired.

As another example, suppose we want to build a table of halfword binary integers containing the
squares of the integers from 1 to 40. We can write
Sqrs DC 40Y((*-Sqrs+2)*(*-Sqrs+2)/4)

where the division by 4 is needed because halfword constants are being generated, so each
Location Counter Reference * increases by 2 for each constant generated.

We will find other uses for LC-dependent constants when we discuss data structures in Chapter
XI.

Exercises
13.7.1.(3) The Assembler lets you specify an Exponent Modifier for some types of constant, as
described in Section 11.8. It is written with the letter E and the value of the modifier imme-
diately preceding the delimiter before the nominal value of the constant. It specifies a power of
ten multiplying the nominal value of the constant.
Suppose you want to generate a table of the first ten powers of 10 (starting at 10 0) and you
write the statements
POWERS DS 0F
DC 10FE((*-POWERS)/4)'1'
What do you think will happen? Can the Assembler generate the desired constants? If not,
what would have to be done to make the Assembler do what you want?

13.7.2.(3) + Assume the Assembler's Location Counter is X'12345' when it reads each of the
following sets of statements. For each of the five symbols, give its value and Length Attribute,
and show the generated constants (omitting any initial zero bytes inserted by the Assembler for
alignment).

• A DC C'U&&I'
• B DC A(*)
• DS 0XL7C
C DC H'137'
• D DC (B'10')AL(B'10')(B'10')
• E DC C'A( )',A(C' ')
• F Equ *
DC 2Y(*-F)

13.7.3.(2) Analyze the DC statement named Sqrs above to determine how it correctly generates
a table of squares. Then, write a short program to assemble the statement.

13.7.4.(3) Suppose you want to create a table of 256 bytes in which each byte contains the
number of 1-bits in the number representing the byte's offset from the start of the table. For
example, the byte at offset 19 should contain 3, the number of 1-bits in B'10011'. Consider the
following:

172 Assembler Language Programming for IBM System z™ Servers Version 2.00
 T DC 256AL1(*-T-(*-T)/2-(*-T)/4-(*-T)/8-(*-T)/16-(*-T)/32-(*-X
T)/64-(*-T)/128)
Assemble the statement and verify that it generates the correct values. Then, explain why they
are correct.

13.8. Assembly Time and Execution Time, Revisited (*)

We will soon investigate many System z instructions that manipulate data, so it is worth
reviewing some concepts relating assembly and execution times. Suppose we have an area of a
program
area of program
┌────────────────┐
│ │
└────────────────┘
that will eventually contain some data. At assembly time, we give the area a name,
area of program name of area
┌────────────────┐ ┌───────┐
│ │─────┤ FDATA │
└────────────────┘ └───────┘
and the Assembler assigns a location.
area of program name of area
┌────────────────┐ ┌───────┐
assembly- │ │─────┤ FDATA │
time └────────────────┘ └───────┘
location 
┌───────┐ │
│ 12468 ├───────────┘
└───────┘

We might also specify a bit pattern for the initial contents of the area.
area of program name of area
┌────────────────┐ ┌───────┐
│ │─────┤ FDATA │
assembly- └────────────────┘ └───────┘
time  
location │ │ contents
┌───────┐ │ │ ┌──────────┐
│ 12468 ├───────────┘ └───│ DC F'12' │
└───────┘ └──────────┘

The name of the area has attributes such as value, length, and relocatability, all of which are dis-
tinct from the value we assign to the bit pattern that is the contents of the area.
area of program name of area
┌────────────────┐ ┌───────┐
│ │─────┤ FDATA │
assembly- └────────────────┘ └───────┘
time   
location │ │ contents │ attributes of name
┌───────┐ │ │ ┌──────────┐ │ ┌────────────────────┐
│ 12468 ├───────────┘ └───┤ DC F'12' │ └───┤ length, val, reloc │
└───────┘ └──────────┘ └────────────────────┘

When the program is executed, this assembly-time information is gone. During loading by the
Program Loader, the area of the program is assigned an address in memory. Its contents may
have changed as the program is executed.

Chapter IV: Defining Constants and Storage Areas 173

 execution-
time execution-time
address contents of memory
┌────────┐ ┌─────────────────┐
│ 9470A0 │──────── │ X'4040405C' │
└────────┘ └─────────────────┘

The “value” of the contents of the area now depends on the context in which it is used. The
contents might be treated as instructions, as data of various types, or as commands to be obeyed
by an input-output device. The interpretation of the bit pattern depends only on how those bits
are used, and is not inherent in the bits themselves, nor in any characteristics you assigned to
them at assembly time. In this example, the contents of the area of memory may be validly inter-
preted as (1) an instruction, (2) a word binary integer, (3) a floating-point number, (4) a 9-digit
packed decimal number, (5) a character string, and (6) a four-byte bit pattern, among others!

Ideally, the execution-time interpretation of the bit pattern will be the same as the assembly-time
interpretation. Instructions will be interpreted only as instructions and not as data, character
strings will be used as character strings and not as floating-point numbers, and so on. Assembler
Language programming does not always achieve this ideal in practice; but it also gives you much
more flexibility.87

13.9. Summary Observations

As mentioned in the footnote on page 137, the name of the assembler instruction “Define
Constant” can be misleading, because the generated machine language data may not be constant
during the execution of your program. And even if you intended the data to remain constant,
your program may accidentally change its value. (Review the example in Figure 42 on page 122!)

In fact, you can define a “constant” that is actually a machine instruction. For example, if the
data generated by the statement
DC X'1A22'
is executed as an instruction, it will add the contents of GR2 to itself.

Another source of confusion may be the fact that you can specify a nominal value in a DS state-
ment, as in
NoData DS C'This won''t generate any machine language data'

There are other contexts where DC statements generate no machine language data, such as
Dummy Control Sections (“DSECTs”) and Common (“COM”) sections that we'll discuss in
Chapter XI.

There are also potentially misleading names for machine instructions. For example the MVC
instruction's name is “Move Characters”, but its operation actually copies bytes that may or not
be character data.

In summary: don't take the names of assembler and machine instructions too literally. Follow the
old advice to “Watch what they do, not what they say”.

Terms and Definitions

EQU Extended Syntax
Additional operands on EQU instructions that provide additional information about the
attributes of the symbol defined by the EQU statement.

87 Some say Assembler Language gives you more “rope you can use to hang yourself”, but that's part of what makes
Assembler Language programming fun.

174 Assembler Language Programming for IBM System z™ Servers Version 2.00
ORG Extended Syntax
Additional operands on ORG statements that allow LC alignment to a specific power-of-two
boundary, and an offset from that position.
parameterization
A valuable technique for adding flexibility and generality to program definitions, typically by
defining assembly-time constants in EQU statements.
zero duplication factor
A duplication factor that causes LC alignment without generating a constant. Skipped bytes
are zeroed for DC instructions if the immediately preceding byte contains object code.

Programming Problems
Problem 13.1.(2) + Write a program to assemble the DC statements in Section 13.7 on page
171, and verify that the expected constants are generated.

Problem 13.2.(1) + Write a program in which you define this set of four four-byte binary inte-
gers:
Ints DC F'-1046306171,-1803381883,-1723823710,1082565781'
Then, define a 16-byte character string named Chars occupying the same storage as the four
integers. Then, display the 16 bytes of the character string as EBCDIC characters.

Chapter IV: Defining Constants and Storage Areas 175

176 Assembler Language Programming for IBM System z™ Servers Version 2.00
Chapter V: Basic Instructions

VV VV
VV VV
VV VV
VV VV
VV VV
VV VV
VV VV
VV VV
VV VV
VV VV
VVVV
VV

The six sections of this chapter treat instructions basic to almost all Assembler Language pro-
grams.
• Section 14 discusses typical instructions that move data between memory and the general regis-
ters, and among the general registers. (We'll explore instructions that use data in the Floating-
Point Registers in Chapter IX.)
• Section 15 describes the important “Branch on Condition” instructions that let you make deci-
sions about alternate execution paths in your program.
• Section 16 introduces the instructions that perform binary addition, subtraction, and compar-
ison using signed and unsigned binary integer operands.
• Section 17 examines instructions that shift binary numbers in the general registers.
• Section 18 continues our investigation of binary arithmetic operations, examining instructions
that multiply and divide numbers in the general registers.
• Section 19 describes instructions performing the logical operations AND, OR, and Exclusive
OR on bits in the general registers.

The instructions in this chapter operate on binary data in the general registers, except those in
Section 15, which do not involve data.

A comment on terminology: we have used terms like “halfword” and “word” (or “fullword”) to
mean data items 2 bytes or 4 bytes long. This has been common usage for many years. However,
the z/Architecture Principles of Operation uses these terms much more precisely: a halfword must
be aligned on a 2-byte boundary, and a word must be aligned on a 4-byte boundary, and similarly
for doublewords and quadwords. Please understand that we may use terms like “word” and
“halfword” inexactly.88 Very few instructions require strict alignment of their operands; we will
point out those instructions that do require operand alignment.

88 Correct alignment is always a recommended practice, so our less-than-precise usage isn't usually harmful.

Chapter V: Basic Instructions 177

14. General Register Data Transmission

11 44
111 444
1111 4444
11 44 44
11 44 44
11 44 44
11 44444444444
11 444444444444
11 44
11 44
1111111111 44
1111111111 44

This section introduces instructions that transmit data among the general registers, and between
the registers and memory. We will see instructions that handle data in the 32-bit portion of a
64-bit register, and in the full length of a 64-bit register. (You will remember from Figure 9 on
page 45 in Section 3.3 that data items in general registers are frequently manipulated in 32-bit or
64-bit lengths.)

The instructions described here transfer data:

• between the rightmost 32 bits of general registers and memory
• among the rightmost 32 bits of general registers89
• between 64-bit general registers and memory
• among the 64-bit general registers.

We'll sample some typical instructions here; there are others we'll see later. The first two groups
of instructions leave the high-order half of a 64-bit register unchanged, as illustrated in Figure 61.

───────────────────────────── 64 bits ─────────────────────────────

─────────── 32 bits ──────────── ─────────── 32 bits ────────────
┌─────────────────────────────────┬─────────────────────────────────┐
│─── untouched by 32─bit ops ─── │ active │
└─────────────────────────────────┴─────────────────────────────────┘
0 31 32 63
Figure 61. 32-bit portion of a 64-bit general register

The high-order half is “invisible” to the first groups of instructions described here. The System z
architects wanted to ensure compatibility with programs that use only 32-bit registers, so that the
presence of the high-order bits of the 64-bit register would have no effect on existing programs.

Note: The terms and notations used for various portions of a general register can sometimes be
confusing. The z/Architecture Principles of Operation uses “High” and “Low” to refer to the

89 We will occasionally use the older term “32-bit general register” to mean “the rightmost 32 bits of a 64-bit general
register.” In System z, all general registers are 64 bits long; before z/Architecture was introduced, general registers
were 32 bits long, so the older terminology is still useful for instructions introduced prior to z/Architecture.

178 Assembler Language Programming for IBM System z™ Servers Version 2.00
 left/top/upper and right/bottom/lower portions respectively; but the letters H and L are also used
in other contexts with (sometimes) different meanings.

We will use “GR R 1” to mean the general register referenced by the “R1” operand of a machine
instruction statement, and “GRn” to mean “general register n”.

The next several sections will describe instructions that affect only the rightmost 32 bits of a
64-bit general register. We'll examine instructions that affect all 64 bits of a register starting in
Section 14.7 on page 189.

14.1. Load and Store Instructions

We first examine instructions that transmit data between general registers and memory. The most
important are L (Load) and ST (Store), shown in Table 34.

Op Mnem Type Instruction Op Mnem Type Instruction

58 L R X Load 50 ST R X Store
Table 34. Load/Store instructions for 32-bit general registers

We saw these two instructions in several earlier examples; the operand's Effective Address should
be divisible by 4, indicating a word operand.90 Neither instruction changes the Condition Code.

As a reminder, an RX-type instruction has the form shown in Table 35.

opcode R1 X2 B2 D2
Table 35. Format of an RX-type instruction

• The Load instruction L copies 4 bytes of data from memory, starting at the Effective Address,
to bits 32-63 of a general register. When executed,
L R1,D2(X2,B2)
places a copy of the word at the Effective Address of the assembler instruction statement's
second operand from memory into GR R 1. The original contents of GR R 1 are lost, and the
word in memory is unchanged. (Remember, “operand” here means both (1) the assembly
time operand field in the assembler instruction statement, and (2) the data referenced at exe-
cution time by the instruction.)
For example, to set the contents of GR9 to zero, we could write
L 9,=F'0'
(this is definitely not the best way to zero a register, as we will see). To set it to the maximum
negative number, we could write
L 9,=F'-2147483648'
• The Store instruction ST copies data from a general register to memory. It is written explicitly
as
ST R1,D2(X2,B2)
When executed, it causes a copy of the contents of bits 32-63 of GR R 1 to replace the word in
memory at the Effective Address of the second operand. The contents of the register are
unchanged, and the original contents of the word area are lost.

90 In the original System/360 systems, correct boundary alignment was required. This requirement was annoying or
inconvenient to many programmers, so IBM introduced the “Byte-Oriented Operand Facility” (or “BOOF”) to relax
the stringent alignment requirement. Correct alignment is still recommended because misaligned operands can some-
times cause programs to run much slower.

Chapter V: Basic Instructions 179

 For example, to put a copy of the contents of the word at A into the word at B, we could write
L 0,A
ST 0,B
and to exchange the contents of the words at A and B, we could write
L 1,B L 0,A L 0,A L 0,A
L 0,A or L 1,B or L 1,B but ST 0,B
ST 0,B ST 0,B ST 1,A not L 0,B
ST 1,A ST 1,A ST 0,B ST 0,A

assuming that GR1 is not being used as the program's base register!

L and ST, like other instructions referencing addresses in memory, are subject to interruptions due
to addressing and memory protection, which provides some control over the areas of memory
accessible to a program.

Exercises
14.1.1.(1) What is the difference at assembly and execution times between
L 5,BBB
BBB EQU 8
and
L 5,BBB
BBB DC F'8' ?

14.2. Multiple Loads and Stores

We sometimes want to transmit groups of 32-bit words between memory and the right halves of
several registers. This can be done with a sequence of L or ST instructions, as in
L 1,A ST 1,B
L 2,A+4 and ST 2,B+4
L 3,A+8 ST 3,B+8

If we use more than a very few registers, this is cumbersome and slow. Instead, we use the LM
(Load Multiple) and STM (Store Multiple) instructions shown in Table 36. Neither instruction
changes the Condition Code.

Op Mnem Type Instruction Op Mnem Type Instruction

98 LM RS Load Multiple 90 STM RS Store Multiple
Table 36. Multiple load/store instructions for 32-bit general registers

Each is RS-type, for which three operands must be specified in the operand field of the assembler
instruction statement, as follows:
LM (or STM) R1,R3,D2(B2) (explicit address)
LM (or STM) R1,R3,S2 (implied address)
The components of the assembled instruction are pictured in Table 37.

opcode R1 R3 B2 D2
Table 37. RS-type instruction format

As usual, the assembler instruction statement's R1 and R 3 operands must be absolute expressions
between 0 and 15. The base and displacement may be given explicitly, or derived by the Assem-
bler from an implied address.

180 Assembler Language Programming for IBM System z™ Servers Version 2.00
Beginning with GR R 1, the CPU stores the contents of registers (for STM) or loads the contents
of registers (for LM) in order of increasing register number into or from successive words in
memory starting at the Effective Address of the second operand, until GR R 3 has been stored or
loaded. If R3 is less than R1, then registers GR R 1 through GR15 will be stored/loaded followed
by registers GR0 through GR R 3. Thus, register 0 may be considered to “follow after” register
15, so that the general registers “wrap around” from highest to lowest numbered.

Thus, STM 15,0,X will store c(GR15) at X and c(GR0) at X+4, and LM 15,0,X will load GR15
from c(X) and GR0 from c(X+4).

For example,
LM 2,6,=5F'0'
will cause the contents of general registers 2, 3, 4, 5, and 6 to be set to zero. Similarly,
STM 0,15,SAVE
will cause the contents of all sixteen registers to be stored beginning at SAVE. The symbol SAVE
could have been defined in a statement such as
SAVE DS 16F
This DS instruction ensures correct boundary alignment for the second operand address of the
STM instruction. If we assume that GR1 contains the address of a list of four words, we can load
them into registers 7 through 10 by executing
LM 7,10,0(1)

Similarly, if we assume that register 13 contains the address of a block of 18 contiguous words,
then
STM 14,12,12(13)
will store registers 14, 15, 0, ..., 12 in successive words, beginning with the fourth word of the
given area. While these last two examples may seem contrived, they illustrate parts of common
conventions for communicating with subprograms.

As a final example of LM and STM, suppose we wish to exchange the contents of GR0 through
GR7, as a group, with the contents of GR8 through GR15. We could write
STM 0,15,SAVE STM 8,7,SAVE
LM 8,7,SAVE or LM 0,15,SAVE
- - - - - -
SAVE DS 16F SAVE DS 16F

This ignores one important detail: one of the general registers must have been specified as a base
register so that the symbol SAVE can be addressed. The STM and LM instructions will work cor-
rectly, because the CPU calculates the Effective Address before the execute phase of the LM
instruction cycle begins. When execution is completed, however, the base register has probably
been changed, so either we must inform the Assembler that the base register is changed (with a
DROP statement, or a new USING statement), or the correct value must somehow be put back
in the original base register.

Exercises
14.2.1.(1) + Describe the differences between these two instructions:
STM 0,0,XXX
ST 0,XXX

14.2.2.(2) In describing the STM instruction, we said that

STM 14,12,12(13)
stores registers 14 through 12 beginning with the fourth word of the save area. Explain why it
isn't the third, as the displacement value 12=3*4 might imply.

Chapter V: Basic Instructions 181

 14.2.3.(1) What is the maximum number of general registers whose contents can be modified by
a single instruction?

14.2.4.(1) Describe the effect of each of the following instructions:

(1) LM 15,15,X
(2) STM 0,0,X
(3) LM 0,0,X

14.2.5.(5) Suppose two symbols have been defined with the statements
A EQU 4
B EQU 9
Then, the instruction STM A,B,X stores registers GR4 through GR9 starting at X, and we can
compute the number of registers stored with the statement
NREGS EQU B-A+1
On the other hand, if we had defined A and B with
A EQU 9
B EQU 4
then the instruction STM A,B,X would store registers GR9 through GR15 and GR0 through
GR4. We can then compute the number of registers stored with the statement
NREGS EQU B-A+17
Thus, the value assigned to NREGS depends on what values are assigned to the symbols A and B.
Write an expression in the operand field of the EQU statement that defines NREGS such that its
value will always tell how many registers were stored by the STM, no matter what values
(between 0 and 15) are assigned to the symbols A and B.

14.3. Halfword Data

Table 38 shows the two instructions described in this section; neither instruction changes the
Condition Code.

Op Mnem Type Instruction Op Mnem Type Instruction

48 LH R X Load Halfword 40 STH R X Store Halfword
Table 38. Halfword load/store instructions for 32-bit general registers

Transmitting halfword data between memory and registers is somewhat more complicated,
because a 16-bit halfword requires only half of a 32-bit general register. This may seem obvious,
but we need to know (1) which half of the register, and (2) what happens to the other half.

The instructions LH (Load Halfword) and STH (Store Halfword) are similar to L and ST; both
are RX-type instructions, and the operand field entry is exactly the same.

STH is simpler: the rightmost 16 bits of GR R 1 replace the halfword in memory at the Effective
Address of the second operand, and GR R 1 remains unchanged. If the 32-bit contents of the
register is an integer too large to be correctly represented as a 16-bit two's complement integer,
the high-order 16 bits are truncated, and significance is lost. No indication is made that the
halfword in memory may not have the desired value!

182 Assembler Language Programming for IBM System z™ Servers Version 2.00
 When LH transmits data from memory to a general register, the CPU assumes you want to
perform arithmetic operations on it, so the result should occupy the entire 32-bit register with the
least significant bit at the right-hand end. To give a correct representation in the 32-bit register,
copies of the sign bit of the 16-bit halfword are sign-extended to the left to occupy the left half of
the first-operand general register.91 This is illustrated in Figure 62.

┌───────────────────┬───────────────────┐
│─ sign─extended ─┼s │ GR R1
└───────────────────┴───────────────────┘
32 48  63
┌─────────┴─────────┐
│s │ Halfword in memory
└───────────────────┘
0 15
Figure 62. Sign extension by L H instruction

For example, the two statements

LH 0,=H'1' (=H'1' = X'0001'), c(GR0) = X'00000001'
and
LH 0,=H'-1' (=H'-1' = X'FFFF'), c(GR0) = X'FFFFFFFF'
set the contents of GR0 to X'00000001' and X'FFFFFFFF', as indicated. So long as the value of a
halfword operand X from memory satisfies
-215 ≤ c(X) < 215
it can be represented correctly in 16 bits, it will be correctly transmitted by LH and STH
instructions. Otherwise, the problems illustrated in the next two examples can occur.

Suppose we execute the instructions in Figure 63. The contents of the registers is given in the
remarks fields of the instruction statements.

L 0,=F'65537' c(GR0)=X'00010001' +65537 = 216+1

STH 0,A c(A) = X'0001' Lost high-order bit!
LH 1,A c(GR1)=X'00000001' Lost significance!
- - -
A DS H
Figure 63. Loss of significant digits using STH/LH

The contents of GR0 and GR1 will be different because the quantity in GR0 stored by the
second instruction is too large.

A more awkward result is illustrated in Figure 64.

L 0,=F'65535' c(GR0)=X'0000FFFF' +65535

STH 0,A c(A) = X'FFFF' No lost bits, but wrong sign
LH 1,A c(GR1)=X'FFFFFFFF' (−1!) Lost significance!
- - -
A DS H
Figure 64. Loss of significant digits using STH/LH

In this case, the result in GR1 has sign and magnitude different from the original operand.

You can see that when you use halfword data, you must be careful to understand what might
happen when storing, loading, or doing (implicitly word) arithmetic with such quantities.

91 We will see many uses of sign extension — copying the sign bit into the higher-order bit positions of a general register
— so it's important to understand its behavior.

Chapter V: Basic Instructions 183

 Exercises
14.3.1.(3) Suppose the STH instruction was modified so that it stored the sign bit and the right-
most 15 bits of the 32-bit R1 register, so the result contains bits 0 and 17-31 of the original
operand. By considering operands like those in Figures 63 and 64, determine whether this form
of the instruction will solve some of the problems in using halfword data we've discussed here.

14.3.2.(2) Suppose GR1 contains X'12345678'. What will be in GR2 after executing these
instructions?
ST 1,A
LH 2,A+2
Now, suppose GR1 contains X'FEDCBA98'; what will be in GR2 after executing the same
instructions?

14.3.3.(2) + Suppose an area of memory contains X'4040405C'. Is it an instruction or data?

Explain.

14.3.4.(1) What similarities can you find among the opcodes assigned to L, LH, and LM com-
pared to those of ST, STH, and STM?

14.3.5.(3) + The inequality following Figure 62 on page 183 says that values ≥ 215 or
< − 215 − 1 can cause problems when used as operands of LH and STH instructions. Write and
execute program segments like that in Figure 63 on page 183 to test this assertion.

14.4. Insert and Store Character

The IC (Insert Character) and STC (Store Character) instructions shown in Table 39 transmit a
single byte between a general register and memory.

Op Mnem Type Instruction Op Mnem Type Instruction

43 IC RS Insert Character 42 STC RS Store Character
Table 39. Character insert/store instructions for 32-bit general registers

The operand field entry is written as for L and ST, but you need not worry about boundary align-
ment for the address of the second operand, since only a single byte of data is being moved.

The instruction
STC R1,D2(X2,B2)
stores the rightmost byte of GR R 1 in memory at the Effective Address of the second operand.
The contents of GR R 1 and the Condition Code are both unaffected.

The reverse operation, IC, is called “Insert Character” rather than “Load Character”, because the
byte from memory is inserted into the rightmost byte of the register without disturbing the other
bytes. No sign extension is done.

Figure 65 on page 185 illustrates the actions of IC and STC.

184 Assembler Language Programming for IBM System z™ Servers Version 2.00
 ┌─────────────────────────────┬─────────┐
│──────── unchanged ──────── │ │ GR R1
└─────────────────────────────┴─────────┘
32 56  63

┌─────────┐
│ │ Byte in memory
└─────────┘
0 7
Figure 65. Action of IC and STC instructions

As an example, the instructions in Figure 66 can be used to copy the two characters in the char-
acter constant at X, and store them in reverse order at Y.

IC 0,X Get 1st byte of constant

STC 0,Y+1 Store at 2nd byte of Y
IC 0,X+1 Get 2nd byte of constant
STC 0,Y Store byte at Y
- - -
X DC C'AB'
Y DS CL2 Becomes C'BA'
Figure 66. Interchanging two bytes with IC and STC

If memory space is at a premium, you can use a single byte to contain a small integer constant. It
can be placed in a register using these instructions:

L 1,=F'0' Clear GR1

IC 1,LitlCon Insert character
- - -
LitlCon DC FL1'53' Explicit length, no alignment
Figure 67. Inserting a small number into a register

but for small constants it is much better to use other available instructions.

Exercises
14.4.1.(3) Write an instruction sequence that will replace the byte at XX with a byte that con-
tains in binary the number of one-bits that were present in the original byte. For example, if
the initial contents of XX was X'48', the final contents should be X'02'. (Hint: define a
carefully-constructed 256-byte constant, and use an indexed IC instruction. Show only enough
of the constant to clarify how you constructed it.)

14.5. ICM and STCM Instructions

ICM and STCM are very flexible RS-type instructions. They are generalizations of the normal
load/store and insert/store character instructions, because you can specify exactly which bytes of a
register participate in the “insert” or “store” operation. Table 40 lists the two instructions:

Op Mnem Type Instruction Op Mnem Type Instruction

BF ICM RS Insert Characters Under BE STCM RS Store Characters Under
Mask Mask
Table 40. Insert/Store characters under mask instructions for 32-bit general registers

The final “M” character on these two mnemonics does not mean “Multiple” as in LM and STM,
but “Mask” instead.

Chapter V: Basic Instructions 185

 The instruction format of ICM and STCM is very similar to that of LM and STM, as shown in
Table 37 on page 180, but the R 3 digit is now interpreted as a mask digit M 3, as illustrated in
Table 41. The M 3 operand is a bit pattern, not a register number.

opcode R1 M3 B2 D2
Table 41. RS-type instruction format for ICM and STCM

The machine instruction statement operand formats for ICM and STCM are like those of LM
and STM:
ICM (or STCM) R1,M3,D2(B2) (explicit address)
ICM (or STCM) R1,M3,S2 (implied address)

The four bits in the mask digit correspond to the four bytes of the rightmost 32 bits of the general
register designated by GR R 1. The leftmost bit of the mask M3 (bit 12 of the instruction) corre-
sponds to the leftmost byte of the 32-bit register, the next bit corresponds to the second byte, and
so forth. If all mask bits are zero, nothing is inserted or stored.

The CPU executes the STCM instruction by first calculating the Effective Address. Then, where
one-bits in the mask appear, the corresponding bytes in GR R 1 are stored into memory in contig-
uous bytes, starting at the Effective Address. Even though separate bytes in GR R 1 may be
stored, they are not separated in memory. STCM does not change the Condition Code, and no
boundary alignment is required for the second operand.

Suppose the four-byte area of memory named AA contains X'01020304', GR12 contains
X'FFD0A061', and we execute this STCM instruction:
STCM 12,B'0101',AA Store bytes 2 and 4 at AA, AA+1
- - -
AA DC X'01020304'

The M 3 mask specifies that the second and fourth bytes of GR12 are to be stored into the first
two bytes starting at AA, so the contents of memory will become X'D0610304'.

STCM can be considered a generalization of the STC, STH, and ST instructions: the three
instructions
STC 12,AA Store rightmost byte at AA
STH 12,BB Store 2 rightmost bytes at BB
ST 12,CC Store all 4 bytes at CC
behave just like these three STCM instructions:
STCM 12,B'0001',AA Store rightmost byte at AA
STCM 12,B'0011',BB Store 2 rightmost bytes at BB
STCM 12,B'1111',CC Store all 4 bytes at CC
except that now the data areas named by the symbols BB and CC are not expected to be halfword
and word aligned, as recommended for STH and ST. A possible disadvantage of STCM is that it
cannot be indexed, since it is not an RX-type instruction.

The ICM instruction performs the inverse operation to STCM, and also does not expect the
second operand to be aligned; however, ICM does set the Condition Code. As above, suppose the
contents of the four bytes in memory in an area named AA contain X'01020304', and GR12 ini-
tially contains X'FFD0A061'. Then if we execute the instruction
ICM 12,B'0101',AA Insert into bytes 2 and 4 of GR12
- - -
AA DC X'01020304'
the contents of GR12 will become X'FF01A002'.

186 Assembler Language Programming for IBM System z™ Servers Version 2.00
 If all the mask bits are zero, or if all the inserted bytes are zero, the CC is set to zero. Otherwise,
the leftmost bit of the first byte inserted anywhere into GR R 1 is inspected: if the leftmost bit is a
one-bit, the CC is set to 1; otherwise the CC is set to 2. The settings are summarized in
Table 42.

CC Meaning
0 M 3 = 0, or all inserted bytes are zero
1 Leftmost bit of first inserted byte = 1
2 Leftmost bit of first inserted byte = 0
Table 42. CC settings after ICM instruction

This method of setting the CC is easier to understand if we consider the case when the mask digit
is all one-bits, meaning that four bytes are brought from memory and placed into GR R 1. If we
execute these three instructions, the CC settings are as indicated.
ICM 1,15,=F'0' CC set to 0, c(GR1) is zero
ICM 2,15,=F'-1' CC set to 1, c(GR2) is negative
ICM 3,15,=F'+1' CC set to 2, c(GR3) is positive

Exercises
14.5.1.(2) Write a sequence of two instructions (using ICM and STCM) that will set the CC to
zero if the middle two bytes of GR1 are zero. For example, if c(GR1) = X'A2000064', the CC
should be set to zero.

14.6. RR-Type Data Transmission Instructions

We now examine RR-type instructions that transmit data among the 32-bit right halves of the
general registers; four of them set CC. The instructions are LR (Load Register), LTR (Load and
Test Register), LCR (Load Complement Register), LNR (Load Negative Register), and LPR
(Load Positive Register). We saw the LR instruction in the machine instruction statement in
Figure 30 on page 78; it is the only one of the five that does not set the CC.

Op Mnem Type Instruction Op Mnem Type Instruction

18 LR RR Load Register 10 LPR R R Load Positive Register
11 LNR RR Load Negative Register 12 LTR R R Load and Test Register
13 LCR RR Load Complement Register
Table 43. Register/register instructions for 32-bit general registers

The operand field entry of the instructions is written

R1,R2
where R 2 need not differ from R1. For example,
LCR 0,0 Complement c(GR0)
forms the two's complement of the contents of GR0 without affecting any other register.

The action of the first five instructions is summarized in Table 44 on page 188, where the arrow
means “replaces” and the vertical bars |...| mean “absolute value”. As noted above, only the
rightmost 32 bits of the registers are involved.

Chapter V: Basic Instructions 187

 Mnemonic Action CC Values
LR c(GR R1) ── c(GR R2) Not changed
LTR c(GR R1) ── c(GR R2) 0,1,2
LCR c(GR R1) ── ─c(GR R2) 0,1,2,3
LPR c(GR R1) ── │c(GR R2)│ 0,2,3
LNR c(GR R1) ── ─│c(GR R2)│ 0,1
Table 44. Action of five RR-type general register instructions

The CC is set to indicate the status of the result in GR R 1, as shown in Table 45.

CC Meaning
0 Result is zero
1 Result is negative
2 Result is positive
3 Result has overflowed
Table 45. Condition Code settings

You can see in Table 44 that the actions of LR and LTR are identical except that LTR sets the
CC. We often test the contents of a register by writing instructions like
LTR 4,4
that has no effect other than setting the CC. We test the CC with the important “Branch on
Condition” instructions we'll see in Section 15.

For LCR, LPR, and LNR, the arithmetic operations use 32-bit two's complement representation.
Overflow can occur during execution of LCR or LPR only if c(GR R 2) is the maximum negative
number − 231. (It may help to review the discussion of overflow in Section 2.8 on page 27.)

If the overflow condition causes a program interruption, the Interruption Code is set to 8, indi-
cating a Fixed-Point Overflow. 92 No overflow can occur executing LNR because all representable
positive values have valid two's complement representations of their negative values.

This example illustrates possible uses of these instructions.

* First, initialize GR2 and GR3

LM 2,3,=F'1,0' c(GR2)=1, c(GR3)=0, CC not set
LR 7,3 c(GR7)=0, CC not set
LTR 2,2 c(GR2)=1, CC=2
LNR 1,3 c(GR1)=0, CC=0
LCR 4,2 c(GR4)=-1, CC=1
LPR 0,4 c(GR0)=+1, CC=2
LNR 5,2 c(GR5)=-1, CC=1
Figure 68. Examples of some RR-type instructions

We saw in Section 14.5 on page 185 that these three ICM instructions set the Condition Code as
indicated in the comment fields:
ICM 1,15,=F'0' CC set to 0, c(GR1) is zero
ICM 2,15,=F'-1' CC set to 1, c(GR2) is negative
ICM 3,15,=F'+1' CC set to 2, c(GR3) is positive

92 This condition is called “fixed-point overflow”, to distinguish it from floating-point and decimal overflow. It is one of
four program interruptions you can allow or disallow by setting bits in the Program Mask sketched in Figure 12 on
page 47. We sometimes say that such disallowed interruption conditions are “masked” or “disabled”, and when
allowed they are “unmasked” or “enabled”. We'll see in Section 16.2.1 how the SPM instruction lets you control
these four program interruptions.

188 Assembler Language Programming for IBM System z™ Servers Version 2.00
 These CC settings are exactly what we would have obtained if we had written the six instructions
L 1,=F'0' CC unchanged
LTR 1,1 CC set to 0, c(GR1) is zero
L 2,=F'-1' CC unchanged
LTR 2,2 CC set to 1, c(GR2) is negative
L 3,=F'+1' CC unchanged
LTR 3,3 CC set to 2, c(GR3) is positive
That is, an ICM instruction whose mask is all one-bits is equivalent to a L instruction followed
by an LTR instruction,.

Unfortunately, this parallel is invalid for the LH instruction, because ICM does not extend the
sign bit to the left to fill the register as does LH. The ICM instruction in
L 1,=F'0' Set GR1 to zero, CC unchanged
ICM 1,B'0011',=H'-1' Sets GR1 to X'0000FFFF', CC = 1
sets the CC to 1 (indicating a one-bit at the left end of the first inserted byte), but the leftmost
two bytes of GR1 are still zero. Conversely, the instruction
LH 1,=H'-1' Set GR1 to X'FFFFFFFF'
does not affect the CC, but GR1 will contain all one-bits.

Exercises
14.6.1.(2) What changes to the Assembler would be needed to let you use a (nonexistent)
“STR” opcode (that is, “Store Register”, in the same sense as “Load Register”)?

14.6.2.(2) For each instruction in Table 43 on page 187, what operands in GR R 2 can result
in the CC being set to 3?

14.7. Load, Store, and Insert for 64-bit General Registers

We'll now look at instructions that manage data using the full 64 bits of a general register. Con-
trast Figure 69 below with the 32-bits-only view in Figure 61 on page 178.

─────────────────────────────────── 64 bits ──────────────────────────────────

┌──────────────────────────────────────────────────────────────────────────────┐
│ │
└──────────────────────────────────────────────────────────────────────────────┘
0 63
Figure 69. 64-bit general register

The instructions are shown in Table 46:

Op Mnem Type Instruction Op Mnem Type Instruction

E304 LG RXY Load E324 STG RXY Store
E315 LGH RXY Load Halfword (64←16)
EB04 LMG RSY Load Multiple EB24 STMG RSY Store Multiple
EB96 LMH RSY Load Multiple High EB26 STMH RSY Store Multiple High
EB80 ICMH RSY Insert Characters Under EB2C STCMH RSY Store Characters Under Mask
Mask (High) (High)
Table 46. Register/storage instructions for 64-bit general registers

Chapter V: Basic Instructions 189

 The letter “G” is used in almost all the instructions involving 64-bit registers. For example, LG
and STG are the 64-bit equivalents of L and ST.93

Here, we introduce two variations on the RX and RS formats. RXY-type instructions behave
just like RX-type instructions, except that they provide a longer, and signed, displacement field, as
shown in Table 47.

opcode R1 X2 B2 DL 2 DH2 opcode

Table 47. RXY-type instruction format

Another instruction type is RSY. Its format and behavior are very similar to RS-type
instructions, and it shares the “long-displacement” format with RXY-type instructions.

opcode R1 R3 B2 DL 2 DH2 opcode

Table 48. RSY-type instruction format.

For now, we'll treat both RXY-type and RSY-type instructions as though they are identical to
RX-type and RS-type instructions, because they do very similar things. Also note that the first
four bytes of RX-type and RS-type instructions have the same format as the first four bytes of
RXY-type and RSY-type instructions, respectively.

We'll investigate the added usefulness of the “long-displacement” instructions and their “DL2”
and “DH 2” fields (and how the Assembler handles them) in Section 20.1 on page 302.

We've seen instructions that manipulate data only in the low-order 32 bits of a general register,
while others deal with all 64 bits. To help us distinguish these two views of a general register, we
introduce another notation, GR G n. Thus, GG R 1 will mean the 64-bit general register refer-
enced by an R1 operand, while GR R 1 will continue to mean the 32-bit general register referenced
by an R 1 operand. Similarly, GGn will mean the specific 64-bit register referenced by GR G n ,
and GRn will mean the specific 32-bit register referenced by GR R n .

The LG, STG, LMG, and STMG instructions do for 64-bit registers exactly the same actions as
their 32-bit equivalents L, ST, LM, and STM.
1. To illustrate STMG, suppose we save 64-bit general registers GG0 through GG3 at Save0123:
STMG 0,3,Save0123 Save 64-bit GG0 through GG3
- - -
Save0123 DS 4D Reserve 4 doublewords
In memory, these would appear like this:
┌───────────────────────────────────────────────────────────┐
Save0123+0 │ c(GG0) │
├───────────────────────────────────────────────────────────┤
Save0123+8 │ c(GG1) │
├───────────────────────────────────────────────────────────┤
Save0123+16│ c(GG2) │
├───────────────────────────────────────────────────────────┤
Save0123+24│ c(GG3) │
└───────────────────────────────────────────────────────────┘

93 In my opinion, “G” was chosen for two reasons. First, it was the least-used letter among the nearly 500 instruction
mnemonics supported by Enterprise System/390 architecture, the predecessor of System z. Second (and anecdotally),
the largest size latte sold at a coffee shop near IBM in Poughkeepsie, New York was called a “Grande”, so it seemed
natural to say the new large registers were similarly “Grande”. Other more descriptive letters like “L” (meaning
“Long”) were already used in many other mnemonics, where “L” can mean “Logical”, or “Long”, or “Low”.

190 Assembler Language Programming for IBM System z™ Servers Version 2.00
 Then, to restore the contents of the registers, we execute
LMG 0,3,Save0123 Restore GG0 through GG3
2. The other two LM/STM instructions in tref refid=s14s8t1. end in “H”, referring to the
32-bit high-order half of a 64-bit general register.94 They do the same actions for the high-
order halves of 64-bit general registers that LM and STM do for the low-order halves. LMH
and STMH might seem unnecessary, since LMG and STMG manage both halves of a 64-bit
register in one operation. The reason they exist is “history”.95
For example, to store and load only the high-order halves of general registers 5 and 6, we can
write
STMH 5,6,High56 Save high-order half of GG5 and GG6
- - -
LMH 5,6,High56 Restore high-order half of GG5 and GG6
- - -
High56 DS 2F Save area for two 32-bit words
3. LGH is the 64-bit equivalent of LH: it sign-extends the 16-bit integer at the Effective Address
in memory to 64 bits, and places the result into GG R 1.

┌──────────────────────────────────────────────────────────┬───────────────────┐
│─────────── sign─extended ──────────────────────────────┼s │ GG R1
└──────────────────────────────────────────────────────────┴───────────────────┘
0 48  63
┌───────────────────┐
Halfword in memory │s │
└───────────────────┘
0 15
Figure 70. Sign extension by L G H instruction

4. The remaining two instructions in Table 46 on page 189 are ICMH and STCMH. They
behave exactly like ICM and STCM, except that the four M 3 mask bits now refer to the four
bytes in the high-order or left half of GG R 1. The Condition Code settings are the same as
in Table 42 on page 187.
To illustrate, suppose you want to swap the first and fourth bytes of GG0 — that is, the
high-order and low-order bytes of the high-order half of the register.

┌───┬───┬───┬───┬───┬───┬───┬───┐
│ 1 │ 2 │ 3 │ 4 │ 5 │ 6 │ 7 │ 8 │ Bytes in GG0
└───┴───┴───┴───┴───┴───┴───┴───┘
 
└─── swap ──┘

These three instructions show one way to do this:

STCMH 0,B'1001',Temp Save bytes 1 and 4 of 64-bit GG0
ICMH 0,B'1000',Temp+1 Insert original byte 4 at left end
ICMH 0,B'0001',Temp Insert original byte 1 into 4th byte
- - -
Temp DS XL2 Two-byte temporary storage

94 The letter “H” is used in mnemonics with many meanings, such as “High”, “Halfword”, etc.
95 Because 64-bit general registers were introduced after many years of program development using only 32-bit general
registers, conventions for saving and restoring the 32-bit registers are embedded in many programs. To minimize the
changes needed, programs can save the low-order register halves using existing conventions, and then save the high-
order halves elsewhere using STMH. The LMD instruction, as we will see, lets you restore both halves of 64-bit
registers from two separate save areas in one operation.

Chapter V: Basic Instructions 191

 Exercises
14.7.1.(1) + There is a LGH instruction, but no STGH instruction. Why not?

14.7.2.(2) Write a sequence of instructions to exchange the high-order and low-order halves of
GG0.

14.8. RRE-Type Data Transmission Instructions for 64-bit General Registers

As the original System/360 architecture evolved, there were not enough one-byte RR-type
opcodes available for new register-to-register instructions, so new two-byte opcodes were assigned
using a new instruction type, RRE. RRE-type instructions are four bytes long (while
“traditional” RR-type instructions are two bytes long). The 8-bit “unused” field in Table 49 is
set to zero by the Assembler.

opcode unused R1 R2
Table 49. RRE-type instruction format

The instructions in Table 50 are RRE-type.

Op Mnem Type Instruction Op Mnem Type Instruction

B904 LGR RRE Load Register (64) B900 L P G R R R E Load Positive Register (64)
B901 LNGR RRE Load Negative Register (64) B902 L T G R R R E Load and Test Register (64)
B903 LCGR RRE Load Complement Register (64)
B927 LHR RRE Load Halfword B907 L G H R R R E Load Halfword (64←16)
Table 50. Register/register instructions for 64-bit general registers

The actions of the instructions in Table 51 are the same as for their 32-bit equivalents in
Table 44 on page 188.

Mnemonic Action CC Values

LGR c(GG R1) ── c(GG R2) Not changed
LTGR c(GG R1) ── c(GG R2) 0,1,2
LCGR c(GG R1) ── ─c(GG R2) 0,1,2,3
LPGR c(GG R1) ── │c(GG R2)│ 0,2,3
LNGR c(GG R1) ── ─│c(GG R2)│ 0,1
Table 51. Action of five RR-type 64-bit general register instructions

The instructions in Figure 68 on page 188 dealt with data in 32-bit registers; their equivalents for
64-bit registers are shown in Figure 71.

* First, initialize GG2 and GG3 (all 64 bits)

LMG 2,3,=FD'1,0' c(GG2)=1, c(GG3)=0, CC not set
LGR 7,3 c(GG7)=0, CC not set
LTGR 2,2 c(GG2)=1, CC=2
LNGR 1,3 c(GG1)=0, CC=0
LCGR 4,2 c(GG4)=-1, CC=1
LPGR 0,4 c(GG0)=+1, CC=2
LNGR 5,2 c(GG5)=-1, CC=1
Figure 71. Examples of some RR-type instructions for 64-bit operands

If we compare Figures 71 and 68, we see that these equivalent instructions behave similarly and
produce identical CC settings.

192 Assembler Language Programming for IBM System z™ Servers Version 2.00
 LHR is similar to LR, and their operand field entries are the same. LHR takes the rightmost 16
bits of the R2 register, extends the sign bit to the left to form a 32-bit result, and places it in the
R 1 register. This is illustrated in Figure 72; note its similarity to Figure 62 on page 183. The R 1
and R 2 registers need not be distinct.

┌───────────────────┬───────────────────┐
│─ sign─extended ─┼s │ GR R1
└───────────────────┴───────────────────┘
32 48  63
┌─────────┴─────────┐
│s │ Rightmost 16 bits of GR R2
└───────────────────┘
0 15
Figure 72. Sign extension by L H R instruction

For example:
L 1,=X'456789AB'
LHR 2,1 c(GR2)='X'FFFF89AB'

We saw in Figure 63 on page 183 that large fullword values can yield incorrect values if truncated
to halfwords. The same problem can occur with LHR:
L 0,=F'65537' c(GR0)=X'00010001'
LHR 1,0 c(GR1)=X'00000001' Lost significance!

LGHR uses the rightmost 16 bits of the second operand register. Sign extension is indicated by
the notation (64←16) in tref refid=s14s8t1.. Figure 70 on page 191 shows its resemblance to
LH seen in Figure 62 on page 183.

Exercises
14.8.1.(2) Can you think of a reason why an LHR instruction would be used with identical
register operands?

14.8.2.(2) + Suppose GR1 contains X'12345678'. What will be in GR2 after executing this
instruction?
LHR 2,1
Now, suppose GR1 contains X'FEDCBA98'; what will be in GR2 after executing the same
instruction?

14.9. The Load and Test Instructions

In Section 14.6 on page 187, we saw two ways to transfer a data item from memory to a general
register and set the CC depending on its sign:
ICM R1,B'1111',dataname
and
L R1,dataname
LTR R1,reg

ICM cannot be indexed nor can it be used for 64-bit operands, because ICM and ICMH set the
CC separately for the low-order and high-order halves of GG R 1, respectively. The L/LTR and
LG/LTGR instruction pairs can be indexed, but two instructions are needed.

To eliminate these inconveniences, System z provides the LT and LTG instructions, as shown in
Table 52 on page 194:

Chapter V: Basic Instructions 193

Op Mnem Type Instruction Op Mnem Type Instruction
E312 LT RXY Load and Test (32) E302 L T G RXY Load and Test (64)
Table 52. Load and Test instructions

Their behavior is identical to the instruction pairs L/LTR and LG/LGTR, respectively.

Exercises
14.9.1.(1) How can the L/LTR and LG/LTGR instruction pairs be “indexed”?

14.9.2.(1) What operand values can cause LT or LTG to set CC=3?

14.10. Mixed 32- and 64-bit Operands

To make it easy to use 32-bit binary operands in 64-bit operations, System z provides a set of
instructions that automatically sign-extend a 32-bit operand to 64 bits. In Table 53, The LGF
instruction is RXY-type and the others are RRE-type. The notation (64←32) indicates the
extension of the 32-bit second operand to a 64-bit first operand.

Op Mnem Type Instruction Op Mnem Type Instruction

E314 LGF RXY Load (64←32) B914 L G F R R R E Load Register (64←32)
B912 L T G F R R R E Load and Test Register B913 L C G F R R R E Load Complement Register
(64←32) (64←32)
B910 L P G F R R R E Load Positive Register B911 L N G F R R R E Load Negative Register
(64←32) (64←32)
Table 53. Register/register instructions for 64-bit general registers

The actions of these instructions are almost the same as their 64-bit equivalents that we saw in
Table 51 on page 192, except that no instruction sets the CC to 3.

Mnemonic Action CC Values

LGF c(GG R1) ── c(Word in memory) Not changed
LGFR c(GG R1) ── c(GR R2) Not changed
LTGFR c(GG R1) ── c(GR R2) 0,1,2
LCGFR c(GG R1) ── ─c(GR R2) 0,1,2
LPGFR c(GG R1) ── │c(GR R2)│ 0,2
LNGFR c(GG R1) ── ─│c(GR R2)│ 0,1
Table 54. Action of 32-bit-to-64-bit general register instructions

In each case, the 32-bit second operand is first sign-extended internally, and then treated as a
64-bit operand. For example, the single instruction
LCGFR 0,1 Sign extend, complement GR1 to GG0
is equivalent to the two instructions
LGFR 0,1 Sign extend GR1 to GG0
LCGR 0,0 Two's complement of GG0

(See Exercise 14.10.2!)

194 Assembler Language Programming for IBM System z™ Servers Version 2.00
 ┌───────────────────────────────────────┬────────────────────────────────────────┐
│──────────── sign─extended ──────────┼s │ GG R1
└───────────────────────────────────────┴────────────────────────────────────────┘
0  63
┌────────────────────────────────────────┐
32─bit second operand │s │ GR R2
└────────────────────────────────────────┘
0 31
Figure 73. Sign extension for instructions with mixed 32- and 64-bit signed operands

The instructions in Table 53 on page 194 all have the letter “F” in their mnemonics, to indicate
that the second operand is a 32-bit, 4-byte “Fullword”. The first operand (designated by R1) is
the 64-bit general register that receives the sign-extended (and possibly complemented) second
operand.

Exercises
14.10.1.(1) Compare the opcodes of the five RRE-type instructions in Table 53 on page 194 to
those in Table 50 on page 192. What similarities and differences do you see?

14.10.2.(2) + What would happen in the (64←32) instructions in Table 53 on page 194 if
complementation is done before sign extension?

14.10.3.(2) + The Condition Code values shown in 51 are not the same as those shown in
Table 54 on page 194. How and why are they different?

14.10.4.(2) Consider the 32-bit maximum negative number X'80000000'. Show the contents of
general register 0 and the CC setting after each of these instruction sequences:
(1) L 0,=X'80000000'
LPR 0,0

(2) L 0,=X'80000000'
LGFR 0,0

(3) L 0,=X'80000000'
LPGFR 0,0

(4) L 0,=X'80000000'
LNGFR 0,0

14.10.5.(2) + Why can none of the instructions in Table 53 on page 194 set the CC to 3?

14.11. Other General Register Load Instructions (*)

The previous sections examined the most frequently used load instructions; System z supports
many others. For example, many programs need to insert a byte into the rightmost 8 bits of a
general register; a common instruction pattern is
L 1,=F'0' Clear GR1 to zero
IC 1,Byte c(GR1) = X'000000xx'
or
SR 1,1 Set c(GR1) to zero (subtract from itself)
IC 1,Byte c(GR1) = X'000000xx'
An extra instruction is needed to set GR1 to zeros before the IC instruction. (The SR instruction
subtracts c(GR1) from itself; we'll review it in more detail in Section 16.2.)

The LLC instruction (“Load Logical Character”) does both operations: the byte is loaded into
the last 8 bits of the GR1 operand, and the rest of GR1 is cleared to zero:

Chapter V: Basic Instructions 195

 LLC 1,Byte c(GR1) = X'000000xx'

Table 55 gives a summary of the instructions we'll review. We'll see that they are arranged in
simple groups with repeating patterns.

Op Mnem Type Instruction Op Mnem Type Instruction

E376 LB RXY Load Byte (32←8) B924 LBR R R E Load Byte (32←8)
E377 LGB RXY Load Byte (64←8) B906 LGBR R R E Load Byte (64←8)
E394 LLC RXY Load Logical Character B994 LLCR R R E Load Logical Character
(32←8) (32←8)
E390 LLGC RXY Load Logical Character B984 L L G C R R R E Load Logical Character
(64←8) (64←8)
E395 LLH RXY Load Logical Halfword B995 L L H R R R E Load Logical Halfword
(32←16) (32←16)
E391 LLGH RXY Load Logical Halfword B985 L L G H R R R E Load Logical Halfword
(64←16) (64←16)
E317 LLGT RXY Load Logical Thirty One Bits B917 L L G T R R R E Load Logical Thirty One
(64←31) Bits (64←31)
E316 LLGF RXY Load Logical (64←32) B916 L L G F R R R E Load Logical (64←32)
Table 55. Other general register load instructions

For example, the four instructions in the first two rows are arithmetic loads: the high-order bit of
the second operand is sign-extended to the length of the first operand (as illustrated in Figure 62
on page 183 and Figure 70 on page 191); the others are logical load instructions that zero-extend
the second operand to the length of the first.

None of the instructions in Table 55 change the Condition Code.

14.11.1. Load Byte Instructions

The LB, LBR, LGB, and LGBR instructions treat the second operand as a signed 8-bit number,
and sign-extend it to the 32- or 64-bit length of the R1 general register operand. For the LGB and
LGBR instructions, this is illustrated in Figure 74.

┌──────────────────────────────────────┬─────────────────────────────┬─────────┐
│──────────────── LGB ────────────────│─────────── LB ─────────────┼s │ GG R1
└──────────────────────────────────────┴─────────────────────────────┴─────────┘
0 (unchanged by LB) 31 32  63
┌─────────┐
Byte in memory or register │s │
└─────────┘
0 7
Figure 74. Sign extension by Load Byte instructions

For the LB and LBR instructions, the R 1 first operand is a 32-bit general register, and the high-
order 32 bits of the 64-bit register are unchanged. For example:
LB 3,=FL1'-7' c(GR3)=X'FFFFFFF9'
LGB 5,=FL1'-7' c(GG5)=X'FFFFFFFF FFFFFFF9'

14.11.2. Load Logical Character Instructions

The second operand of these instructions is called an unsigned “character” to distinguish it from
the (signed) “byte” operand of the Load Byte instructions. Each of LLC, LLCR, LLGC, and
LLGCR does the same as the “Byte” instructions above, except that the rest of the R1 first
operand register is set to zeros. To illustrate LLGC and LLGCR:

196 Assembler Language Programming for IBM System z™ Servers Version 2.00
 ┌──────────────────────────────────────┬─────────────────────────────┬─────────┐
│────── (zeroed by LLGC, LLGCR) ───── ────────── zeros ────────── │ │ GG R1
└──────────────────────────────────────┴─────────────────────────────┴─────────┘
0 (unchanged by LLC, LLCR)  63
┌─────────┐
Character in memory or register │ │
└─────────┘
0 7
Figure 75. Zero extension by Load Logical Character instructions

LLC and LLCR affect only the 32 low-order bits of the 64-bit R1 register; the high-order 32-bits
are unaffected.

These four instructions can eliminate the need to clear a register before inserting a character for
processing.

14.11.3. Load Logical Halfword Instructions

The four instructions LLH, LLHR, LLGH, and LLGHR all load the 16-bit halfword operand
into the low-order 16 bits of the R1 register, and clear the preceding 16 bits of the 32-bit register
(for LLH and LLHR) or the preceding 48 bits of the 64-bit register (for LLGH and LLGHR).

┌──────────────────────────────────────┬───────────────────┬───────────────────┐
│────── (zeroed by LLGH, LLGR) ────── ───── zeros ───── │ │ GG R1
└──────────────────────────────────────┴───────────────────┴───────────────────┘
0 (unchanged by LLH, LLHR)  63
┌───────────────────┐
Halfword in memory or register │ │
└───────────────────┘
0 15
Figure 76. Operation of Load Logical Halfword instructions

These four Load Logical Halfword are closely related to the arithmetic “Load Halfword”
instructions, except that the logical loads fill the rest of the 32- or 64-bit R1 register with zeros,
rather than sign-extending the high-order bit of the loaded halfword.

14.11.4. Load Logical (Word) Instructions

The LLGF and LLGFR instructions load the 32-bit second operand from memory or from
G R R 2 into the low-order 32 bits of the 64-bit GG R 1 register, as illustrated in Figure 77:

┌──────────────────────────────────────┬───────────────────────────────────────┐
│────────────── zeros ─────────────── │ │ GG R1
└──────────────────────────────────────┴───────────────────────────────────────┘
0  63
┌───────────────────────────────────────┐
Word in memory or register │ │
└───────────────────────────────────────┘
0 31
Figure 77. Operation of Load Logical word instructions

In effect, LLGF and LLGFR are like L and LR, followed by setting the high-order half of the
G G R 1 register to zero. The R 1 operand is always a 64-bit register.

14.11.5. Load Logical Thirty One Bit Instructions

The LLGT and LLGTR are unusual: the second operand is 32 bits long, but its high-order bit is
ignored! This is illustrated in Figure 78 on page 198:

Chapter V: Basic Instructions 197

 ┌──────────────────────────────────────┬───────────────────────────────────────┐
│────────────── zeros ─────────────── │0bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb│ GG R1
└──────────────────────────────────────┴───────────────────────────────────────┘
0  63
┌───────────────────────────────────────┐
Word in memory or register │xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb│
└───────────────────────────────────────┘
0 31
Figure 78. Operation of Load Logical Thirty One Bits instructions

The R 1 operand is always a 64-bit register.

Why ignore the high-order bit of the 32-bit second operand? When we discuss “addressing
modes” and instructions that both change and depend on addressing mode in Section 20, we'll see
that the high-order bit of a 32-bit address was often used to indicate which mode was desired; it
can be important to set that bit to zero. 96

Exercises
14.11.1.(1) How would you simulate the action of the Load Logical Character instructions with
other instructions already described?

14.11.2.(1) How would you simulate the action of the Load Logical (Word) instructions with
other instructions already described?

14.12. Misunderstandings to Avoid

Two common errors made by beginning programmers are
1. confusing the LR and L instructions, and
2. trying to use a “Store Register” or “STR” instruction to “store” one register into another.

First: by substituting L for LR, you can occasionally create an error that can't be detected by the
Assembler, and sometimes is difficult to find. For example, suppose you intended to load GR5
from GR8 with a LR instruction. If the symbols R5 and R8 have values 5 and 8, then both
L 5,8 Load GR5 with value 8 (??)
and
L R5,R8 Load GR5 from GR8 (??)
are valid instructions referring to memory at address 8. This is probably not what was intended
for the second instruction, even though it looks like it is “loading” GR5 from GR8. This can be
seen by checking the machine language object code generated for the two instructions:
000000 5850 0008 L 5,8 Load GR5 with value 8 (??)
000004 5850 0008 L R5,R8 Load GR5 from GR8 (??)
Exactly the same instruction will be executed.

Warning
Symbols like R8 — an “R” followed by a number — might not refer to a
register!

96 This unusual behavior is difficult to justify now, but we'll see in Section 37 that there are good reasons to have these
instructions.

198 Assembler Language Programming for IBM System z™ Servers Version 2.00
 To help you remember the difference between related instructions of different types, note that
almost all RR-type instruction mnemonics end in the letter “R”, while the RX-, SI-, and RS-type
instruction mnemonics end in other letters.
Second: there is no “STR” instruction. To “store” data from one general register to another, you
must use a LR-like instruction. (See Exercise 14.6.1.)

14.13. Summary
You can think of load-type instruction statements as moving data from right to left: that is, the
second operand replaces the first operand. For example, consider this assembler instruction state-
ment:
L 0,X c(GR0) ── c(X) Right to left
This way of visualizing actions applies to most instructions. The primary exceptions are the
store-type instructions, where you can visualize data moving from the first operand to the second,
or from left to right in the assembler instruction statement. For example:
ST 0,X c(GR0) ── c(X) Left to right
It also helps to remember how short operands are extended to the length of the target operand.

Operand Extension
When a source operand in a register or in memory is moved to a target
register longer than the operand, the operand is extended to the length of
the target register. Arithmetic loads extend the sign bit, and logical loads
extend with zero bits.

Examples of arithmetic load instructions are LH, LGH, and LGFR; examples of logical load
instructions are LLH, LLGH, and LLGFR.
We've seen a lot of new instructions in this section, and keeping track of them can be difficult.
The following table provides a compact summary to help you understand how they are grouped
and related.

Don't try to memorize!

The System z processors are very complex, and you'll learn the instruc-
tion mnemonics a few at a time. The tables at the end of each section
summarizing the mnemonics and their opcodes are primarily for reference
(and to help you in solving some of the Exercises).

Chapter V: Basic Instructions 199

 Func- Oprnd1 8 bits 32 bits 64 bits
tion Oprnd2 8 bits 8 bits 16 bits 32 bits 8 bits 16 bits 31 bits 32 bits 64 bits
LB LH L LGB LGH LGF LG
Load Arithmetic
LT LMH LTG
(from memory)
LM LMG
LBR LHR LR LGBR LGHR LGFR LGR
LTR LTGFR LTGR
Load Arithmetic
LPR LPGFR LPGR
(from register)
LNR LNGFR LNGR
LCR LCGFR LCGR
Load Logical LLC LLH LLGC LLGH LLGT LLGF
(from memory)
Load Logical LLCR LLHR LLGCR LLGHR LLGTR LLGFR
(from register)
STC STH ST STMH STG
Store STM STCMH STMG
STCM
IC ICM
Insert
ICMH
Table 56. Summary of instructions discussed in this section

We'll use tables like this to summarize other instructions as they are introduced. (This one is
more complex than most!)
In Table 56 you might say that the ICM/ICMH and STCM/STCMH instructions deal with one
byte at a time; but because they might move up to 4 bytes, they are shown in the column with
32-bit second operands.
It is difficult to remember all these mnemonics, but they will become more familiar with regular
use. You might ask why the System z architects didn't choose more descriptive mnemonics like
LoadRegister and InsertCharactersUnderMask. Here are two reasons why not.
1. When you write Assembler Language programs, long mnemonics would require a lot of extra
work that is saved by using short abbreviations.
2. In the early years of System/360, programs were prepared on 80-column punched cards, of
which only 71 columns were available for Assembler Language statements. This meant that
shorter mnemonics provided more space for name-field symbols, operands, and comments.

Instructions Discussed in this Section

The instruction mnemonics and opcodes are shown in the following table:

200 Assembler Language Programming for IBM System z™ Servers Version 2.00
Mnemonic Opcode Mnemonic Opcode Mnemonic Opcode
IC 43 LLC E394 LPGR B900
ICM BF LLCR B994 LPR 10
ICMH EB80 LLGC E390 LR 18
L 58 LLGCR B984 LT E312
LB E376 LLGF E316 LTG E302
LBR B926 LLGFR B916 LTGFR B912
LCGFR B913 LLGH E391 LTGR B902
LCGR B903 LLGHR B985 LTR 12
LCR 13 LLGT E317 ST 50
LG E304 LLGTR B917 STC 42
LGB E377 LLH E395 STCM BC
LGBR B906 LLHR B995 STCMH EB2C
LGF E314 LM 98 STG E324
LGFR B914 LMG EB04 STH 40
LGH E315 LMH EB96 STM 90
LGHR B907 LNGFR B911 STMG EB24
LGR B904 LNGR B901 STMH EB26
LH 48 LNR 11
LHR B927 LPGFR B910

Chapter V: Basic Instructions 201

 The instruction opcodes and mnemonics are shown in the following table:

Opcode Mnemonic Opcode Mnemonic Opcode Mnemonic

10 LPR B907 LGHR E314 LGF
11 LNR B910 LPGFR E315 LGH
12 LTR B911 LNGFR E316 LLGF
13 LCR B912 LTGFR E317 LLGT
18 LR B913 LCGFR E324 STG
40 STH B914 LGFR E376 LB
42 STC B916 LLGFR E377 LGB
43 IC B917 LLGTR E390 LLGC
48 LH B926 LBR E391 LLGH
50 ST B927 LHR E394 LLC
58 L B984 LLGCR E395 LLH
90 STM B985 LLGHR EB04 LMG
98 LM B994 LLCR EB24 STMG
B900 LPGR B995 LLHR EB26 STMH
B901 LNGR BC STCM EB2C STCMH
B902 LTGR BF ICM EB80 ICMH
B903 LCGR E302 LTG EB96 LMH
B904 LGR E304 LG
B906 LGBR E312 LT

We will use tables like these to summarize instruction mnemonics and their operation codes as
they are introduced.

Terms and Definitions

GR R n
A notation referring to the rightmost 32 bits of the general register specified by R n .
GR G n
A notation referring to the full 64 bits of the general register specified by R n .
GRn
A notation referring to the rightmost 32 bits of general register “n”.
GGn
A notation referring to 64-bit general register “n”.
insert
Place one or more bytes into a register without changing other bytes.
load operation
Replace the contents of a register with a copy of data from a memory address or from
another register. Other parts of the register may contain sign-extended bits (for arithmetic
loads), or zero-extended bits (for logical loads). The original contents of the target register
are not preserved.
Mn
The field of a machine instruction designating a mask.

202 Assembler Language Programming for IBM System z™ Servers Version 2.00
Rn
The field of a machine instruction designating the number of a general register.
sign extension
The process of making copies of the sign bit of a shorter operand and extending it to the left,
to the length of a target field.
store operation
Place a copy of part or all of a register's contents into memory.
zero extension
The process of adding zero bits to the left of a shorter operand, to extend it to the length of a
target field.

Chapter V: Basic Instructions 203

15. Testing the Condition Code: Conditional Branching

11 55555555555
111 55555555555
1111 55
11 55
11 555555555
11 55555555555
11 555
11 55
11 55
11 555
1111111111 55555555555
1111111111 555555555

Branch instructions let you choose alternative actions in your program, depending on tests or
computed results whose status was indicated in the Condition Code.

The Condition Code is a two-bit field in the PSW (see Figure 12 on page 47), so its value is 0, 1,
2, or 3. To test the CC value we use a “Branch on Condition” instruction. The most common
are the RX-type instruction BC and the RR-type instruction BCR. The result of testing the value
of the CC determines whether or not the branch condition is met.

We'll start with the basic forms of conditional branch instructions; newer forms are discussed in
Section 22. Other instructions whose actions depend on the value of the Condition Code are
described later.

15.1. The Branch Address

If the condition for branching is not met (we'll see how to determine this in a moment), no action
is taken and execution proceeds normally to the next sequential instruction following the Branch
on Condition instruction.

If the branch condition is met, the branch address is determined:

1. For the BC instruction, the branch address is the Effective Address, determined from the dis-
placement, base, and index fields of the instruction.
2. For the BCR instruction, the branch address is contained in the general register specified by
the R 2 digit of the instruction. However, if the R2 digit is zero, no branch ever occurs: that
is, if R2=0, the branch condition is never met.

To complete execution of a branch instruction, the IA portion of the PSW is replaced by the
branch address. The next instruction to be fetched then comes from the address specified by the
branch address. Branch instructions are also called “transfer” instructions, in the sense that
control is transferred to the instruction at the branch address.

A successful branch instruction alters the normal sequencing of instruction fetching. If the IA is
not changed by the branch instruction, the next instruction fetched follows the branch instruction,
and we say that the branch was “not taken”.

204 Assembler Language Programming for IBM System z™ Servers Version 2.00
15.2. The Branch Mask and Branch Condition
The branch condition is determined by examining a single bit of the third hex digit of the instruc-
tion denoted “R 1” in Table 17 on page 107 and in Table 19 on page 108. For the BCR and BC
instructions this digit does not refer to GR R 1, but is treated as a bit pattern called a mask, M 1,
as we saw in Section 14.5 for the ICM and STCM instructions. The instructions have these
formats:

07 M1 R2
Table 57. BCR instruction

47 M1 X2 B2 D2
Table 58. BC instruction

For both the RR and RX instructions, M 1 is the mask digit. Thus, we could write

BCR 9,4 M1 = B'1001'

and
BC 7,4(8,2) M1 = B'0111'
Figure 79. Examples of conditional branch instructions

where the mask fields are B'1001' and B'0111' respectively.

The CPU matches the value of the CC to one of the mask bits, as shown in Table 59. If a 1-bit
in the mask field position corresponds to the value of the CC, the branch condition is met; if the
CC value matches a 0-bit in the mask, the branch condition is not met and no branch occurs.

Instruc-
CC value Mask bit Mask bit
tion bit
tested position value
position
0 8 0 8
1 9 1 4
2 10 2 2
3 11 3 1
Table 59. Mask bits and corresponding CC values

Thus in Figure 79, the BCR 9,4 instruction would branch if the CC had values of 0 or 3, and the
BC 7,4(8,2) instruction would not branch if the CC had value 0.

Exercises
15.2.1.(2) Show how the value of the CC can be used as a bit index in determining which bit of
the mask digit to test.

15.2.2.(1) + Why does a mask value of 15 imply an unconditional branch?

15.2.3.(1) + What happens when BC 15,0 is executed?

15.2.4.(3) If 0 ≤ n ≤ 15, what will be the result of executing this instruction?

BC n,n(n,n)

15.2.5.(1) + Using the information in Table 59, create a table with four rows of Condition Code
values (0, 1, 2, and 3) and columns of 16 BC mask values that show at each intersection
whether or not a branch will occur. (Feel free to transpose rows and columns if necessary.)

Chapter V: Basic Instructions 205

15.3. Examples of Conditional Branch Instructions
Here are some examples of conditional branching:
1. Branch to XX if the CC is zero.
BC 8,XX M1 = B'1000'
The BC instruction mask field has value B'1000', so the branch condition will be met only if
the CC is zero.
2. Branch to XX if the CC is not 0.
BC 7,XX M1 = B'0111'
The mask has value B'0111', so the branch condition will be met if the CC is 1, 2, or 3.
3. Branch to the instruction whose address is contained in GR14.
BCR 15,14 M1 = B'1111'
or
BC 15,0(0,14) M1 = B'1111'
When all mask bits are one, the CC value must match a one-bit in the mask, so a branch
always occurs: this is called an unconditional branch. We could also have written the BCR
instruction as
BCR X'F',14
or
BCR B'1111',14 M1 is very clear here!
4. Branch to XX if the CC is 1 or 3.
BC 5,XX M1 = B'0101'

15.4. No-Operation Instructions

We noted in example 3 above that a mask of all 1-bits means the branch is unconditional,
because the branch condition is always met. Sometimes it is useful to execute an instruction that
has no effect, so we usually use a conditional branch instruction with a zero mask field. Thus,
BC 0,x
and
BCR 0,any
have no effect, because the branch condition can never be met. They are sometimes called “no-
operation” or “no-op” instructions, and the Assembler provides special “extended mnemonics” for
them. The instructions
NOP S2
and
NOPR R2
are treated by the Assembler as being the same as
BC 0,S2
and
BCR 0,R2
respectively. Only a single operand is specified for each NOP or NOPR instruction, and the
Assembler automatically provides the zero mask digit.

15.4.1. Special No-Operation Instructions (*)

One special type of no-operation instruction has an unusual side-effect. It has the form
BCR 15,0 M1 is B'1111'

206 Assembler Language Programming for IBM System z™ Servers Version 2.00
 Modern processors are highly “pipelined”. That is, the fetch, decode, and execute phases are proc-
essed internally in many smaller steps called “stages”.

Pipelining allows one instruction to begin its execution phase while the next is being decoded, and
the instruction after that is being fetched.97 Occasionally, it may be necessary to prevent this over-
lapped type of execution; this form of BCR instruction blocks execution of the following instruc-
tion until all preceding instructions have completed execution. This is sometimes called
“draining” or “flushing” the pipeline, and it can cause programs to execute more slowly.

BCR operands can be interpreted this way: 98

BCR 0,0 Branch never nowhere
BCR 15,0 Branch always nowhere (pipeline synchronization)
BCR 0,x Branch never somewhere (when x > 0)
BCR x,0 Branch sometimes nowhere (when 0 < x < X'F')
BCR x,y Branch sometimes somewhere (when 0 < x,y < X'F')

Exercises
15.4.1.(2) + In trying to ensure that a BASR instruction was followed immediately by a word
address constant, a programmer wrote the following instructions as part of his program:
DS 0F Align to fullword boundary
NOPR 0 2-byte No-op
BASR 8,11 2-byte BASR instruction
DC A(Anywhere) Properly aligned fullword constant
Explain why this might create an unexpected problem.

15.4.2.(2) What other instructions could be used in place of NOPR and NOP?

15.4.3.(1) Suppose you execute the instruction

BCR 15,0
Will an unconditional branch occur? If so, from what address will the next instruction be
fetched?

15.4.4.(2) Explain the execution-time differences between these two pairs of instructions:
L 1,=F'0' L 0,=F'0'
BCR 15,1 BCR 15,0

15.5. Conditional No-Operation

An important use of “no-operation” instructions is to ensure a desired boundary alignment for a
particular instruction in a stream of other executable instructions. (We have already seen how to
obtain boundary alignments for data.) For example, we may require that an RR-type instruction
such as
BASR 8,11

97 The CPU is designed so that exception conditions at any stage are correctly recognized and handled as though each
instruction is completely processed (or prevented from executing) before the next is fetched. Early pipelined
processors couldn't always do this, and were subject to what were called “imprecise” interruptions. The CPU set the
Instruction Length Code (ILC) to zero, meaning that both it (and you) weren't certain which instruction caused the
interruption.
98 This is not an official description.

Chapter V: Basic Instructions 207

 be followed immediately (with no wasted space) by an aligned word constant such as an address
constant. While it is best not to mix instructions and data this way, there are times where such a
technique is useful.99

Since BASR is an RR-type instruction, we need to ensure that its location lies on a halfword
boundary between two word boundaries. In a small program, it may be easy to determine the
location of the BASR by counting LC values: if the BASR falls on a word boundary, insert a
NOPR 0
instruction just before it. But if the program is large or if changes must be made somewhere pre-
ceding the BASR, it is difficult to know whether the NOPR should be inserted or not.

To do this automatically, the Assembler provides the CNOP (Conditional No-Operation) assem-
bler instruction. If the LC is already on the desired boundary, nothing is inserted. Otherwise,
CNOP inserts as many “NOPR 0” and “NOP 0” instructions as are needed to give the desired
alignment.

The operand field entry of a CNOP instruction is written

CNOP boundary,width
where “boundary” and “width” are absolute expressions. The “boundary” operand may have any
multiple-of-two value between 0 and 14, and its value must be less than the value of “width”,
which is 4, 8, or 16. A name field symbol is allowed, and its Length Attribute is always 1.

The “width” operand specifies the boundary relative to which alignment is performed, and
“boundary” specifies the desired halfword relative to that boundary, as shown in Table 60.100

Instruction Location Counter Alignment

CNOP 0,4 beginning of a word
CNOP 2,4 middle of a word
CNOP 0,8 beginning of a doubleword
CNOP 2,8 second halfword of a doubleword
CNOP 4,8 middle of a doubleword
CNOP 6,8 fourth halfword of a doubleword
CNOP 0,16 beginning of a quadword
CNOP 2,16 second halfword of a quadword
CNOP 4,16 second word of a quadword
CNOP 6,16 fourth halfword of a quadword
CNOP 8,16 second doubleword of a quadword
CNOP 10,16 sixth halfword of a quadword
CNOP 12,16 third word of a quadword
CNOP 14,16 eighth halfword of a quadword
Table 60. CNOP operands

To achieve the alignment desired for the BASR in our example, we would write

99 Modern CPUs maintain high-speed buffers known as “caches”, one for fast access to instructions and another for
fast access to data items. If data items appear in the instruction cache, the CPU must stop pre-processing
instructions, load the data into the data cache (probably displacing useful data already there), and resume processing.
This can cause significantly slower execution, so you should avoid “close” mixing of instructions and data.
100 More precisely,
CNOP boundary,width
causes the Assembler to insert enough “NOPR 0” or “NOP 0” instructions as may be needed to increment the LC (if
necessary) so that the new value of the LC satisfies boundary = LC (modulo width).

208 Assembler Language Programming for IBM System z™ Servers Version 2.00
 CNOP 2,4 Align to middle of a word
BASR 8,11 Two-byte instruction
DC A(AnyWhere) No intervening bytes

Note that we should not write

DS 0H
BASR 8,11
DC A(AnyWhere) No (??) intervening bytes
because alignment to a halfword boundary is automatically performed by the Assembler for
instructions. Thus, the BASR could still fall on a word boundary, and the Assembler would then
zero-fill the two bytes between the BASR and the address constant (because A-type constants
have an implied word alignment). Similarly, we could not write
BASR 8,11
DS 0F
DC A(AnyWhere)
since the BASR could again fall on a word boundary, leaving two bytes between it and the con-
stant that would be skipped by the Assembler. The contents of the two skipped bytes at execution
time are arbitrary, since the Supervisor does not always clear or otherwise initialize the area into
which a program is about to be loaded.

Name field symbols on CNOP instructions are rarely used, because branch-target symbols typi-
cally are given to instructions immediately preceding or following the CNOP. Thus, you could
write a symbol that is the name of “nothing”:
DS 0F Align on word boundary
CNopName CNOP 0,4 Align on word boundary (again?)
CallSub BASR 14,15 Go to a subroutine
- - -

The two symbols CNopName and CallSub will have the same LC value even though CNopName
doesn't name anything different; it will have length attribute 1.

Figure 80 illustrates the alignment action of CNOP.

─┬─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┬─
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │
─┴─────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┴─
│ halfword1 │ halfword2 │ halfword3 │ halfword4 │ halfword5 │ halfword6 │ halfword7 │ halfword8 │
│────────word1────────│────────word2────────│────────word3────────│────────word4────────│
│─────────────────doubleword1─────────────────│─────────────────doubleword2─────────────────│
│──────────────────────────────────────────quadword───────────────────────────────────────────│
0,4 2,4 0,4 2,4 0,4 2,4 0,4 2,4 0,4
0,8 2,8 4,8 6,8 0,8 2,8 4,8 6,8 0,8
0,16 2,16 4,16 6,16 8,16 10,16 12,16 14,16 0,16
Figure 80. CNOP alignments and operands

Exercises
15.5.1.(2) + Suppose the Location Counter value is X'0246' when each of these CNOP
instructions is processed by the Assembler. Determine the value of the LC after each CNOP is
processed.
(1) CNOP 2,4
(2) CNOP 0,4
(3) CNOP 6,8
(4) CNOP 10,16
(5) CNOP 4,16
(6) CNOP 2,8

Chapter V: Basic Instructions 209

 15.5.2.(3) + For each of these sets of statements the value of the Location Counter is X'000743'
when the first statement is read by the Assembler. Give the length and value attributes of all
symbols.

1. A DC AL3(A)
CNOP 2,4
B DC A(B)
2. C DC C'DS C''&&'''
CNOP 0,4
D DC C'D DC D''DC'''
3. CNOP 2,8
E DC 2F'100'
F DC (X'F')X'F'

15.5.3.(1) In Exercise 15.5.2, what machine language data is generated by the statement named
D?

15.5.4.(2) + For each of the following, assume that the Location Counter value is X'345' when
the initial statement is processed by the Assembler. Give the value and length attributes of the
symbol A.

1. CNOP 2,4
A LM 2,6,0(1)
2. CNOP 2,8
A BC 10,Smith

15.5.5.(2) + What will be generated by a CNOP 6,8 statement?

15.6. Extended Mnemonics

Conditional branch instructions are used frequently. It can be difficult to remember the Condi-
tion Code values and mask bit values associated with possible branch conditions, so the Assem-
bler provides extended mnemonics for conditional branch instructions. They let you imply the
value of the mask field M1 of a BC or BCR instruction by using an extended mnemonic. For
example, an unconditional branch to an instruction named XX can be written
B XX
which is easier and clearer than writing
BC 15,XX

Table 61 gives the extended mnemonics associated with the BC and BCR instructions. The
notations “(A)”, “(C)”, and “(T)” refer to the contexts in which each extended mnemonic is most
often used. The “A” mnemonics are typically used after Arithmetic instructions, “C” after Com-
parisons, and “T” after Tests.

Table 61 (Page 1 of 2). Extended branch mnemonics and their branch mask values
RX Mnemonic RR Mnemonic Mask Meaning
B BR 15 Unconditional Branch
BNO BNOR 14 Branch if Not Ones (T)
Branch if No Overflow (A)
BNH BNHR 13 Branch if Not High (C)
BNP BNPR 13 Branch if Not Plus (A)
BNL BNLR 11 Branch if Not Low (C)
BNM BNMR 11 Branch if Not Minus (A)
Branch if Not Mixed (T)

210 Assembler Language Programming for IBM System z™ Servers Version 2.00
 Table 61 (Page 2 of 2). Extended branch mnemonics and their branch mask values
RX Mnemonic RR Mnemonic Mask Meaning
BE BER 8 Branch if Equal (C)
BZ BZR 8 Branch if Zero(s) (A,T)
BNE BNER 7 Branch if Not Equal (C)
BNZ BNZR 7 Branch if Not Zero (A,T)
BL BLR 4 Branch if Low (C)
BM BMR 4 Branch if Minus (A)
Branch if Mixed (T)
BH BHR 2 Branch if High (C)
BP BPR 2 Branch if Plus (A)
BO BOR 1 Branch if Ones (T)
Branch if Overflow (A)
NOP NOPR 0 No Operation

As this table indicates, the RR forms of the extended mnemonics are formed by adding the letter
“R” to the equivalent RX mnemonic.

Each of these instructions needs only a single operand field entry. Because the mask digit is
implied by the extended mnemonic, the operand may take any of the forms allowed for the
second operand of an RX- or RR-type instruction.

For example, we could write example 1 of Section 15.3 on page 206 as

BZ XX

and example 2 could be written

BNZ XX

There is no extended mnemonic corresponding to a mask value of 5, so there is no convenient

way to rewrite example 4.

Exercises
15.6.1.(2) + Programmers sometime write programs that contain instruction sequences like this:
Loop - - - Do something in the loop
- - - Now make a test, set the CC
BNZ Finish Exit the loop if something's nonzero
B Loop Otherwise repeat the loop
Finish - - - Rest of program
Why is this wasteful? How can it be made shorter, simpler, and (very probably) faster?

15.6.2.(1) Sometimes the conditional branch instructions are described as follows: “The opera-
tion code for an unconditional branch is X'47F', for a branch-on-zero is X'478', etc.” Is this an
accurate description?

15.6.3.(2) The word at VAL contains a 32-bit binary integer. Write an instruction sequence that
will branch to POS if c(VAL) is greater than zero, to NEG if c(VAL) is less than zero, and to
ZERO if c(VAL) is zero.

15.6.4.(2) A programmer accidentally wrote the operand of a branch instruction so that the
branch target was a constant containing a string of space characters:

Chapter V: Basic Instructions 211

 B Target He meant to go elsewhere...
- - -
Target DC CL132' ' 132 bytes containing X'40'
What would you expect to happen?

15.7. A Comment on Programming Style

For short instruction sequences, it is sometimes tempting to avoid the effort of writing the name
of a target symbol. For example, sometimes a programmer may write
LTR 0,0 LTR 0,0
BZ *+6 instead of BZ Next
LR 0,5 LR 0,5
- - - Next - - -
The operand *+6 means the programmer knows that the lengths of BZ and LR are 4 and 2 bytes
respectively, and this has saved him the “task” of writing the symbol Next in two places.
However: suppose the logic of these statements needs to be updated, and extra instructions must
be added following the BZ instruction. If the operand of BZ (which was not the cause of the
change) isn't updated, it will branch into the added instructions and not to the intended target.101

A Programming Practice to Avoid

Do NOT write operands of branch instructions using the Location
Counter value *± number.

Exercises
15.7.1.(2) + A programmer wanted to be sure that the target of his branch instruction was at the
correct location, so he wrote
BZ *+18 Branch to known target location
- - - More instructions
*+18 EQU * Define the target location.
Can he now be sure his BZ instruction will branch to the intended target?

15.8. A Design Oversight and a Modern “Correction” (*)

Due to a peculiarity in the original design of System/360 and System/370, invalid branch addresses
were not detected during the execute phase of the instruction cycle at the time the CPU finds the
branch condition is met. (Odd addresses produce specification errors, and excessively large
addresses can produce addressing exceptions.) The error is found only when the bad address is
presented, as the IA portion of the PSW, at the next instruction's fetch cycle. The error is duly
detected and an interruption results, but the IA then contains the invalid address rather than the
address of the instruction that attempted the improper branch. This means that looking at the
“Old” PSW can't tell you where the error was caused, so such errors in a program are often very
difficult to correct. You must specify branch addresses accurately to avoid this particular error.
The “Breaking Event Address Register” (sometimes called the “BEAR”) was added to
z/Architecture. Whenever an instruction causes a break in normal sequential execution (such as a
successful branch), the address of the instruction causing the “break” or discontinuity is placed in
the BEAR. If the “break” causes a program interruption, the contents of the BEAR are stored in
a fixed address where error detection and diagnosis routines can use the break address to help you
find the instruction that caused the interruption.
Unfortunately, although the BEAR is accessible to ordinary problem-state programs, its contents
aren't of much use unless its contents are captured at the moment an interruption occurs. So, to

101 A clever programmer knew instruction lengths so well that he avoided writing name-field symbols on statements by
coding instructions like B *+24 and BNZ *-20. Fixing errors in his code was very tedious.

212 Assembler Language Programming for IBM System z™ Servers Version 2.00
 answer questions like “How did my program start executing instructions here?”, we must depend
on the operating system's Supervisor to save the BEAR's contents so the information can be used
for problem diagnosis.

Exercises
15.8.1.(1) + Explain why an odd branch address is invalid.

15.9. Summary
This section described the BC and BCR instructions and their forms as extended mnemonics.
There are many other types of branch instructions, but their most important features are based on
the concepts we've seen here; the others can be thought of as “variations” on the theme of this
section. Newer forms of conditional branch instructions will be described in Section 22.1.

Exercises
15.9.1.(1) How could you design a CPU without a Condition Code or similar indicators?

15.9.2.(1) + Can an instruction generate multiple CC values in a single execution?

Instructions Discussed in this Section

The instruction mnemonics and opcodes are shown in the following table:

Mnemonic Opcode Mnemonic Opcode

BC 47 BCR 07

The instruction opcodes and mnemonics are shown in the following table:

Opcode Mnemonic Opcode Mnemonic

07 BCR 47 BC

Terms and Definitions

branch address
The address from which the next instruction will be fetched if the branch condition is met.
branch condition
The CPU's decision whether to alter the normal sequential execution of instructions by
fetching instructions at the branch address.
branch mask
A 4-bit field in a Branch on Condition instruction used to test the value of the Condition
Code. If a 1-bit in the branch mask matches the CC value, the branch condition is met.
conditional no-operation
An Assembler CNOP instruction that may generate NOP and NOPR instructions, causing
the Location Counter to be aligned on a specified even boundary.
extended mnemonic
An instruction mnemonic provided by the Assembler allowing you to specify a branch mask
implicitly.

Chapter V: Basic Instructions 213

 no-operation instruction
An executable instruction having no effect other than to occupy space, to align a following
instruction on a desired even boundary.
pipeline
A technique used in modern CPUs to speed instruction execution by dividing the fetch.
decode, and execute phases into smaller stages that can be occupied by more than one
instruction.

214 Assembler Language Programming for IBM System z™ Servers Version 2.00
Chapter V: Basic Instructions 215
16. Fixed-Point Binary Addition, Subtraction, and Comparison

11 6666666666
111 666666666666
1111 66 66
11 66
11 66
11 66666666666
11 666666666666
11 66 66
11 66 66
11 66 66
1111111111 666666666666
1111111111 6666666666

This section describes instructions for fixed-point two's complement binary addition, subtraction,
and comparison in the general registers, and between the general registers and memory. Because
the instructions occur in very regular groups and patterns, understanding their basic behavior
makes it easier to understand related instructions.

16.1. Signed-Arithmetic Add and Subtract Instructions

As we noted in Section 2.14 on page 37, logical addition and subtraction produce exactly the
same bit patterns as arithmetic addition and subtraction, but the resulting CC settings have dif-
ferent meanings. We'll investigate logical-arithmetic instructions in Section 16.5 on page 224.

The instructions are shown in Table 62. The first six generate 32-bit results, and the others
produce 64-bit results.

Op Mnem Type Instruction Op Mnem Type Instruction

5A A RX Add (32) 1A AR RR Add Register (32)
5B S RX Subtract (32) 1B SR RR Subtract Register (32)
4A AH RX Add Halfword (32←16) 4B SH RX Subtract Halfword (32←16)
E308 AG RXY Add (64) B308 A G R R R E Add Register (64)
E309 SG RXY Subtract (64) B309 SGR R R E Subtract Register (64)
Table 62. Frequently used add and subtract instructions

216 Assembler Language Programming for IBM System z™ Servers Version 2.00
16.2. Signed-Arithmetic Operations Using 32-Bit Registers
All the instructions in Table 62 on page 216 set the Condition Code as indicated in Table 63.

Operation CC Setting and Meaning

0: Result is zero; no overflow
c(GR R 1) = c(GR R 1) ± c(GR R 2) 1: Result is < zero; no overflow
2: Result is > zero; no overflow
c(GR R 1) = c(GR R 1) ± c(Word in memory)
3: Result has overflowed
Table 63. CC settings for arithmetic add and subtract instructions

Table 63 shows that these add and subtract instructions (like the LCR and LPR instructions in
Table 44 on page 188) can cause a fixed-point overflow exception. We'll see in Section 16.9 on
page 234 how to set the Program Mask to enable or disable an interruption.

We begin with the six add/subtract instructions A/AR, S/SR, and AH/SH. In each case, the
second operand is added to or subtracted from the first operand, and the result replaces the first
operand.

For the halfword operations AH and SH, the 16-bit second operand is brought from memory to
an internal register, extended to a word in length, and then used for the indicated operation (as we
saw in the description of LH in Section 14.3 on page 182). The notation (32←16) in Table 62
on page 216 means that the 16-bit operand is extended to 32 bits.

To illustrate arithmetic addition and subtraction, suppose we must store at ANS the sum of c(X)
and c(Y), unless the sum is negative, in which case we must also add c(Z) and subtract 17. If we
assume that X, Y, and Z name word areas of the program, then the following instructions will
calculate the required value (assuming no overflows occur).

L 6,X Copy c(X) into GR6

A 6,Y c(GR6) = c(X) + c(Y)
BNM ST Branch if sum is not negative
A 6,Z It was negative; add c(Z)
SH 6,=H'17' Subtract 17
ST ST 6,ANS Store answer at ANS
- - -
X DC F'71'
Y DC F'-220'
Z DC F'284'
ANS DS F Computed answer
Figure 81. Calculate a sum with an intermediate test

All the machine instructions are RX-type, and all but BNM refer to data operands in memory.
The characters “ST” are used both as a symbol and as an instruction mnemonic. No confusion is
possible, since the Assembler identifies a mnemonic only by its appearance as an operation field
entry.

Now, suppose we want to store the sum of the first N odd numbers at the word named Sum
where the positive integer N is stored in the halfword integer at NN.

Chapter V: Basic Instructions 217

 LH 3,NN Get the value of N from c(NN)
LM 6,9,=F'0,2,1,1' Load GR6-GR9 with 0,2,1,1
AddUp AR 6,8 Add odd integer to sum in GR6
AR 8,7 Next odd integer in GR8
SR 3,9 Decrease N by 1
BNZ AddUp Branch back (N-1) times
ST 6,Sum Store result in GR6 at SUM
- - -
NN DC H'6' Number of odd numbers to add
Sum DS F Sum of the first c(NN) odd numbers
Figure 82. Calculate the sum of the first N odd integers

In this example, the calculations inside the “loop”102 (the AR and SR instructions beginning at
Addup) are RR-type instructions; no memory references are needed. This technique is useful in
programs where processing speed is important, and enough registers are available to allow fre-
quently referenced operands to be carried in registers instead of in memory. 103

To give another simple example of using some of these instructions, suppose we wish to compute
the quantity NewStock from the formula
NewStock = OldStock + Received - Sold
where all quantities are word integers small enough in value to guarantee that no overflows will
occur. These statements will compute the desired result.

L 2,OldStock Get c(OldStock) in GR2

A 2,Received Add number of items received
S 2,Sold Subtract number of items sold
ST 2,NewStock Store result at NewStock
Figure 83. Example of arithmetic addition and subtraction

Although we assumed that no overflows can occur, it may be possible that values calculated else-
where in the program could cause an overflow here. Thus, to be careful, the above code sequence
might continue with the instructions

- - - (As above)
ST 2,NewStock (As above)
BZ ReOrder None left, must order more!
BM OverSold Reorder now! Sold more than stock!
BO Disaster Error! More than 2**31 items??
Figure 84. Testing the result of arithmetic instructions

The instructions at ReOrder and OverSold will probably do similar things, except that at OverSold
the order for new items would likely be given higher priority so our customers can receive their
previously ordered products more promptly.

16.2.1. Condition Code Settings After Arithmetic

There is an important property of Condition Code settings after a binary addition and subtraction
operation that causes an overflow: it is possible that the CPU could choose one of two CC set-
tings. For example, adding X'80000000' to itself generates an overflow (the carry out of the sign
bit isn't matched by a carry into the sign bit), and the arithmetic result is X'00000000'. The CPU
follows this rule:

102 A loop is a sequence of instructions executed repeatedly until some condition is satisfied. We'll see in Section 22 how
other instructions help us write efficient loops.
103 Don't be too impressed, however: the example is mathematically futile, because we have expended all this effort to
calculate the square of N, when a single multiply instruction would have worked just as well. (See Exercise 16.2.2 for
some mathematical background.)

218 Assembler Language Programming for IBM System z™ Servers Version 2.00
 Condition Code After Overflow
If a binary arithmetic operation causes fixed-point ovreflow, CC=3 is
given preference to indicating any other property of the result.

That is, overflow indication is given priority.

See Exercise 16.2.16 and Programming Problem 16.12.

Exercises
16.2.1.(2) In Figure 81 on page 217, what will be stored at ANS if overflow occurs?

16.2.2.(3) Show that the sum of the first N odd integers is the same as N 2.

16.2.3.(2) + In Figure 82 on page 218, we assumed that the positive integer N in c(NN) is 2 or
greater. Rewrite the instructions to handle the possibility that N may be as small as 1.

16.2.4.(2) + In a large program, a programmer wanted to decrement the value of an integer vari-
able at VARBL by 1, so he wrote the instructions
Load L 2,VARBL
S 2,ONE
ST 2,ONE (Error! Meant to use 'VARBL'!)
- - -
B Load Try again
- - -
VARBL DC F'4'
ONE DC F'1'
Unfortunately, the ST instruction stores the result in the wrong place! The program went into
an infinite loop that included the three instructions above. What sequence of values appeared
in the word named ONE?

16.2.5.(3) + Given a word integer stored at Data, write an instruction sequence that will count
the number of 1-bits in the word, and store the result in the halfword named NBits.

16.2.6.(3) + Given a word integer stored at Data, write an instruction sequence that will deter-
mine the maximum power of 2 in the word, and store the result in the halfword named MaxPow.
For example, the largest power of 2 in 9=B'1001' is 3. If c(Data) is zero, store − 1, and if
c(Data) is negative, store − 31.

16.2.7.(2) In Figure 82 on page 218, what would happen if we had written

NN DC F'6' ?

16.2.8.(3) + Complete the “assembly” of this program segment by showing the generated object
code and its locations.
Loc Object Code Assembler Language Statements
Ex16_2_8 Start X'5000'
5000 0D40_________ BASR 4,0
____ _____________ Using *,4
____ _____________ SR 2,2
____ _____________ IC 2,XX+3
____ _____________ LTR 0,2
____ 47___________ BZ Looper
____ _____________ STH 0,XX
____ _____________ Looper B * Loop forever here
____ _____________ YY DC CL4'Ugh'
____ _____________ XX DC F'-10'

Chapter V: Basic Instructions 219

 16.2.9.(4) When the “program” in Exercise 16.2.8 is stopped (because it is in an unending
loop), what will be the hexadecimal contents of the word at XX?

16.2.10.(2) + Can an arithmetic operation using AH or SH cause fixed-point overflow? Explain.

16.2.11.(3) + Suppose two constants are defined as follows:

X DC FL3'1234567'
Y DC FL3'7654321'
Write a sequence of instructions that will add the two numbers and store their sum as a 24-bit
two's complement number in the three-byte field starting at W. If the sum overflows (it can't
be represented correctly in 24 bits), branch to Over.

16.2.12.(2) In Exercise 16.2.11, what data is generated for the constant named Y?

16.2.13.(2) Explain the differences between these instruction pairs:

SR 1,1 and SR 0,0
BCR 15,1 BCR 15,0
Compare your answers to those you created for Exercise 15.4.4.

16.2.14.(3) + Complete the “assembly” of this (nonsensical) program segment by showing the
generated object code and its locations.
Loc Object Code Assembler Language Statements
8000 Ex16_2_E Start X'8000'
____ _____________ BASR 4,0
____ _____________ Using *,4
____ _____________ LM 1,2,Value
____ _____________ STCM 2,B'111',First
____ _____________ LCR 0,1
____ _____________ BC 10,*+8
____ _____________ STH 0,Last(1)
____ _____________ BCR 15,14
____ _____________ Value DC F'4'
____ _____________ DC F'-6'
____ _____________ First DS F
____ _____________ Last DS H'-10'

16.2.15.(2) + Show the contents of GR2 and the Condition Code setting after executing each of
the following instruction sequences:

1. L 2,=A(X'89ABCDEF')
AR 2,2
2. L 2,=F'2'
A 2,=A(X'7FFFFFFF')
3. L 2,=F'2'
A 2,=A(X'123345')
ICM 2,2,=X'12345'

16.2.16.(2) + For each of these arithmetic operations, show the result and the CC setting.
1. L 1,=X'80000000'
S 1,=X'80000000'

2. L 2,=X'00000000'
S 2,=X'80000000'

3. L 3,=X'FEDCBA98'
A 3,=X'FEDCBA98'

220 Assembler Language Programming for IBM System z™ Servers Version 2.00
 4. L 4,=X'FEDCBA98'
S 4,=X'87654321'

16.3. Signed-Arithmetic Operations Using 64-Bit Registers

We now investigate the instructions in the second group pictured in Table 62 on page 216. The
AG/AGR and SG/SGR instructions are 64-bit analogs of the 32-bit instructions A/AR and S/SR
illustrated above. Condition Code settings are as shown in Table 63 on page 217. To illustrate,
suppose we revise the example In Figure 81 on page 217 to use 64-bit operands:

LG 6,XX
AG 6,YY c(GG6) = c(XX) + c(YY)
BNM ST Branch if sum is not negative
AG 6,ZZ It was negative; add c(ZZ)
SG 6,=FD'17' Subtract 17 (doubleword literal)
ST STG 6,DAnswer Store result
- - -
XX DC FD'7569241038'
YY DC FD'-94226701151'
ZZ DC FD'137'
DAnswer DS FD Computed result
Figure 85. Calculate a 64-bit sum with an intermediate test

In this example, we cannot use the literal =H'17' because the System z instruction set does not
(now) provide the AGH and SGH instructions. 104 (See Exercises 16.3.1 and 16.3.2.)
Suppose we add these two large numbers:

LG 0,A Get c(A)

AG 0,B ... and c(B)
STG 0,C Store sum at C
- - -
A DC FD'9223372036854775807' = 2**63-1
B DC FD'9223372036854775807'
C DS FD Result =X'FFFFFFFFFFFFFFFE' = -2, CC=3
Figure 86. Adding two 64-bit numbers

Because a fixed-point overflow has occurred, the result is arithmetically invalid.

Exercises
16.3.1.(2) Suppose you need to add a halfword value stored in memory at HW to a 64-bit value
in GG0, and the CPU has no AGH instruction. What alternative instruction sequences could
you use?

16.3.2.(2) Do the same as in Exercise 16.3.1, but now consider subtracting the HW operand from
the 64-bit operand in GG0.

104 At the time of this writing. But new instructions like AGHI (that we'll see in Section 21) are added regularly to the
System z architecture, so check the Principles of Operation.

Chapter V: Basic Instructions 221

16.4. Signed-Arithmetic Compare Instructions
Table 64 lists the arithmetic compare instructions we'll examine:

Op Mnem Type Instruction Op Mnem Type Instruction

49 CH RX Compare Halfword (32←16) E379 CHY RXY Compare Halfword (32←16)
59 C RX Compare (32) 19 CR R R Compare (32)
E359 CY RXY Compare (32)
E320 CG RXY Compare (64) B920 C G R R R E Compare (64)
Table 64. Arithmetic compare instructions

These instructions compare the magnitudes of two arithmetic operands. Thus, all positive
numbers are greater than all negative numbers, and − 2 is greater than − 4. (We will see that
logical comparisons behave differently.) The results of an arithmetic comparison are indicated in
the CC setting, as shown in Table 65.

CC Meaning
0 Operand 1 = Operand 2
1 Operand 1 < Operand 2
2 Operand 1 > Operand 2
Table 65. CC settings after arithmetic comparisons

The CC cannot be set to 3 as a result of a compare instruction.

For the CR, C, and CH instructions, the CC setting is the same as would result from performing
SR, S, and SH instructions with the same operands, assuming that no overflow occurs. In fact,
this is how the comparison is done by the CPU: a subtraction is performed internally, and the
CC is set to reflect the sign and magnitude of the difference (that would then have been placed
back in GR R 1 or GG R 1 for a subtract instruction). Further analysis of the original operands is
required by the CPU if the internal result overflows. (See Exercise 16.4.2.)

To illustrate arithmetic comparisons, consider these instructions and their comment fields:

LM 0,3,=F'1,0,-1,-2147483647' Initialize registers GR0-GR3

* c(GR0) = -1, c(GR1) = 0, c(GR2) = +1, c(GR3) = X'80000001'
CR 1,3 CC = 2 0 > -2147483647
CR 0,2 CC = 2 1 > -1
CR 2,3 CC = 2 -1 > -2147483647
LPR 4,3 CC = 2 +2147483647 > 0
CR 4,3 CC = 2 +2147483647 > -2147483647
CR 1,0 CC = 1 0 < 1
C 0,=F'1' CC = 0 1 = 1
CH 1,=H'5' CC = 1 0 < 5
Figure 87. Examples of arithmetic comparisons

As an example of the use of a compare instruction, let us recalculate the sum of the first N odd
integers, using a different scheme from the one in Figure 82 on page 218.

222 Assembler Language Programming for IBM System z™ Servers Version 2.00
 LH 4,=H'1' c(GR4) = accumulated sum
LR 7,4 c(GR7) = count of additions
Test CH 7,NN Compare count to c(NN)
BE Store Branch if equal, N terms added
LR 0,7 Compute next odd integer
AR 0,0 Counter + counter = 2N
AH 0,=H'1' Add 1, giving next odd term
AR 4,0 Add term to sum
AH 7,=H'1' Increment count by 1
B Test Branch back to see if finished
Store ST 4,Sum Store result
Figure 88. Calculate the sum of N odd integers

This example is cumbersome but yields the desired result.105

The arithmetic comparison instructions for 64-bit registers do exactly the same operations as the
equivalent instructions do for 32-bit registers. If the second operand is shorter than the R1 reg-
ister, it is sign-extended internally to the length of the first operand before doing the comparison.

Exercises
16.4.1.(1) + Why can the CC not be set to 3 in a comparison operation?

16.4.2.(3) In executing arithmetic compare instructions, the CPU performs an internal sub-
traction. By examining the possible combinations of signs and magnitudes for the two oper-
ands, determine (1) when an internal overflow might occur as a result of the internal
subtraction, and (2) what the CPU must do to set the CC correctly in such cases.

16.4.3.(2) Suppose a programmer had written the last instruction in Figure 87 on page 222 as
CH 1,=F'5' (Rather than =H'5')
What would the CC setting be?

16.4.4.(2) + In the following program, some pieces of data are missing, as indicated by the ____
spaces. Using the available information, fill in those spaces.
Loc Object Code Assembler Language Statements
Ex16_4_4 Start X'4800'
4800 _____________ BASR 10,0
4802 _____________ Using *,10
4802 _________A056 Loop L 0,________
4806 _____________ A 0,One
480A 5000_________ ST 0,Number
480E <other ops> PrintOut Number
4824 59___________ C 0,Ten
4828 47___________ BL Loop
482C <other ops> PrintOut *
4854 00000000 Number DC F'0'
4858 00000001 One DC F'1'
485C _____________ Ten DC F'10'
End Ex16_4_4

105 There are often many ways to perform the same computation. Programming is as much an art as a science, since
you can write many different programs of varying degrees of efficiency, effectiveness, or elegance to achieve a given
objective. A key consideration is that your program be understandable by others who may have to enhance (or fix) it
in the future.

Chapter V: Basic Instructions 223

16.5. Logical-Arithmetic Add and Subtract Instructions
Logical-arithmetic instructions are used less often than signed-arithmetic instructions. They are
typically used for extended-length or multiple-precision arithmetic (we'll see some examples), and
on occasions when a sum or difference must be found without any possibility of a fixed-point
overflow interruption. (The CPU calculates Effective Addresses using logical arithmetic, but does
not set the Condition Code.)

Table 66 lists the logical arithmetic instructions we examine here:

Op Mnem Type Instruction Op Mnem Type Instruction

5E AL R X Add Logical (32) 1E ALR R R Add Logical (32)
5F SL R X Subtract Logical (32) 1F SLR R R Subtract Logical (32)
E30A ALG RXY Add Logical (64) B90A ALGR R R E Add Logical (64)
E30B SLG RXY Subtract Logical (64) B90B SLGR R R E Subtract Logical (64)
Table 66. Logical arithmetic instructions

The CC settings we saw in Table 62 on page 216 for signed arithmetic are different for logical
arithmetic. The Condition Code settings shown in Table 67 apply to all logical arithmetic
instructions, so that references to c(GR R 1) also apply to c(GG R 1).

Operation CC Setting and Meaning

0: Zero result, no carry
c(GR R 1) = c(GR R 1) ± c(GR R 2) 1: Nonzero result, no carry
c(GR R 1) = c(GR R 1) ± c(Word in memory) 2: Zero result, carry
3: Nonzero result, carry
Note: CC0 cannot occur for logical subtraction
Table 67. CC settings for logical add and subtract instructions

In Table 67, the CC settings for the logical arithmetic instructions depend only on whether a
carry occurs out of the leftmost position of the R1 register, and whether the result is zero. (Note
that CC3 does not mean an overflow has occurred!) By referring to the examples in Sections 2.6
and 2.14, we see that the following rules hold:
1. A CC zero setting is possible for AL and ALR, and for ALG and ALGR, only if the first
and second operands are both zero.
2. It is not possible to have a CC setting of zero for SL and SLR, or for SLG and SLGR. After
the ones' complement of the second operand and a low-order 1-bit are added to the first
operand, a carry must have occurred if the result is zero.

To illustrate the differences between arithmetic and logical addition and subtraction, consider
examples 1 and 2 of Section 2.11 on page 32.
• Example 1. For unsigned operands, the result of 5 − 3=2 is representable.
5-3: 0000 0101
-0000 0011
becomes
0000 0101
+1111 1101
(carry lost) 0000 0010 = 2
When we logically subtract unsigned operands, the presence of a carry means that the result
was valid, and that there was no need to “borrow” from any higher-order digit positions.
• Example 2. For unsigned operands, the result of 3 − 5 cannot be correctly represented without
“borrowing” from higher-order digit positions (negative values don't exist in this 8-bit repre-
sentation).

224 Assembler Language Programming for IBM System z™ Servers Version 2.00
 3-5: 0000 0011
-0000 0101
becomes
0000 0011
+1111 1011
(no carry) 1111 1110 = -2 (arithmetically, not logically!)
Thus, when logically subtracting unsigned operands, the absence of a carry means that we need
to “borrow” from a higher-order digit position.

Table 68 summarizes these observations:

Operation Carry No Carry

Logical
Carry to higher-order position No carry to higher-order position
Addition
Logical
No borrow from higher-order position Borrow from higher-order position
Subtraction
Table 68. CC indications for logical addition and subtraction

As in Figure 86 on page 221, we can use logical arithmetic to add the same two numbers:

LG 0,A Get c(A)

ALG 0,B ... and c(B)
STG 0,C Store sum at C
- - -
A DC FD'9223372036854775807'
B DC FD'9223372036854775807'
C DS FD Result =X'FFFFFFFFFFFFFFFE', CC=3
Figure 89. Adding two 64-bit numbers logically

The result at C is the same as before, but now there is no fixed-point overflow.

In the next section we will see how the presence or absence of a carry condition is used when we
add and subtract “long” or “multiple-precision” numbers.

To illustrate a typical use of logical arithmetic, suppose we must add and subtract 64-bit integers
represented by pairs of 32-bit integers: that is, double-length integers two words long. (Double-
length integers are also encountered as products and dividends.) That is, we must do integer
arithmetic with operands longer than a single general register.

First, consider how we find the two's complement (the negative) of such a 64-bit number. Since
we know that the two's complement is found by adding a low-order 1-bit to the ones' comple-
ment of the number, we might proceed as follows. The number to be complemented is stored in a
doubleword at ARG, and c(GR0,GR1) means the contents of the double-length register pair
formed by GR0 and GR1.

L 0,=F'-1' All one bits in GR0

LR 1,0 c(GR0,GR1) is now all 1-bits
SL 0,ARG Ones' complement of high-order part
SL 1,ARG+4 Ones' complement of low-order part
AL 1,=F'1' Now add the low-order 1 bit
BC B'1100',NoCarry Branch if no carry out of GR1 occurs
AL 0,=F'1' Propagate the carry bit to GR0
NoCarry STM 0,1,ARG Store final result back at ARG
- - -
ARG DC FD'123456787654321' 64-bit integer
Figure 90. Double-length complementation

Chapter V: Basic Instructions 225

 The first AL instruction must be used rather than an A instruction because the high-order bit of
GR1 is not a sign bit, but an arithmetically significant bit with weight 231 . If a carry out of GR1
occurs, it must be detected and propagated into the low-order bit of GR0.

The same complementation is performed by the following code sequence, but more directly (and
less obviously).

LM 0,1,ARG Get double-length operand

LCR 0,0 Complement high-order half
LCR 1,1 Complement low-order half
BZ XXX Jump if c(GR1) was 0
SL 0,=F'1' Subtract 1 from GR0
XXX STM 0,1,ARG Store result at ARG
- - -
ARG DC FD'123456787654321' 64-bit integer
Figure 91. Double-length complementation, a simpler way

The first LCR instruction forms the two's complement of the high-order 32 bits in c(GR0); that
is, we have already added a low-order 1-bit to the ones' complement of c(GR0). The following
LCR complements the low-order 32 bits, and sets the CC. If c(GR1) had been zero, its ones'
complement would have been all 1-bits, and adding a low-order one would cause a carry out the
left end of R1; the first LCR has already “propagated” a carry into GR0. For any other bit
pattern, no such carry would have occurred, so we must correct c(GR0) by subtracting off the
low-order bit that was automatically added during the execution of the first LCR. 106

Adding the two double-length integers at A and B is straightforward: the instructions are explained
in the comments.

LM 0,1,A Load A into c(GR0,GR1)

AL 1,B+4 Add low-order part of B
BC B'1100',NoCarry Branch if no carry
AL 0,=F'1' Propagate carry to high-order word
NoCarry AL 0,B Add high-order part of B
STM 0,1,Sum Store the double-length sum
- - -
Sum DS FD 8 bytes, aligned
A DC FD'888777666555'
B DC FD'222333444555'
Figure 92. Double-length addition

Subtracting 64-bit operands is done the same way, except that the condition code setting after the
first logical subtraction requires explanation.

LM 0,1,A Get first operand as c(GR0,GR1)

SL 1,B+4 Subtract low-order parts
BC B'0011',NoBorrow Branch if there's a carry
SL 0,=F'1' Reduce c(GR0) by 1 (i.e., borrow 1)
NoBorrow SL 0,B Subtract high-order parts
STM 0,1,Diff Store 64-bit difference
- - -
Diff DS FD
A DC FD'234567898765432'
B DC FD'123456787654321'
Figure 93. Double-length subtraction

106 This instruction sequence has a minor defect: if either of the LCR instructions complements the maximum negative
number X'80000000', a fixed-point overflow exception could occur. (See Exercise 16.6.5.)

226 Assembler Language Programming for IBM System z™ Servers Version 2.00
In performing a subtraction, the ones' complement of the second operand and a low-order 1-bit
are added to the first operand. If a carry occurs out of the high-order bit position of the low-order
register, then the result is correctly represented. If a carry does not occur the result is not correctly
represented, in the sense that we have tried to generate a “negative” integer in the logical represen-
tation. Hence we must “borrow” a 1-bit from the next higher bit position, so we subtract =F'1'
if the branch condition is not met.

It might help to review the examples in Section 2.11 on page 32 to clarify the relationship
between carries and overflow in the arithmetic and logical representations. The instructions in
Section 16.6 greatly simplify these operations.

Using 32-bit registers to calculate 64-bit results is unnecessary if you need only 64-bit results,
because you can use 64-bit operations instead. But if you need to calculate the 128-bit sum of two
64-bit operands, these techniques are useful. (See Exercise 16.7.4.)

To see how logical arithmetic can provide possibly misleading arithmetic results, consider the
example in Figure 83 on page 218, revised to use logical add and subtract instructions:

L 2,OldStock Get c(OldStock) in GR2

AL 2,Received Add number of items received
SL 2,Sold Subtract number of items sold
ST 2,NewStock Store result at NewStock
Figure 94. Example of logical addition and subtraction

These instructions (using logical add and subtract) are not recommended, for two reasons. First,
although the result stored at NewStock is the same in both cases, the CC setting is not; if we
follow the ST instruction by conditional branch instructions that depend on the arithmetic sign of
the result (as in Figure 84 on page 218), the branch instructions may not go to the intended
targets.

Exercises
16.5.1.(2) Suppose the instruction sequence in Figure 94 is followed by the three branch
instructions in Figure 84 on page 218. What results will cause branching to each of the three
target symbols?

16.5.2.(2) + In the complementation instructions shown in Figures 90 and 91, what additional
instructions would be needed to cause a branch to OverFlow if the 64-bit result of the
complementation overflowed?

16.5.3.(3) + In the addition instructions shown in Figure 92 on page 226, what additional
instructions would be needed to cause a branch to OverFlow if the 64-bit result of the addition
overflowed?

16.5.4.(2) + In the subtraction instructions shown in Figure 93 on page 226, what additional
instructions would be needed to cause a branch to OverFlow if the 64-bit result of the sub-
traction overflowed?

16.5.5.(2) In Figure 91 on page 226, if either 32-bit operand is the maximum negative number,
complementation by the LCR instructions will cause a fixed-point overflow condition. Revise
the instructions to produce the 64-bit two's complement without any overflow condition.

16.5.6.(3) Examine the instructions in Figures 92 and 93. Make a short table indicating all the
possible CC settings, and the operands that produce them.

16.5.7.(3) Examine the instructions in Figures 92 and 93. Revise them to set the contents of the
word at CCode to contain the correct CC setting after addition and subtraction. If you can
make the actual CC setting correct, so much the better.

16.5.8.(3) Write a sequence of instructions that form the two's complement of a 64-bit integer
represented as a pair of 32-bit words, that also set the CC to the same value as LCGR does for
the same 64-bit integer.

Chapter V: Basic Instructions 227

 16.5.9.(3) In the examples of the addition and subtraction of double-length numbers in Figures
92 and 93, make modifications to the code such that if the final double-length result overflows,
control will be transferred to OVER. The register contents need not be correct if such a transfer
is made.

16.5.10.(4) Do the same as for Exercise 16.5.9, but after the addition or subtraction, the word
named CCode should reflect the condition of the double-length result, which should also be cor-
rectly represented to 64 bits. That is, using 32-bit registers, compute the 64-bit sum as though
a 64-bit addition is performed. Extra credit: make the actual CC setting correct,

16.5.11.(2) + For the logical add and subtract instructions, each bit of the CC has a particular
meaning. Make a table with two rows and two columns summarizing the meanings of the four
possible CC values as a function of the values of its two bits.

16.5.12.(1) If a logical subtraction is performed with two operands that are identically zero, why
is the resulting CC setting not zero?

16.6. Add With Carry, Subtract With Borrow (*)

Referring to Table 67 on page 224, we can represent the Condition Code settings for logical
addition in a different way, as shown in Table 69.

CC bit 0 1
Left No carry Carry
Right Zero result Nonzero result
Table 69. CC settings after logical addition

Thus, the leftmost bit of the CC can be thought of as the “carry bit”. Similarly, referring to
Table 68 on page 225, another way to represent the CC settings for logical subtraction is pro-
vided in Table 70.

CC bit 0 1
Left Borrow (no carry) No borrow (carry)
Right Zero result Nonzero result
Table 70. CC settings after logical subtraction

The instructions in Table 71 take advantage of the leftmost CC bit to minimize the number of
instructions needed to do double-length (or multiple-length) arithmetic 107 by using the CC bit to
propagate a carry or borrow to the next higher-order operand.

Op Mnem Type Instruction Op Mnem Type Instruction

E398 ALC RXY Add Logical with Carry (32) B998 ALCR R R E Add Logical with Carry (32)
E388 ALCG RXY Add Logical with Carry (64) B988 ALCGR R R E Add Logical with Carry (64)
E399 SLB RXY Subtract Logical with Borrow B999 SLBR R R E Subtract Logical with
(32) Borrow (32)
E389 SLBG RXY Subtract Logical with Borrow B989 SLBGR R R E Subtract Logical with
(64) Borrow (64)
Table 71. Logical arithmetic instructions with carry/borrow

107 Multiple-precision arithmetic is used intensively in cryptographic applications for data security.

228 Assembler Language Programming for IBM System z™ Servers Version 2.00
 Now, we can use these instructions to improve the examples of double-length addition and sub-
traction shown in Figures 92 and 93 on page 226. First, consider addition: now, the intermediate
branch and addition of a low-order 1 are unneeded.

LM 0,1,A Load A in register pair

AL 1,B+4 Add low-order part of B
ALC 0,B Add high-order part of B with carry
STM 0,1,Sum Store the double-length sum
- - -
Sum DS FD 8 bytes, aligned
A DC FD'888777666555'
B DC FD'222333444555'
Figure 95. Double-length addition with carry

Similarly, the double-length subtraction can be rewritten:

LM 0,1,A Get first operand

SL 1,B+4 Subtract low-order parts
SLB 0,B Subtract high-order parts with borrow
STM 0,1,Diff Store 64-bit difference
- - -
Diff DS FD
A DC FD'234567898765432'
B DC FD'123456787654321'
Figure 96. Double-length subtraction with borrow

Exercises
16.6.1.(2) + Repeat Exercise 16.5.9, using Add Logical With Carry and Subtract Logical With
Borrow instructions as appropriate.

16.6.2.(3) Repeat Exercise 16.5.9, using Add Logical With Carry and Subtract Logical With
Borrow instructions as appropriate, this time storing the proper Condition Code value at CCode.

16.6.3.(3) + Suppose two 256-bit integers are stored as eight consecutive words (or four consec-
utive doublewords) in memory starting at A256 and B256 respectively. Using Add Logical With
Carry and Subtract Logical With Borrow instructions, write instructions to store their sum and
difference at Sum256 and Diff256 respectively.

16.6.4.(3) In Exercise 16.6.3, the add and subtract instructions do logical arithmetic. How
would you detect an arithmetic overflow?

16.6.5.(2) + Write an instruction sequence using ALC to add two 128-bit numbers represented
as two groups of four fullwords each.

16.7. Operations With Mixed 64-Bit and 32-Bit Operands

The instructions in Table 72 on page 230 all involve a 64-bit first operand and a 32-bit second
operand.

Chapter V: Basic Instructions 229

Op Mnem Type Instruction Op Mnem Type Instruction
B318 AGF RXY Add (64←32) B318 AGFR RRE Add Register (64←32)
B309 SGF RXY Subtract (64←32) B319 SGFR RRE Subtract Register (64←32)
E31A ALGF RXY Add Logical (64←32) B91A ALGFR RRE Add Logical (64←32)
E31B SLGF RXY Subtract Logical (64←32) B91B SLGFR RRE Subtract Logical (64←32)
E330 CGF RXY Compare (64←32) B930 CGFR RRE Compare (64←32)
Table 72. Instructions for mixed-length operands

The AGF and SGF instructions are similar to AH and SH, except that instead of sign-extending a
16-bit memory operand to 32 bits, a 32-bit memory operand is extended to 64 bits before partic-
ipating in the 64-bit operation, as illustrated in Figure 97.

┌───────────────────────────────────────┬────────────────────────────────────────┐
│ ───────── sign extended ─────────────┼s │ GG R1
└───────────────────────────────────────┴────────────────────────────────────────┘
0 32  63
┌────────────────────────────────────────┐
32─bit second operand │s │
└────────────────────────────────────────┘
0 31
Figure 97. Sign extension for instructions with mixed 32- and 64-bit signed operands

Using SGF, we can modify the example in Figure 85 on page 221 to use a word literal:

LG 6,XX
AG 6,YY c(GG6) = c(XX) + c(YY)
BNM ST Branch if sum is not negative
AG 6,ZZ It was negative; add c(ZZ)
SGF 6,=F'17' Subtract 17 (word literal)
ST STG 6,DAnswer Store result
- - - etc.
Figure 98. Calculate a 64-bit sum with an intermediate test

The AGFR and SGFR instructions use the same sign-extension process for 32-bit second oper-
ands in general registers as AGF and SGF do for 32-bit second operands in memory. For
example, if we must use only a halfword operand such as =H'17', we can rewrite Figure 98 as
follows:

LG 6,XX
AG 6,YY c(GG6) = c(XX) + c(YY)
BNM ST Branch if sum is not negative
AG 6,ZZ It was negative; add c(ZZ)
LH 0,=H'17' Load 17 into GR0 (32 bits)
SGFR 6,0 Extend; then subtract GR0 from GG6
ST STG 6,DAnswer Store result
- - - etc.
Figure 99. Calculate a 64-bit sum with an intermediate test

This approach requires an additional register (GR0) as a “temporary” register, which may be
inconvenient. Figure 99 is also one instruction and two bytes longer (counting the literal) than
Figure 98, so we could have used a word operand such as =F'17'.

Because logical arithmetic uses unsigned nonnegative operands, all bits have positive weight.
Thus, when an instruction requires unsigned operands with mixed lengths, the shorter operand is
always “sign-extended” with zero bits, as shown in Figure 100 on page 231.

230 Assembler Language Programming for IBM System z™ Servers Version 2.00
 ┌───────────────────────────────────────┬────────────────────────────────────────┐
│ ───── zeros ───── │ │ GG R1
└───────────────────────────────────────┴────────────────────────────────────────┘
0 32  63
┌────────────────────────────────────────┐
32─bit second operand │ │
└────────────────────────────────────────┘
0 31
Figure 100. Sign extension for instructions with mixed 32- and 64-bit unsigned operands

For example:
(1) LG 0,=AD(X'0123456789ABCDEF')
ALG 0,=AD(X'123456789ABCDEF0') c(GG0)=X'13579BE02468ACDF', CC=1
Adding the two operands causes no overflow and the result is nonzero, so CC=1.
(2) LG 0,=AD(X'0123456789ABCDEF')
ALGF 0,=A(X'87654321') c(GG0)=X'0123456811111110', CC=1
As in (1), but the second operand is first extended with zeros.
(3) LG 0,=AD(X'0123456789ABCDEF')
SLGF 0,=A(X'87654321') c(GG0)=X'0123456702468ACE', CC=3
Subtracting the second operand causes a carry and the result is nonzero, so CC=3.
(4) SR 1,1 c(GR1)=0
SGR 0,0 c(GG0)=0
SLGFR 0,1 c(GG0)=X'0000000000000000', CC=2
Subtracting the second operand causes a carry and the result is zero, so CC=2.

Exercises
16.7.1.(2) Revise the instructions shown in Figure 91 on page 226 to complement a pair of
64-bit integers, giving a 128-bit result.

16.7.2.(2) Revise the instructions shown in Figure 92 on page 226 to add a pair of 64-bit inte-
gers, giving a 128-bit sum.

16.7.3.(2) Revise the instructions shown in Figure 93 on page 226 to subtract a pair of 64-bit
integers, giving a 128-bit difference.

16.7.4.(3) Write instructions to form the 128-bit sum and difference of the pair of 64-bit integers
stored starting at Two64s. Store the sum at Sum128 and the difference at Diff128.

16.7.5.(1) Show the CC values after executing

SLR 0,0
and
SLGR 0,0
and after executing
SR 0,0
and
SGR 0,0

Chapter V: Basic Instructions 231

16.8. Logical-Arithmetic Compare Instructions
The logical compare instructions are shown in Table 73.

Op Mnem Type Instruction Op Mnem Type Instruction

55 CL RX Compare Logical (32) 15 CLR RR Compare Logical (32)
E321 CLG RXY Compare Logical (64) B921 CLGR RRE Compare Logical (64)
E331 CLGF RXY Compare Logical (64←32) B931 CLGFR RRE Compare Logical (64←32)
BD CLM RS Compare Logical Characters EB20 C L M H RSY Compare Logical Charac-
under Mask (32) ters under Mask (32)
EB21 CLMY RSY Compare Logical Characters
under Mask (32)
Table 73. Arithmetic compare instructions

As we saw in Section 14.7 on page 189, RXY- and RSY-type instructions behave the same way
as RX- and RS-type instructions.

The logical compare instructions test the relative magnitudes of two operands, using an unsigned
comparison instead of the signed-arithmetic comparison used for arithmetic comparisons. The
results of all logical comparisons are indicated in the CC setting, as shown in Table 74 (you'll
note that it's identical to Table 65 on page 222).

CC Meaning
0 Operand 1 = Operand 2
1 Operand 1 < Operand 2
2 Operand 1 > Operand 2
Table 74. CC settings after logical comparisons

Logical comparisons do not give the same results as arithmetic comparisons, since numbers in the
logical representation are always nonnegative. The following instruction sequence may help to
show the differences. (Following the LM instruction, the contents of R3 will be X'80000001'.)

The 64-bit logical comparison instructions behave the same way as their 32-bit equivalents. Care-
fully compare the CC settings in Figure 101 with those in Figure 87 on page 222.

LM 0,3,=F'1,0,-1,-2147483647' Initialize registers GR0-GR3

CLR 1,3 CC = 1 X'00000000' < X'80000001'
CLR 0,2 CC = 1 X'00000001' < X'FFFFFFFF'
CLR 2,3 CC = 2 X'FFFFFFFF' > X'80000001'
LPR 4,3 CC = 2; (now, c(GR4) = X'7FFFFFFF')
CLR 4,3 CC = 1 X'7FFFFFFF' < X'80000000'
CL 2,=F'+2' CC = 2 X'FFFFFFFF' > X'00000002'
CH 1,=H'5' CC = 1 X'00000000' < X'00000005'
Figure 101. Examples of logical comparisons

The CLM and CLMH instructions are unlike the other compare instructions, because the entire
first operand might not be used. Instead, they operate on selected bytes in the register, as deter-
mined by 1-bits in the M3 mask field of the instruction (just as we saw for the ICM/ICMH
instructions in Section 14.5 on page 185). The selected bytes in the register are compared to the
string of bytes in memory beginning at the second operand address. The comparison is performed
by considering the two strings to be unsigned logical numbers of length 8, 16, 24, or 32 bits. If the
mask digit M3 is zero, the CC is set to zero and no comparison is performed.
• CLM and CLMY compare selected bytes in the first operand register (either in a 32-bit register
or in the rightmost 32 bits of a 64-bit register) to the storage operand. For example:

232 Assembler Language Programming for IBM System z™ Servers Version 2.00
 L 0,=A(X'00010203') Initialize GR0
CLM 0,B'0000',=X'0123' CC = 0, because mask is 0
CLM 0,B'0001',=X'0123' CC = 2, because X'03' > X'01'
CLM 0,B'0100',=X'0123' CC = 0, because X'01' = X'01'
CLM 0,B'0110',=X'0123' CC = 1, because X'0102' < X'0123'
• CLMH does exactly the same as CLM, except that it compares bytes in the high-order half of
a 64-bit register to bytes in memory. For example:
LG 0,=AD(X'0001020304050607') Initialize GG0
CLMH 0,B'0000',=X'0123' CC = 0, because mask is 0
CLMH 0,B'0001',=X'0123' CC = 2, because X'03' > X'01'
CLMH 0,B'0100',=X'0123' CC = 0, because X'01' = X'01'
CLMH 0,B'0110',=X'0123' CC = 1, because X'0102' < X'0123'
The bytes in the low-order half of the 64-bit register are ignored.

Sometimes the logical compare instructions are used to test the ordering of values that are regu-
larly incremented. For example, if Value has been saved at different times, we could find that
Oldest DC X'789ABCDE' Oldest value
Later DC X'89ABCDEF' A later value
Newest DC X'9ABCDEF0' Most recent value
and we can use logical comparisons to determine their ordering, as in

L 0,Oldest
L 1,Later
L 2,Newest
- - -
CLR 1,0 Compare Later to Oldest
CLR 2,1 Compare Newest to Later
Figure 102. Comparing logically ordered values

then both CLR instructions will give the correct ordering of the three values.

But if the values can “wrap around” from X'FFFFFFFF' to zero, we must be more careful. For
example, suppose the three values are
Oldest DC X'FFFFFFFE' Oldest value
Later DC X'FFFFFFFF' A later value
Newest DC X'00000001' Most recent value
Then if we compare them as previously, the second comparison will fail, because the value at
Newest will be logically less than the value at Later.

To avoid this problem, we can write instead

LR 3,1 Copy Later value to GR3
SLR 3,0 Subtract Oldest value
LTR 3,3 Test result
and the Condition Code will indicate that c(Later) is indeed greater than c(Oldest). Similarly, if
we write
LR 3,2 Copy Newest value to GR3
SLR 3,1 Subtract Later value
LTR 3,3 Test result
the CC will again indicate the correct ordering.

Exercises
16.8.1.(2) Show how the CC settings after SL and SLR are related to those after CL and CLR.

Chapter V: Basic Instructions 233

 16.8.2.(2) Suppose GG0 contains X'1122334455667788', and you must compare bytes 2 through
5 (containing X'33445566') to a 4-byte memory operand named StgOp. Write an instruction or
sequence of instructions to do this.

16.8.3.(2) + Suppose c(GR0) is X'87654321' and c(GR1) is X'01234567'. What is the CC setting
and the apparent ordering of the operands after executing each of these two instructions?
CR 0,1 Compare c(GR0) to c(GR1)
CLR 0,1 Compare c(GR0) to c(GR1)
Now, suppose the sign bit of each operand has been inverted, so that c(GR0)=X'07654321'
and c(GR1)=X'81234567'. What is the CC setting and the apparent ordering of the operands
after executing each of the two instructions? Why might this sign-bit inversion be useful?

16.8.4.(2) Make a table showing the first and second comparison operands in Figures 87 and
101, and the CC settings from their arithmetic and logical comparisons. For which operands are
they the same, and why?

16.8.5.(2) What differences will occur if two binary numbers are compared using arithmetic and
then logical compare instructions?

16.8.6.(2) + Write and execute a small program to verify the assertions about correctly-ordered
logical comparisons in the examples starting with Figure 102 on page 233.

16.9. Retrieving and Setting the Program Mask (*)

The IPM and SPM instructions in Table 75 let you retrieve and set the value of the Condition
Code and the Program Mask (PM).

Op Mnem Type Instruction Op Mnem Type Instruction

B222 IPM R R E Insert Program Mask 04 SPM R R Set Program Mask
Table 75. IPM and SPM instructions

Both instructions have a single operand:

IPM R1 Insert CC and Program Mask into GR R1
SPM R1 Set CC and Program Mask from GR R1

IPM inserts the Condition Code and Program Mask into bits 34-39 of register R1, in the posi-
tions shown in Figure 103; the remaining bits of the R1 register are unchanged. Conversely, SPM
sets the Condition Code (CC) and Program Mask from the same bit positions, and ignores the
rest of the R1 register.

─────────────unchanged────────────────── ─────────unchanged────────────
┌───────────────────────────────────────┬────────────────────────────────────────┐
│///////////////////////////////////////│//CCFDUS////////////////////////////////│ R1
└───────────────────────────────────────┴────────────────────────────────────────┘
0 63
Figure 103. Bit positions used by I P M and SPM instructions (System/360 PSW sketch)

The four mask bits in the Program Mask (“FDUS” in Figure 103) control the behavior of the four
exceptions described in Section 4.6 on page 55. These four mask bits correspond to the bit posi-
tions shown in Table 76 on page 235:

234 Assembler Language Programming for IBM System z™ Servers Version 2.00
 Bit Exception Condition Controlled Int. Code
36 (F) Fixed-point overflow 8
37 (D) Decimal overflow A
38 (U) Hexadecimal floating-point underflow D
39 (S) Hexadecimal floating-point lost significance E
Table 76. Program Mask bits

Setting a mask bit to 1 enables the corresponding interruption. If the mask bit is 0, the CPU takes
a default action without an interruption.

In practice, many programmers choose to set the Program Mask to zero initially, and trust to
luck that nothing goes wrong. For example:
SR 0,0 Set c(GR0) to zero
SPM 0 Set CC and Program Mask bits to zero

Careful placement of tests for overflow can help justify such faith, but it is generally better to test
in advance for possible errors, and let a program interruption catch the unexpected and truly
exceptional cases.

For now, we are concerned only with fixed-point overflow. The result of an instruction causing a
fixed-point overflow is the same whether or not an interruption occurs; the Condition Code is set
to 3.

Exercises
16.9.1.(4) For each of the conditions controlled by a bit in the Program Mask, determine what
actions are taken by the CPU (including CC settings) when the PM bit is zero or one. (You
may need to consult the z/Architecture Principles of Operation.)

16.9.2.(2) + Write instructions that will turn off the Lost-Significance mask bit in the Program
Mask, without affecting the settings of the other mask bits.

16.9.3.(2) Assume you are executing in 24-bit addressing mode. The fullword integer at CCode
has a value of 0, 1, 2, or 3. Set the Condition Code to that value, without affecting the setting
of the Program Mask.

16.9.4.(2) Assume you are executing in 24-bit addressing mode. Store the current value of the
program mask in the rightmost four bits of the byte at PMask. The remaining 4 bits of the byte
should be zero.

16.9.5.(2) Assume you are executing in 24-bit addressing mode. Store the current value of the
Condition Code in the word at CCode without changing the Condition Code.

16.10. Summary
Operands used in arithmetic and logical operations may be extended, as we noted in Sections
14.10 and 16.7.

Operand Extension
When a source operand in a register or in memory is used as an operand
in an arithmetic instruction whose target register is longer than the
operand, the operand is extended internally to the length of the target
register:
• arithmetic operands are sign-extended
• logical operands are extended with zeros.

Examples of arithmetic instructions doing sign extension are AH, AGH, CGFR, and SGFR;
examples of logical instructions that extend with zeros are ALGF, CLGF, and CLGFR.

Chapter V: Basic Instructions 235

 In this section we examined some frequently-used instructions for addition, subtraction, and com-
parison; they are summarized in Table 77 on page 236.

Operand1 4 bytes 8 bytes

Function
Operand2 2 bytes 4 bytes 4 bytes 8 bytes
Arithmetic Add and Subtract AH A AGF AG
(from memory) SH S SGF SG
Arithmetic Add and Subtract AR AGFR AGR
(from register) SR SGFR SGR
AL ALGF ALG
Logical Add and Subtract SL SLGF SLG
(from memory) ALC ALCG
SLB SLBG
ALR ALGFR ALGR
Logical Add and Subtract SLR SLGFR SLGR
(from register) ALCR ALCGR
SLBR SLBGR
Arithmetic Compare CH C CGF CG
(to memory)
Arithmetic Compare CR CGFR CGR
(to register)
Logical Compare CL CLGF CLG
(to memory) CLM CLMH
Logical Compare CLR CLGFR CLGR
(to register)
Table 77. Summary of instructions discussed in this section

Instructions Discussed in this Section

The instruction mnemonics and opcodes are shown in the following table:

236 Assembler Language Programming for IBM System z™ Servers Version 2.00
Mnemonic Opcode Mnemonic Opcode Mnemonic Opcode
A 5A C 59 SGF E319
AG E308 CG E320 SGFR B919
AGF E318 CGF E330 SGR B909
AGFR B918 CGFR B930 SH 4B
AGR B908 CGR B920 SL 5F
AH 4A CH 49 SLB E399
AL 5E CL 55 SLBG E389
ALC E398 CLG E321 SLBGR B989
ALCG E388 CLGF E331 SLBR B999
ALCGR B988 CLGFR B931 SLG E30B
ALCR B998 CLGR B921 SLGF E31B
ALG E30A CLM BD SLGFR B91B
ALGF E31A CLMH EB20 SLGR B90B
ALGFR B91A CLR 15 SLR 1F
ALGR B90A CR 19 SR 1B
ALR 1E S 5B
AR 1A SG E309

The instruction opcodes and mnemonics are shown in the following table:

Opcode Mnemonic Opcode Mnemonic Opcode Mnemonic

15 CLR B90A ALGR E30A ALG
19 CR B90B SLGR E30B SLG
1A AR B918 AGFR E318 AGF
1B SR B919 SGFR E319 SGF
1E ALR B91A ALGFR E31A ALGF
1F SLR B91B SLGFR E31B SLGF
49 CH B920 CGR E320 CG
4A AH B921 CLGR E321 CLG
4B SH B930 CGFR E330 CGF
55 CL B931 CLGFR E331 CLGF
59 C B988 ALCGR E388 ALCG
5A A B989 SLBGR E389 SLBG
5B S B998 ALCR E398 ALC
5E AL B999 SLBR E399 SLB
5F SL BD CLM EB20 CLMH
B908 AGR E308 AG
B909 SGR E309 SG

Chapter V: Basic Instructions 237

 Terms and Definitions
addend
see augend
augend
When two numbers are added, the number being augmented (the first operand) is the
augend, to which the addend (the second operand) is added.
logical arithmetic
Binary arithmetic and comparison operations with unsigned operands.
minuend
see subtrahend
subtrahend
When one number is subtracted from another, the number being diminished (the first
operand) is the minuend, and the number being subtracted (the second operand) is the
subtrahend.

Programming Problems
Problem 16.1. Write a program that computes three word quantities X, Y, and Z that occupy
successive words in memory. Also define a 12-byte character string to occupy the same storage.
Compute the contents of the three words as follows:
c(X) = B'100000000000000' + X'C7A98' - 231471192,
c(Y) = X'C0FFEE' - C'@#$' - 694895668, and
c(Z) = 1073741823 + X'F194F6' + X'ABCD'.
Treat all the quantities as words whose values are self-defining terms. A hint: this means that
the simplest way to create them is as A-type constants.
Print the hexadecimal and character forms of the 12-byte result (using the PRINTOUT macro, for
example).

Problem 16.2. Write a program that computes four values stored in successive words at W, X,
Y, and Z. The values are to be computed according to the relations
c(W) = c(WA) + c(WB) - 929065920, where
c(WA) = B'100000000000000' and
c(WB) = X'1230000'.
c(X) = c(XA) + 50344169 + c(XB), where
c(XA) = X'5CF17' and
c(XB) = C'000'.
c(Y) = c(YA) + c(YB) + c(YC), where
c(YA) = B'11111111',
c(YB) = X'1261F02', and
c(YC) = C'ABCD'.
c(Z) = c(ZA) + c(ZB) - c(ZC), where
c(ZA) = X'CAF75A',
c(ZB) = B'1000011', and
c(ZC) = 511686493.
All the quantities used in the calculations are four-byte word-aligned constants in memory.
Define symbols having length attribute 16 and types C and X to name the same 16 bytes of
memory. Calculate W, X, Y, and Z, and print the results of your calculation in character and
hexadecimal form (using the PRINTOUT macro, for example).

Problem 16.3. Do as in Problem 16.2, but the four quantities W, X, Y, and Z are defined this
time by

238 Assembler Language Programming for IBM System z™ Servers Version 2.00
 c(W) = c(WA) + c(WB) - 759375551, where
c(WA) = B'100000000000000',
c(WB) = X'CBA98'.
c(X) = c(XA) - c(XB) + 1386388536, where
c(XA) = X'C0FFEE',
c(XB) = C'@#$'.
c(Y) = c(YA) + c(YB) + c(YC), where
c(YA) = B'11111111',
c(YB) = X'1F7C05',
c(YC) = C'ABCD'.
c(Z) = c(ZA) + c(ZB) - 975583924, where
c(ZA) = X'FFFF',
c(ZB) = -65536.
As before, print the 16 bytes of the result as a character string and as a string of 32 hexadecimal
digits.

Problem 16.4. Consider the sequence of integers starting

0, 1, 2, 3, 6, 11, 20, 37, ...,
where (after starting with 0, 1, and 2) each successive term is generated by adding the previous
three terms together.
Write a program that will compute and print the first 25 terms of this sequence. (A hint: an
appropriate choice of starting values will make it unnecessary to take special actions to print the
first few terms.)

Problem 16.5. Suppose you are given three integers A, B, and C, and you are told that they are
three successive terms in a sequence. Each term of the sequence was generated by adding the
previous three terms together.
Write a program that will generate the previous 25 terms of the sequence, for various values of
A, B, and C. As a check, you might start with values you found in solving Problem 16.4.

Problem 16.6. Write a program to do the calculations in Figures 92 through 96 for various
values of the operands. Use the PRINTOUT macro to display the values of the 64-bit results. For
example,
PRINTOUT 17,18
displays c(GG1) and c(GG2) in both hex and decimal.

Problem 16.7.(2) + The Fibonacci 108 series is defined by the relation

F(n+1) = F(n) + F(n-1) with F(0)=0 and F(1)=1
Write a program to calculate and display the numbers in the Fibonacci series starting with F(1)
up to the largest value that does not exceed one million.

Problem 16.8.(2) + Do the same as in Problem 16.7, but now calculate and display the
Fibonacci series up to the largest positive value representable in a signed 32-bit binary fullword.

Problem 16.9.(3) + Do the same as in Problem 16.8, but format and print the results using the
CONVERTO and PRINTLIN macros.

Problem 16.10.(3) Calculate the numbers in the Fibonacci series (described in Problem 16.7) up
to the maximum positive value representable using 64-bit binary arithmetic, and format and
print the results using the CONVERTO and PRINTLIN macros.

Problem 16.11.(2) + Assemble the following program:

108 Named after Leonardo of Pisa, known as Fibonacci.

Chapter V: Basic Instructions 239

 P16_11 CSect ,
Using *,12
LR 12,15
A 15,X
BASR 12,15
X DC F'18'
DC F'4'
Exit BR 14
L 10,X-4
B X-4(10)
End P16_11
Study the object code carefully, and explain what each instruction does and how it does it.

Problem 16.12.(2) + Write and execute a program to test the results of Exercise 16.2.16 above.
(Remember that the PRINTOUT macro will display both register contents and CC settings.)

240 Assembler Language Programming for IBM System z™ Servers Version 2.00
Chapter V: Basic Instructions 241
17. Binary Shifting

11 777777777777
111 777777777777
1111 77 77
11 77
11 77
11 77
11 77
11 77
11 77
11 77
1111111111 77
1111111111 77

The multiplication and division instructions in Section 18 are often combined with shift oper-
ations, so we'll start with instructions that shift data within a single general register or pair of
general registers.

The general register shift instructions are summarized in Table 78. Nine operate on data in 32-bit
registers, and five operate on 64-bit registers. The notation “(32+32)” means that 64 bits are
shifted in an even-odd pair of 32-bit general registers. There are no double-length shifts of 128-bit
operands “(64 + 64)” in an even-odd pair of 64-bit general registers.109

We say that single-length shifts operate on bits in a single 32- or 64- bit register, and double-
length shifts operate on bits in an even-odd pair of registers.

Op Mnem Type Instruction Op Mnem Type Instruction

88 SRL RS Shift Right Logical (32) 89 SLL RS Shift Left Logical (32)
8A SRA RS Shift Right Arithmetic 8B SLA RS Shift Left Arithmetic (32)
(32)
8C SRDL RS Shift Right Double 8D SLDL RS Shift Left Double Logical
Logical (32+32) (32+32)
8E SRDA RS Shift Right Double 8F SLDA RS Shift Left Double
Arithmetic (32+32) Arithmetic (32+32)
EB0C SRLG RSY Shift Right Logical (64) EB0D SLLG RSY Shift Left Logical (64)
EB0A SRAG RSY Shift Right Arithmetic EB0B SLAG RSY Shift Left Arithmetic (64)
(64)
EB1C RLLG RSY Rotate Left Logical (64) EB1D RLL RSY Rotate Left Logical (32)
Table 78. General register shift instructions

These RS-type instructions differ from other RS-type instructions: the shaded portion of the
instruction (where the R3 register specification digit would be) in Table 79 on page 243 is ignored
when the instructions are executed.

109 At the time of this writing. But new instructions are added regularly to the System z architecture, so check the Princi-
ples of Operation.

242 Assembler Language Programming for IBM System z™ Servers Version 2.00
 opcode R1 B2 D2
Table 79. RS-type shift instruction

Thus, the Assembler makes no provision for specifying a value in that field, and sets it to zero.
The operand field entry for shift instructions is written in either of the two forms
R1,D2(B2) (explicit address)
R1,S2 (implied address)
and no R 3 operand is specified.

The RSY-type shift instructions do have an R 3 operand, as shown in Table 80. For these
instructions, the source operand is in the R3 register and the result goes into the R1 register. We'll
see examples using the R3 operand when we discuss these instructions.

opcode R1 R3 B2 DL 2 DH2 opcode

Table 80. RSY-type instruction format

When executed, none of the logical shift instructions change the CC setting, while all of the arith-
metic shifts treat the shifted data as signed, and set the CC to indicate the status of the result.

For all shift instructions, the number of bit positions to be shifted is determined from the low-
order six bits of the Effective Address; this allows actual shift amounts only between 0 and 63.
That is, the shift count is the remainder obtained when the Effective Address is divided by 64:
shift count = Effective Address (modulo 64).

This means, for example, that a shift amount specified by an Effective Address of 66 actually
shifts only 2 positions when executed.

Shift Amounts
Shift instructions can specify at most 63 shifts.

First, we'll describe the unit shift, and then look at the eight RS-type instructions, all of which
involve 32-bit registers.

17.1. Unit Shifts

To illustrate the behavior of various shift instructions, we'll assume that the source register starts
with the contents illustrated in Figure 104.

┌─────┬─────┬─────┬─────┬─ ─ ─ ─┬─────┬─────┬─────┬─────┐
│ a │ b │ c │ d │ │ w │ x │ y │ z │ Before
└─────┴─────┴─────┴─────┴─ ─ ─ ─┴─────┴─────┴─────┴─────┘
0 1 2 3 n-4 n-3 n-2 n-1
Figure 104. Register contents before shifting

The bit positions are numbered from 0 to n − 1, where n is the number of bits participating in the
shift.

The basic shift operation is the unit shift, in which each bit moves right or left by one bit posi-
tion. The digit position at the right (low-order) end of the register behaves identically for logical
and arithmetic left and right shifts, but the bit at the left (high-order) end of the register is treated
differently.

For logical shifts, the vacated bit position at either end of a register is always set to zero, and the
bit shifted off the opposite end is lost and ignored. This is illustrated in Figures 105 and 106.

Chapter V: Basic Instructions 243

 ┌─────┬─────┬─────┬─────┬─ ─ ─ ─┬─────┬─────┬─────┬─────┐
┌──┼ b │ c │ d │ e │ ── │ x │ y │ z │ 0 ┼─0 After
 └─────┴─────┴─────┴─────┴─ ─ ─ ─┴─────┴─────┴─────┴─────┘
│ a │
└───┘ bit bucket
Figure 105. Logical unit shift left

The “bit bucket” doesn't really exist; it just means that the lost bit vanishes.110

┌─────┬─────┬─────┬─────┬─ ─ ─ ─┬─────┬─────┬─────┬─────┐
0─┼ 0 │ a │ b │ c │ ── │ v │ w │ x │ y ┼──┐ After
└─────┴─────┴─────┴─────┴─ ─ ─ ─┴─────┴─────┴─────┴─────┘ 
│ z │
└───┘ bit bucket
Figure 106. Logical unit shift right

For arithmetic right shifts, the rightmost bit is lost and ignored, and the sign bit is duplicated to
preserve the arithmetic integrity of the operand. This is illustrated in Figure 107.

┌─────┬─────┬─────┬─────┬─ ─ ─ ─┬─────┬─────┬─────┬─────┐
┌──┼ s ─┼ s │ b │ c │ ── │ v │ w │ x │ y ┼──┐ After
│ └──┼──┴─────┴─────┴─────┴─ ─ ─ ─┴─────┴─────┴─────┴─────┘ 
│  │ z │
└─────┘ └───┘ bit bucket
Figure 107. Arithmetic unit shift right

For arithmetic left shifts, the vacated bit position at the right end is set to zero, and the sign bit is
not shifted; it doesn't move. However, the bit immediately to the right of the sign bit is lost. This
is illustrated in Figure 108.

┌─────┬─────┬─────┬─────┬─ ─ ─ ─┬─────┬─────┬─────┬─────┐
│ s │ c │ d │ e │ ── │ x │ y │ z │ 0 ┼─0 After
└─────┴──┬──┴─────┴─────┴─ ─ ─ ─┴─────┴─────┴─────┴─────┘

│ b │
└───┘ bit bucket
Figure 108. Arithmetic unit shift left

Again, the sign of the operand is preserved. Because arithmetic left shifts may lose a significant
bit, an overflow condition can occur; we'll see how this happens when we look at the arithmetic
shift instructions in Section 17.4.

To illustrate unit shifts, suppose c(GR8) is X'87654321', or

1000 0111 0110 0101 0100 0011 0010 0001
in binary, and a unit logical left shift in GR8 is executed. Each of the bits moves one position to
the left, and the result in GR8 will be
0000 1110 1100 1010 1000 0110 0100 0010
in binary, or X'0ECA8642'. The leftmost one-bit was lost, and a zero-bit was introduced at the
right. Similarly, if we again start with X'87654321' and execute a unit logical right shift in GR8,
each bit moves one position to the right, and the result will be
0100 0011 1011 0010 1010 0001 1001 0000

110 When I took my first programming class, we were all taken to see the computer; its operation was slowed so we
could watch it shift, add, etc. After showing the shifts the instructor paused, because a student always asked “What
happens to the bits shifted off the end?” An engineer would then open a door on the end of the machine and hold up
a small silver bucket, saying gravely that the bits had to be emptied after every 8 hours of operation. Some of us
never realized it was a joke.

244 Assembler Language Programming for IBM System z™ Servers Version 2.00
 in binary, or X'43B2A190'.

The execution of a shift instruction is simple: it simply performs the number of unit shifts speci-
fied by the low-order 6 bits of its Effective Address.

Exercises
17.1.1.(1) What shift amounts are represented by each of the following Effective Addresses?

1. X'EDCBA987'
2. X'12345678'
3. X'87654321'
4. X'00000FED'
5. X'FFFFFFFF'
6. X'27A49FC1'
7. X'6789ABC0'

17.2. Single-Length Logical Shifts

The simplest shifting instructions are SRL (Shift Right Logical) and SLL (Shift Left Logical). In
most of the following examples, bit patterns will be represented in hexadecimal.

To perform a unit logical left shift of the contents of R8, we can execute the instruction
SLL 8,1(0) Shift GR8 left 1 bit position

Suppose GR8 again contains X'87654321' and GR3 contains X'82F3A2B5', executing the logical
right-shift instruction
SRL 8,16(3)
first causes the Effective Address to be computed as
X'82F3A2B5' + X'010' = X'82F3A2C5'
of which the rightmost six bits are B'000101'. Thus it shifts right five bit positions, leaving
0000 0100 0011 1011 0010 1010 0001 1001
in binary, or X'043B2A19' as the result in GR8.

In these examples, we saw that the original contents of GR8 were not preserved: that is, the shifts
can be thought of as “destructive”. All the RS-type shifts use the same register (or register pair) as
the source and target of the operation. The RSY-type shifts let you preserve the original source
operand if you like.

The SLL instruction is the most commonly used logical shift. It is often used to multiply index
values by a power of two (such as the length of an operand in memory) prior to executing an
RX-type instruction for which the shifted register is the index register. We will see many such
uses in discussing looping and indexing in Section 22.
• Suppose the word at Index contains a small positive integer N that is to be used to index into
a table of words starting at the word named Tab. To load the N-th of those words into GR0,
we could write a sequence of instructions like the following:
L 1,Index Get index word
SLL 1,2 Shift left 2 bits (multiply by 4)
L 0,Tab-4(1) Load N-th word into GR0
The shift left by two bit positions is needed so that we access the N-th word (not the N-th
byte) in the table; and we must address the table at Tab-4 because if the integer at Index is 1,
we should access the first word at Tab. If N is 1, indexing will add 4 to Tab-4, giving the
address of Tab as desired.
• Suppose we want to set the leftmost seven bits of register 8 to zero, leaving the other bits
unchanged. Then we could execute the two instructions

Chapter V: Basic Instructions 245

 SLL 8,7 Shift left 7 places, drop off bits
SRL 8,7 Shift right 7 places, bring in zeros
and the leftmost 7 bits are replaced by zeros.
• As another example, suppose we need to align the address in GR6 to a doubleword boundary.
That is, we will force the value in GR6 to be a multiple of 8 in such a way that if it is not
already so, the next higher multiple of 8 will be chosen.
This can be done very simply:

AL 6,=F'7' Force carry if possible

SRL 6,3 Drop off three bits
SLL 6,3 Multiply by 8
Figure 109. Rounding an integer to the next higher multiple of 8

The presence of any 1-bit in the three rightmost bits of the original number in GR6 will cause
a carry into the 2 3 bit position (bit number 28 of GR6).
• Suppose we have a large table of six-byte data items containing a mix of integer and character
data. Each table entry is aligned on a halfword boundary. Suppose also that the data is
arranged so that the first three bytes contain a signed 24-bit two's complement integer, and the
remaining three bytes contain the character data (see Figure 110).

──────── 3 bytes ──────── ──────── 3 bytes ────────

─ ─ ─┬─────────┬─────────┬─────────┬─────────┬─────────┬─────────┬─ ─ ─
│ │ │
│ integer data │ character data │
│ │ xx yy zz │
─ ─ ─┴─────────┴─────────┴─────────┴─────────┴─────────┴─────────┴─ ─ ─
Figure 110. A 6-byte data entry

Space for typical table entry might have been reserved with DS statements such as

Entry DS 0XL6 Define name of 6-byte data entry

IntPart DS FL3 Give name to integer part
CharPart DS CL3 And to the character part
Figure 111. Storage definitions for a 6-byte data entry

We want to retrieve the integer value from a data entry and place it into GR5 where it will be
used for some purpose in the program, and then store it from GR5 back into memory in the
format illustrated in Figure 110. We can see that L and ST instructions cannot be used,
because the operands are neither 4 bytes long nor correctly aligned in memory; similarly, LH
and STH handle only two of the three bytes.
Now, suppose GR12 contains the address of the first byte of a data entry. The instructions
needed to load the integer value into GR5 are shown in Figure 112. (Assume for the moment
that the data entry contains X'F01234xxyyzz'; for now, we'll ignore the three characters repres-
ented by “xxyyzz”.)

LH 5,0(0,12) c(GR5) = X'FFFFF012', leftmost 16 bits

SLL 5,8 c(GR5) = X'FFF01200', move left 8 bits
IC 5,2(0,12) c(GR5) = X'FFF01234', insert last 8 bits
- - - - - do some calculations with the value
STC 5,2(,12) Store rightmost 8 bits
SRL 5,8 Position remaining 16 Bits
STH 5,0(0,12) Store high-order part
Figure 112. Using shift instructions for a 6-byte data item

The arrangement of data in memory usually depends on the requirements of the application,
as well as on considerations of ease of programming or speed of execution.

246 Assembler Language Programming for IBM System z™ Servers Version 2.00
This example might tempt you to manipulate characters by inserting and shifting them in the
general registers. Resist that that temptation until after we have examined instructions designed
specifically for managing character data in Section 25.

17.2.1. Three-Operand Shift Instructions

SRLG and SLLG are the 64-bit equivalents of SRL and SLL. They behave exactly as the 32-bit
shifts, with a useful extension: rather than specifying only a single operand register (as in Table 79
on page 243), these two RSY-type instructions specify separate source and target registers. The
source operand is taken from GG R 3, shifted by the specified amount, and placed into the target
operand, GG R 1. The operand field is is written
R1,R3,D2(B2) (explicit address)
R1,R3,S2 (implied address)
Table 80 on page 243 shows the format of an RSY-type instruction.

If you specify different register numbers for R3 and R 1, the shift is “nondestructive” because the
source operand in GG R 3 is unchanged. If you specify the same register number for both R3 and
R 1, the shift is “destructive”, just like the shifts in 32-bit general registers.

To illustrate, consider these instructions:

L 0,=A(X'12345678') c(GR0) initialized
SLL 0,9 c(GR0) = X'68ACF000'
and the contents of GR0 is changed. For these instructions:
LG 1,=XL8'123456789ABCDEF0' c(GG1) initialized
SLLG 0,1,9 c(GG0) = X'68ACF135 79BDE000'

LG 1,=XL8'123456789ABCDEF0' c(GG1) initialized

SRLG 0,1,9 c(GG0) = X'00091A2B 3C4D5E6F'
in both cases, the contents of the GG1 source register is unchanged. Otherwise, the instructions
for shifting operands in 64-bit registers behave the same way as their equivalents for 32-bit regis-
ters.

Exercises
17.2.1.(2) + Suppose the string of bytes beginning at BStrg is to be considered as a string of bits.
Given an integer K stored in the word at KK, write a code sequence to place in GR0 the value
of bit K of the string. (Remember to start numbering the bits at zero.)

17.2.2.(2) A word integer at K has value between 0 and 7. Write a code sequence using shifts
that will store at KthBit a byte containing a single 1-bit at a position determined by the integer
at K. That is, if c(K)=6, then c(KthBit) = X'02'. (Remember that bits in a byte are numbered
from 0 to 7!)

17.2.3.(2) Rewrite Exercise 17.2.2 to use no shifts, but define an appropriate 8-byte table.
Which code sequence is shorter? Simpler?

17.2.4.(1) + The SLL instruction shifts data in a 32-bit general register. How many bit posi-
tions will be shifted if you specify
SLL 0,33 ?

17.2.5.(2) The word at DPG contains 4 bytes; write instructions to put those four bytes into GR1
in reverse order. Thus, if c(DPG) is X'12345678', c(GR1) will be X'78563412'.

17.2.6.(2) + GR0 contains a positive, nonzero number. Write a set of instructions that will shift
the number to the left until there is a 1-bit in bit position 1 of GR0 (the bit immediately to the
right of the sign bit). In GR1, put the number of positions shifted. Remember that the number
in GR0 must be positive when the instruction sequence terminates.

Chapter V: Basic Instructions 247

 17.2.7.(2) + Given these two constants at X and Y:
X DC FL3'1234567'
Y DC FL3'7654321'
Write instructions to add the two numbers and store their sum as a 24-bit number at W. If the
sum overflows and cannot be represented correctly, branch to OverFlo.
What are the hexadecimal representations of the constants at X and Y? What is the represen-
tation of the result stored at W, and does the sum overflow?

17.2.8.(2) What will be the result of executing this instruction?

SLL n,n(n)

17.2.9.(2) + In the example following Figure 109 on page 246, does it matter if the 3-byte
integer data is signed or unsigned? Explain.

17.3. Double-Length Logical Shifts

The double-length logical shift instructions SLDL (Shift Left Double Logical) and SRDL (Shift
Right Double Logical) work in exactly the same way as SLL and SRL, except they shift the 64
bits in a pair of even-odd 32-bit registers. The register specified by the first operand (R1) must be
an even-numbered register; otherwise a specification exception will occur. The next higher-
numbered register is the low-order half of the double-length register pair. Bits right-shifted out of
the right end of GR R 1 enter the left end of GR R 1+1, and vice versa for left shifts. (Figure 10
on page 46 shows paired general registers.)

Revisiting the example in Figure 109 on page 246, here is another way to round an integer to the
next higher multiple of 8 if it is not already a multiple of 8.
SR 7,7 Clear GR7 to zero
SRDL 6,3 Shift three bits into GR7 from GR6
LTR 7,7 Test whether the bits are zero
BZ A Branch if yes
A 6,=F'1' If not, add 1 to GR6
A SLL 6,3 Finally, multiply GR6 by 8

First, we clear GR7 by subtracting it from itself, a fast and simple way to do this. Then, we use a
shift instruction to divide by 8. The double-length shift moves the three “remainder” bits into the
three high-order bit positions of GR7. The BZ instruction branches only if the remainder bits are
all zero: that is, if the number in GR6 was already a multiple of 8. If any remainder bit is
nonzero, 1 is added to GR6. Finally, GR6 is shifted left 3 bit positions to give the correct mul-
tiple of 8.

As another example, suppose a positive nonzero integer word at N is to be shifted right as many
places as necessary to ensure that its rightmost bit is nonzero. Here are two ways we might do
this:
1. Shift left from GR5 into GR4, until only zero-bits remain in GR5. That is, if two right shifts
of the integer at N were actually needed, we will do 30 double-length left shifts.

L 5,N Get integer from N

L 4,=F'0' Clear GR4
ShiftL SLDL 4,1 Shift left one bit position
LTR 5,5 Test remaining bits in GR5
BNZ ShiftL Repeat if not zero
ST 4,N Store result
Figure 113. Shifting to make the low-order bit one (1)

248 Assembler Language Programming for IBM System z™ Servers Version 2.00
 2. This time, we shift right, testing “lost” bits:

L 4,N Get integer from N

ShiftR SRDL 4,1 Shift right once
LTR 5,5 Test sign bit of GR5
BNM ShiftR Branch if not minus
SLDL 4,1 Move the bit back
ST 4,N Store result
Figure 114. Shifting to make the low-order bit one (2)

This second example will also work for negative integers if arithmetic shift instructions are
used.

These examples illustrate simple loops, instructions that are repeated as many times as necessary
to obtain a desired result or condition. Loops are an important aspect of programming; special
System z branch instructions simplify coding of loops.111

Suppose that in a certain application we need to store some integer data in a very compact
format. The integer values are unsigned and are small enough that we can squeeze four integers
into a 32-bit word as shown in Figure 115. (Section 17.6 will describe how you can define these
four values in a word.)

9 bits 4 bits 13 bits 6 bits

┌───────────┬──────┬───────────────┬────────┐
│ aaaaaaaaa │ bbbb │ ccccccccccccc │ dddddd │
└───────────┴──────┴───────────────┴────────┘
────A──── ──B─ ──────C────── ──D───
Figure 115. Four integers packed in a 32-bit word

Suppose the four packed integers are stored at DataWord and we want to extract the second integer
(the four bbbb bits) and store their value in the word at BVal. We can do this with the
instructions in Figure 116:

L 0,DataWord Load 32 bits

SLL 0,9 c(GR0)=bbbbcccccccccccccdddddd000000000
SRL 0,28 c(GR0)=0000000000000000000000000000bbbb
ST 0,BVal Store value of b-bits
Figure 116. Extracting one packed integer from a 32-bit word

The SLL instruction shifts all the a bits off the left end of GR0, and the SRL instruction shifts all
but the four b bits off the right end of GR0, leaving only the four bbbb bits right-adjusted in
GR0.

To illustrate a more general technique, we will write instructions that extract the integers from
their compacted word format in a memory area named DataWord, separating them into individual
words named First, Second, Third, and Fourth. In Figure 117 on page 250, the comment state-
ments show the binary contents of registers GR0 and GR1; the integers to be unpacked are
named A, B, C, and D as shown in Figure 115. In Figure 117 on page 250, a letter “x” repres-
ents a bit whose value is unknown, and 0 is a zero bit. We will shift each integer from the right
end of GR0 into GR1, where it will be right-justified in GR1 and stored. This example uses only
right shifts.

As mentioned in Section 13.3 on page 162, the EQU instruction assigns the value of the operand
to the name-field symbol. This symbolic technique is very useful if the sizes of the fields must be
changed, because the shift instruction operands will be adjusted automatically by the Assembler.

111 These special “Branch on Index” and “Branch on Count” instructions neither examine nor change the CC. We will
investigate them in Section 22.

Chapter V: Basic Instructions 249

 LA EQU 9 Define bit length of integer A
LB EQU 4 Length of B
LC EQU 13 Length of C
LD EQU 6 Length of D
L 0,DataWord Load data fullword into GR0
* c(GR0) = B'aaaaaaaaabbbbcccccccccccccdddddd'
* c(GR1) = B'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
SRDL 0,LD Shift 6 bits in both registers
* c(GR0) = B'000000aaaaaaaaabbbbccccccccccccc'
* c(GR1) = B'ddddddxxxxxxxxxxxxxxxxxxxxxxxxxx'
SRL 1,32-LD Move D to right end of GR1
* c(GR1) = B'00000000000000000000000000dddddd'
ST 1,Fourth Store fourth integer D at FOURTH
SRDL 0,LC Shift 13 bits in both registers
* c(GR0) = B'0000000000000000000aaaaaaaaabbbb'
* c(GR1) = B'ccccccccccccc0000000000000000000'
SRL 1,32-LC Move C to right end of GR1
* c(GR1) = B'0000000000000000000ccccccccccccc'
ST 1,Third Store third integer C at THIRD
SRDL 0,LB Shift 4 bits in both registers
* c(GR0) = B'00000000000000000000000aaaaaaaaa'
* c(GR1) = B'bbbb0000000000000000000ccccccccc'
ST 0,First Store first integer A from GR0
SRL 1,32-LB Position second integer B in GR1
* c(GR1) = B'0000000000000000000000000000bbbb'
ST 1,Second Store second integer B at Second
Figure 117. Unpacking four unsigned integers using right shifts

We can also shift the integers left, from the left end of GR1 into the right end of GR0, but we
must clear GR0 each time before shifting.

SR 2,2 Constant zero for clearing GR0

L 1,DataWord Get data fullword in GR1
LR 0,2 Clear GR0
SLDL 0,LA Shift 9 bits into GR0 from GR1
ST 0,First Store first integer
LR 0,2 Clear GR0
SLDL 0,LB Shift 4 bits into GR0
ST 0,Second Store second integer
LR 0,2 Clear GR0
SLDL 0,LC shift 13 bits into GR1 into GR0
ST 0,Third store third integer
SRL 1,LA+LB+LC Reposition fourth integer in GR1
ST 1,Fourth Store fourth integer
Figure 118. Unpacking four unsigned integers using left shifts

We have used LR instructions to clear GR0, rather than subtracting it from itself. Similarly, in
this example the final “SRL 1,LA+LB+LC” shift replaces the LR and SLDL used in the first three
steps, because it results in less code and faster execution. The overall saving is quite small, but this
illustrates a small economy that could result in significant savings if this sequence is frequently
executed.

Exercises
17.3.1.(2) + Suppose your CPU has only single-length logical shift instructions (SLL, SRL). A
word at DataWord is to be shifted logically to the left, as though it was the high-order word of a
pair of general registers. Write an instruction sequence that simulates a double-length left shift
of N bit positions, where N is a halfword integer at NShifts. Assume 0≤ N < 32, and that the
simulated low-order “register” contains zero. Store the result at a doubleword named DWord.

250 Assembler Language Programming for IBM System z™ Servers Version 2.00
17.3.2.(2) Do the same as in Exercise 17.3.1, and again assume you must do a double-length
logical left shift of a 32-bit word in the high-order half. This time, assume 0≤ N < 64.

17.3.3.(2) + Do the same as in Exercise 17.3.1, but simulate a double-length logical right shift of
N places, where 0≤ N < 32, again assuming that the low-order half of the original 64-bit operand
is zero.

17.3.4.(2) Do the same as in Exercise 17.3.3, but now assume 0≤ N < 64.

17.3.5.(3) + Do the same as in Exercise 17.3.1, but now assume the initial data is in a
doubleword at DWData, and store the left-shifted result at DWord.

17.3.6.(3) + Do the same as in Exercise 17.3.5, but now assume the initial data is in a
doubleword at DWData, and store the right-shifted result at DWord. (Remember that 0≤ N < 32.)

17.3.7.(2) Do the same as in Exercise 17.3.5, but now assume 0≤ N < 64.

17.3.8.(2) Do the same as in Exercise 17.3.6, but now assume 0≤ N < 64.

17.3.9.(3) There is a word at OLD into which four positive integers have been packed as illus-
trated in Figure 115 on page 249. Write a code sequence to rearrange the four unsigned inte-
gers into a new word format, in which the first integer occupies the first seven bits, the second
integer occupies the next two, the third is expanded to occupy the next fifteen bits, and the
fourth integer occupies the last eight bits. Store the result at NEW.

17.3.10.(3) + Suppose four unsigned integers are stored in the words named FIRST, SECOND,
THIRD, and FOURTH. Write a code sequence that will pack the integers from those words into a
word at NEW in the format illustrated in Figure 115 on page 249.

17.3.11.(3) As in Exercise 17.3.10, assume we wish to pack the four integers at FIRST, SECOND,
THIRD, and FOURTH into a word at NEW. The number of bits to be allocated to each integer in its
packed form is given as the value of the four positive halfword integers stored at L1, L2, L3,
and L4 respectively. We know that
c(L1) + c(L2) + c(L3) + c(L4) = 32.
The integers to be packed are stored in the logical representation.

17.3.12.(3) Rewrite Exercise 17.3.11 assuming that the values are to be stored in the arithmetic
representation.

17.3.13.(2) What will happen in Figures 113 and 114 if c(N)=0?

17.3.14.(3) + A common mathematical notation is the “ceiling” function. If a number x has

integer part p and fraction part q, we write “p.q” to represent x. The “ceiling” function is
defined as:
if q = 0, Ceiling(x) = p,
if q > 0, Ceiling(x) = p+1.
Suppose there is a nonnegative integer N stored in the word at NN. Write a code sequence that
will leave Ceiling(N+N/2) in GR1.

17.3.15.(4) + Rewrite Exercise 17.3.10 to repack the four unsigned integers into a new word, but
include tests to check that the values will fit into the fields provided for them in the packed
word. To indicate whether or not each of the integers fits into its allotted field, set the bytes at
FLAG1, FLAG2, FLAG3, and FLAG4 zero if the value will fit, and to nonzero if the value will not fit.

17.3.16.(2) GR0 contains a 32-bit number considered as a bit pattern. Write a code sequence
that will place the same bit pattern into GR1, but reversed from right to left within the register.

17.3.17.(2) + The word at Data contains information to be shifted circularly: that is, bits shifted
off one end of the register should reappear at the other end. For example, a circular left shift of
the operand X'12345678' by 12 bit positions would produce X'45678123'. Write instructions

Chapter V: Basic Instructions 251

 (not using RLL!) to shift c(Data) circularly to the left by N places, where N is a nonnegative
word integer stored at NShifts. Can you do this using only single-length shifts?

17.3.18.(2) + Modify the coding of Exercise 17.3.17 so that if N is negative, the shift is a circular
right shift instead.

17.3.19.(3) + A programmer wanted to display the hex digits in a byte string starting at Hex as a
string of EBCDIC characters starting at Chars, with each EBCDIC character representing a
single hexadecimal digit. The length of the byte string with the hex digits is stored as a halfword
binary integer stored at Len. He wrote:
LH 0,Len Get length of source string in GR0
L 2,=A(Hex) Addr of start of hex string in GR2
L 3,=A(Chars) Addr of start of char string in GR3
GetAByte SR 4,4 Clear GR4 for a work register
IC 4,0(,2) Get a byte from hex string
SRDL 4,4 Move high-order hex digit in GR4
SRL 5,28 And low-order hex digit in GR5
IC 4,EBCDIC(4) Get character form of high digit
IC 5,EBCDIC(5) Get character form of low digit
SLL 4,8 Make room in GR4 for second byte
ALR 4,5 Now have both characters in GR4
STCM 4,B'0011',0(3) Store both chars in output string
AH 2,=H'1' Increment input pointer
AH 3,=H'2' Increment output pointer
SH 0,=H'1' Reduce input byte count by 1
BP GetAByte If count > 0, do another byte
- - -
EBCDIC DC C'0123456789ABCDEF' EBCDIC form of hex digits
Does this work? Explain.

17.4. Arithmetic Shift Instructions

The arithmetic shift instructions are similar to the logical shift instructions, except for the setting
of the CC and the treatment of the sign bit. The instructions are SLA (Shift Left Arithmetic),
SRA (Shift Right Arithmetic), SLDA (Shift Left Double Arithmetic), and SRDA (Shift Right
Double Arithmetic). The CC settings after arithmetic shift instructions are similar to those for the
arithmetic add and subtract instructions:

Operation CC Setting and Meaning

0: Result is zero
1: Result is < zero
Left shift
2: Result is > zero
3: Result has overflowed
0: Result is zero
1: Result is < zero
Right shift
2: Result is > zero
3: Cannot occur
Table 81. CC settings for arithmetic shift instructions

As we saw in Figure 107 on page 244, for right shifts the sign bit is duplicated (or extended) in
the vacated sign position after each unit shift, to preserve the arithmetic integrity of the shifted
operand.

To illustrate the difference between logical and arithmetic shifts, suppose a right shift of two bits
is performed on a register containing X'FFFFFFF8':

252 Assembler Language Programming for IBM System z™ Servers Version 2.00
 L 0,=F'-8' L 0,=F'-8'
SRL 0,2 SRA 0,2

After the SRL logical shift, c(GR0)=X'3FFFFFFE', because two zero bits were inserted at the left;
after the SRA arithmetic shift, c(GR0)=X'FFFFFFFE', because the sign bit has been duplicated.
For positive operands, the SRL and SRA instructions will leave identical results in the register;
SRA will set the CC as shown in Table 81 on page 252, but SRL will leave the CC unchanged.
The SRDA instruction is similar to SRA, except that an even-odd register pair is shifted as a
single 64-bit entity.

A typical use of SRDA is to create a correctly-signed 64-bit dividend for a fixed-point divide
instruction, as we will see in Section 18:
L 0,Dividend 32-bit number in GR0
SRDA 0,32 Sign-extend to 64-bit length in (GR0,GR1)
D 0,Divisor Divide by 32-bit number

The sign bit of the word at Dividend has been extended by the SRDA instruction to fill GR0.

For arithmetic left shifts, the situation is a little more complicated, as we saw in Figure 108 on
page 244. When an operand is shifted left one or more significant bits may be lost; though lost,
they are not ignored! An arithmetic left shift (1) always retains the original sign bit, and (2) indi-
cates an overflow if any bit shifted out of the position just to the right of the sign is different from
the sign bit. This is a fixed-point overflow, and may cause a program interruption with the Inter-
ruption Code set to 8.

The following instructions will produce the results indicated in the remarks fields:
L 0,=F'-8' c(GR0)=FFFFFFF8, CC unchanged
SRL 0,2 c(GR0)=3FFFFFFE, CC unchanged
SLA 0,4 c(GR0)=7FFFFFE0, CC set to 3 (Overflow)

When executing the SLA instruction, one 0-bit and three 1-bits are shifted out of the bit position
immediately to the right of the sign bit. Because the sign bit is zero after the SRL instruction, the
first one-bit to be shifted out of the bit position just to the right of the sign signals the overflow
condition, since it differs from the sign.

We can use the ICM, STCM, and SRA instructions to simplify the example in Figure 112 on
page 246:
ICM 5,B'1110',0(12) c(GR5) = X'F01234??'
SRA 5,8 c(GR5) = X'FFF01234'
- - - Compute something
STCM 5,B'0111',0(12) Store result back

As indicated in Table 81 on page 252, a CC value of 3 is not possible after the SRA and SRDA
instructions, because there can be no overflow. For SLDA and SRDA, the result tested is a
double-length operand, so these instructions provide a simple way to test whether both registers
contain zero. Both SRDA 0,0 and SLDA 0,0 will set the CC to zero if the register pair
(GR0,GR1) both contain zeros.

An important use of the arithmetic shift operations is to multiply by positive and negative powers
of two. Since the bits of an operand shifted left by a unit shift appear with a weight (in the sum
forming the value of the operand) that has increased by two, so long as no significant bits are lost
and no overflow occurs, an arithmetic left shift of n places corresponds to multiplication by 2 n .

Similarly, for a unit right shift, each bit has a weight that has decreased by two, so that an arith-
metic right shift of n places corresponds to division by 2 n . Because such a “division” might seem
to produce fractional results, we must check what happens when bits are lost. Consider these
sequences:

Chapter V: Basic Instructions 253

 L 3,=F'5' c(GR3) = 00000005 = +5
SRA 3,1 c(GR3) = 00000002 = +2 (1-bit lost)

L 3,=F'-5' c(GR3) = FFFFFFFB = -5

SRA 3,1 c(GR3) = FFFFFFFD = -3 (1-bit lost)
As we expect, the lost bit in the first case results in the fractional part of (5/2) being discarded, so
the result is simply 2. In the second case the result is − 3, not − 2; this is because the truncation
of the fraction part of a number in the two's complement representation has the effect of always
forcing the result to the next algebraically lower integer value. (See Exercises 17.4.9 and 17.4.14.)

As a simple example, suppose we wish to truncate the integer in GR9 to the next algebraically
lower multiple of 16, unless it is already a multiple of 16. Both of the following achieve the
desired result.
SRA 9,4 SRL 9,4
SLA 9,4 SLL 9,4

Either the logical or arithmetic shifts can be used, because whatever bit is shifted out of the sign
position by the SRL instruction will be put back by the SLL. If a CC setting is desired to indicate
the status of the result, arithmetic shifts must be used.

To conclude our discussion of shifting, we revisit the problem of retrieving the data packed in the
word pictured in Figure 115 on page 249, but now assuming that each of the four integers is
signed rather than logical. The following code segment separates and stores the four signed inte-
gers as required; we again use the symbols LA, LB, LC, and LD to represent the bit lengths of
the fields, as in Figure 117 on page 250.

L 0,DataWord Get data word into GR0

SRDA 0,LD Shift 6 bits into GR1
SRA 1,32-LD Sign-extend to right
ST 1,Fourth Store fullword result D
SRDA 0,LC Shift off 13 more bits into GR1
SRA 1,32-LC Shift with sign extension
ST 1,Third Store signed result of C
SRDA 0,LB Shift off next 4 bits for B
SRA 1,32-LB Sign-extend second integer
ST 1,Second Store final result of B
ST 0,First Store correct first integer A
Figure 119. Unpacking four signed integers

As noted in Section 17.2, the instructions for shifting operands in 64-bit registers behave just like
the equivalent instructions for shifting operands in 32-bit registers. To illustrate, consider these
right shift instructions:
L 0,=A(X'12345678') c(GR0) initialized
SRA 0,9 c(GR0) = X'00091A2B'
The contents of GR0 is changed. For these instructions,
LG 1,=AD(X'123456789ABCDEF0') c(GG1) initialized
SRAG 0,1,9 c(GG0) = X'00091A2B 3C4D5E6F'
the contents of the source register, GG1, is unchanged. If we initialize the source register with a
negative number, the sign bit is propagated:
L 0,=A(X'87654321') c(GR0) initialized
SRA 0,9 c(GR0) = X'FFC3B2A1'
and the contents of GR0 is changed. For these instructions,
LG 1,=XL8'FEDCBA9876543210' c(GG1) initialized
SRAG 0,1,9 c(GG0) = X'FFFF6E5D 4C3B2A19'
GG1 is again unchanged.

254 Assembler Language Programming for IBM System z™ Servers Version 2.00
Left arithmetic shifts may cause overflow:
L 0,=A(X'87654321') c(GR0) initialized
SLA 0,9 c(GR0) = X'CA864200', CC=3

LG 1,=XL8'FEDCBA9876543210' c(GG1) initialized

SLAG 0,1,9 c(GG0) = X'B97530EC A8642000', CC=3

Double-Length Shifts
The double-length shift instructions (SRDA, SLDA, SRDL, SLDL)
always require an even-odd pair of general registers.

Exercises
17.4.1.(2) Suppose your CPU has only single-length arithmetic shift instructions (SLA, SRA).
There is a word at DataWord that is to be shifted arithmetically to the left, as though it was the
high-order word of a pair of general registers. Write an instruction sequence that simulates a
double-length arithmetic left shift of N bit positions, where N is a halfword integer at NShifts.
Assume 0≤ N < 32, and that the simulated low-order “register” contains zero. Store the result at
a doubleword named DWord. If you can, show whether or not the CC setting is correct at the
end of your instruction sequence.

17.4.2.(3) Do the same as in Exercise 17.4.1, and again assume you must do a double-length
arithmetic left shift of a 32-bit word in the high-order half. This time, assume 0≤ N < 64.

17.4.3.(3) + Do the same as in Exercise 17.4.1, but simulate a double-length arithmetic right
shift of N places, where 0≤ N < 32, and still assuming that the low-order half of the original
operand is zero.

17.4.4.(3) Do the same as in Exercise 17.4.3, but now assume 0≤ N < 64.

17.4.5.(3) + Do the same as in Exercise 17.4.1, but now assume the initial data is in a
doubleword at DWData, and store the left-shifted result at DWord.

17.4.6.(3) + Do the same as in Exercise 17.4.5, but now assume the initial data is in a
doubleword at DWData, and store the right-shifted result at DWord. (Remember that 0≤ N < 32.)

17.4.7.(3) Do the same as in Exercise 17.4.5, but now assume 0≤ N < 64.

17.4.8.(3) Do the same as in Exercise 17.4.6, but now assume 0≤ N < 64.

17.4.9.(3) In mathematics it is occasionally useful to define the “integer-part-of” or “floor”

function, that yields the largest integer not exceeding its argument. It is usually written with
square brackets like this:
[X] is the largest integer ≤ X.
Show that in the two's complement binary representation, the result of arithmetically right-
shifting a number Z by n bit positions gives the result [Z/(2 n)].

17.4.10.(3) Rewrite the code sequence of Exercise 17.3.9 assuming that the integers may be pos-
itive or negative (that is, they are stored in the arithmetic representation rather than the logical
representation).

17.4.11.(2) + Suppose there is a positive nonzero word integer stored at the word at NUM. Write
an instruction sequence that leaves a number in GR0 that is the largest power of two less than
or equal to the given number. That is, compute 2**N such that 2**N ≤ c(NUM). (For
example, if c(NUM)=9, c(GR0) will be 8.)

17.4.12.(3) In Exercise 17.4.11, you wrote instructions to leave a number in GR0 that was the
largest power of two less than or equal to the nonzero positive number at NUM. Write another
instruction sequence, assuming that the number at NUM may be positive or negative. Leave a

Chapter V: Basic Instructions 255

 number in GR0 that is either zero (if c(NUM) is), or is the largest power of two less than or
equal to the magnitude of c(NUM).

17.4.13.(3) In Exercise 17.4.11, you wrote instructions to leave a number in GR0 that was the
largest power of two less than or equal to the nonzero positive number in the word at NUM.
Write another code sequence that will leave the exponent of that power of two in GR0. (That
is, if the number left in GR0 in Exercise 17.4.11 is 2**N, c(GR0) is N.)

17.4.14.(3) + In describing the shift instructions on page 253, it was stated that a right shift of N
places was equivalent to a division by 2**N. This is sometimes true, and sometimes not true.
When is it true, and when not?

17.4.15.(2) Repeat Exercise 17.3.15, assuming that the values are to be stored in the arithmetic
representation.

17.4.16.(2) Write a sequence of instructions that will count the number of 1-bits in the byte at
XX and replace the byte with its bit count.

17.4.17.(2) Suppose the initial contents of GG0 is X'FEDCBA9876543210' before executing each of
these instructions:
(1) SRAG 0,0,20
(2) SLAG 0,0,28
(3) SRA 0,18
(4) SRLG 0,0,18
What result will be in GG0 after executing each instruction, and what will be the resulting CC
setting?

17.4.18.(2) + Suppose GR0 contains X'87654321' before executing each of these instructions.
What will be in GR0 after it is executed, and what will be the CC setting?

1. SRA 0,20
2. LPR 0,0
3. SLA 0,28

17.4.19.(2) Suppose you want to display the individual bits in a byte at Byte in character form.
Write a program segment that will “spread out” the bits into eight EBCDIC characters starting
at Char so that the eight characters faithfully represent the bits in the byte.

17.4.20.(3) + Suppose your CPU supports logical but not arithmetic shifts. Write instructions
using logical shift instructions to perform the functions of SRDA, including setting the Condi-
tion Code correctly. The double-length operand to be shifted is in (GR0,GR1) and the shift
amount is in GR2. Other registers may be used as needed.

17.4.21.(2) + You can use SRA to divide a number by 2. But if the number is negative, the
result isn't always what you expect. For example:
L 0,=F'+5' c(GR0) = X'00000005' = +5
SRA 0,1 C(GR0) = X'00000002' = +2
L 0,=F'-5' c(GR0) = X'FFFFFFFB' = -5
SRA 0,1 C(GR0) = X'FFFFFFFD' = -3
In both cases the result is “rounded” downward, toward − infinity. What should you do to be
sure right-shifting a negative number will give the same result (except for sign) when you divide
by 2 as for positive numbers?

17.4.22.(1) + Show how you can use a shift instruction to test the sign of the contents of a
general register without affecting its value.

17.4.23.(2) + An arithmetic right shift of a binary number makes it smaller in magnitude, except
for two values. What are they?

256 Assembler Language Programming for IBM System z™ Servers Version 2.00
17.5. Rotating Shifts
Unlike the shift instructions we've seen, the rotating shift instructions RLL and RLLG neither
lose nor introduce bits. A rotate unit shift takes the leftmost bit of the register, shifts all the other
bits left one position, and inserts the previous leftmost bit at the right end of the register, as illus-
trated in Figure 120.

┌─────┬─────┬─────┬─────┬─ ─ ─ ─┬─────┬─────┬─────┬─────┐
┌──┼ b │ c │ d │ e │ ── │ x │ y │ z │ a ┼─┐ After
│ └─────┴─────┴─────┴─────┴─ ─ ─ ─┴─────┴─────┴─────┴─────┘ │
└─────────────────────────────────────────────────────────────┘
Figure 120. Logical rotate unit shift

As shown in Table 80 on page 243, the source operand in R 3 and the target operand in R1 can
be the same or different registers. If they are the same, the shift does not preserve the original
operand.

The rotating shift instructions are sometimes used in data compression algorithms. In applications
where speed of rotation is not important, their functions can be “emulated” using logical shifts.
(See Exercises 17.5.1 and 17.5.2.)

To illustrate a rotating shift, suppose we rotate the 32-bit operand X'56789ABC' left by 10 bit posi-
tions:
L 0,=A(X'56789ABC') Load initial data into GR0
RLL 1,0,10 Rotate 10 bits, result in GR1
Then c(GR1) will be X'E26AF159'. Similarly, if we rotate the 64-bit operand X'56789ABCDEF01234'
left by 10 bit positions:
LG 0,=AD(X'56789ABCDEF01234') Initialize GG0
RLLG 1,0,10 Rotate 10 bits, result in GG1
Then c(GG1) will be X'E26AF37BC048D159'.

Exercises
17.5.1.(2) + Suppose your CPU has only single-length logical shift instructions (SLL, SRL). A
32-bit word at DataWord is to be rotated. Write an instruction sequence that simulates the RLL
instruction by doing a logical rotation of N bit positions, where N is any nonnegative number
stored in a halfword at NN. Store the result at RotateWd.

17.5.2.(3) Do the same as in Exercise 17.5.1, but now simulate the RLLG instruction using
SLDL and SRDL to do a double-length rotating shift of N places. Assume the initial data is in
a doubleword at DWData, and store the rotated double-length result at RotatDWd.

17.5.3.(1) Show how you can use a rotating shift to exchange the halves of a 64-bit general
register.

17.6. Calculated Shift Amounts

As we saw in Section 17.2, the number of bit positions shifted can be specified during program
execution, because the number of shifts in any shift instruction is determined from its Effective
Address. For example,
SLL 9,0(4)
will shift GR9 by an amount determined by the rightmost six bits of the contents of GR4.

Suppose GR1 contains a nonnegative integer less than 31; call it “n”. Then, to leave 2 n in GR0,
we could write

Chapter V: Basic Instructions 257

 L 0,=F'1' Put 2**0 = 1 in GR0
SLL 0,0(1) Shift left 'n' places to form 2**n

The shift amount in GR1 could have been previously calculated or loaded into GR1 from
memory.

We can use shifts to illustrate an amusing (but not recommended!) application of the USING
statement. As with relocatable implied addresses, the Assembler computes displacements and
assigns base registers for absolute implied addresses. If we write the statements below, the
instructions would be assembled as indicated in the remarks fields of the last three statements.
USING 6,2 Absolute expression for base in GR2
A EQU 10 Symbol with absolute value
* Assembled instructions:
SLL 9,12 8990 2006 (implied address) 12 shifts
SLL 9,12(0) 8990 000C (explicit address) 12 shifts
SLL 9,A 8990 2004 (implied address) 10 shifts

Thus we can vary the number of shifts at execution time by placing appropriate values in the
“base” register, GR2. This is a very poor programming technique; it's far better to use an instruc-
tion like
SLL 9,0(2)
There are very few occasions where an absolute expression is used as the first operand in a
USING instruction. The need for caution is apparent when you consider what would happen to
a program with the implied-address shift instructions above, and then someone changed the con-
tents of GR2.

Exercises
17.6.1.(2) + What will happen at both assembly and execution times if the following sequence of
three statements appears in a program:
USING *,2
A EQU *
SLL 9,A

17.6.2.(2) + What number of shifts is specified by

SLL 9,* ?
Is that number fixed within any one program?

17.6.3.(2) + What number of shifts is specified by these instructions?

SLL 9,AAA
- - -
AAA DC F'12'

17.6.4.(2) Describe and evaluate the usefulness of each of the following methods for clearing a
32-bit general register x to zero: (1) SLL x,32 (2) L x,=F'0' (3) LH x,=H'0' (4)
SLDL x,32 (5) SRL x,32 (6) SRDL x,32 (7) SRDA x,32 (8) SLDA x,32.

17.6.5.(1) + In the mnemonics for the 32-bit (single-length) shift instructions, a consistent con-
vention is used to indicate (1) the type, (2) the direction, and (3) the length of the shift. Make
a table that displays this convention.

17.6.6.(1) Can you think of any reason to perform a logical shift of more than 31 bit positions
in a single register? An arithmetic shift?

17.6.7.(2) + We wish to generate a pair of bytes containing the EBCDIC characters corre-
sponding to the 2 hex digits in the byte at DATA. That is, if c(DATA) = X'4A', the generated
pair of bytes will contain X'F4C1'. Write a code sequence that will store the two characters at CH

258 Assembler Language Programming for IBM System z™ Servers Version 2.00
 and CH+1, for any values in the byte at DATA. (Hint: construct a 16-byte character table, and
access it with an indexed IC instruction.)

17.6.8.(2) + Most System z instructions expect that their operands will be found in memory at
addresses satisfying a specific boundary alignment. This usually means that the Effective
Address of an instruction should be divisible by some number. For each of the following
instructions, show the number by which the Effective Address should be divisible.

1. L
2. BC
3. LH
4. ICM
5. LR
6. SRDA
7. STM
8. STC

17.6.9.(1) How many bit positions are shifted by this instruction?

SRL 7,=F'15'

17.7. Bit-Length Constants (*)

In Figures 117, 118, and 119 we saw examples of using shift instructions to extract and insert
small binary constants in various fields within a 32-bit word. You can define constants with such
lengths using bit-length constants.

We first encountered length modifiers for binary constants in Section 11.4 on page 140, where we
defined constants like
DC FL3'8'
Such length modifiers determine the byte length of the constant.

You can also define the bit length of a constant by writing a length modifier specifying the
number of bits allotted to its assembled value; follow the modifier letter L with a period and the
number of bits. For example:
DC FL3'8' can also be written
DC FL.24'8'
The same constant will be generated in both cases, aligned on the current location counter
boundary (not necessarily a word boundary).

The general form of a length modifier is either

LByteLength as in L3
or
L(ByteLengthExpr) as in L(2+1)
or
L.BitLength as in L.24
or
L.(BitLengthExpr) as in L.(16+8)
but unfortunately you cannot combine the two by writing
LByteLength.BitLength as in L2.5
The length modifier must be either byte or bit length, not both.

For both byte- and bit-length modifiers, the length value may be written either as a positive
decimal constant or as a positive absolute expression in parentheses.

Chapter V: Basic Instructions 259

 A nominal value can be any length (subject to normal truncation and padding rules):
DC FL.12'2047',FL.8'64',XL.4'D' generates X'7FF40D'
Incomplete bytes are padded with zero bits:
DC FL.12'2047' generates X'7FF0'

Now we can see how to generate the “packed” unsigned binary integers in Figure 115 on
page 249. Suppose the four integers A, B, C, and D have values 432, 12, 5001, and 47 respec-
tively. We can define a word containing these values as shown in Figure 121.

UnsdVals DC 0F,FL.9'U432',FL.4'U12',FL.13'U5001',FL.6'U47'
Figure 121. Packing four unsigned bit-length constants in a 32-bit word

Similarly, if the four values could be signed, with values − 232, − 8, − 4001, and − 31 respectively,
we could define a word containing their values as shown in Figure 122.

SgndVals DC 0F,FL.9'-232',FL.4'-8',FL.13'-4001',FL.6'-31'
Figure 122. Packing four signed bit-length constants in a 32-bit word

Exercises
17.7.1.(1) What differences might you find for these constants?
A DC F'-97'
B DC FL4'-97'
C DC FL.32'-97'

17.7.2.(2) + In Figure 121, what constant is generated? What constant would be generated if the
letter “U” is omitted?

17.7.3.(2) + In Figure 122, what constant is generated?

17.7.4.(3) + Rewrite the constant definitions in Figures 121 and 122 to use the symbolic defi-
nitions of the four field lengths named LA, LB, LC, and LD respectively, as shown in
Figure 117 on page 250.

17.7.5.(2) + If you can't write a bit-length constant with a length modifier of the form LA.B
(where A is the byte length and B is the bit length), how can you write it to achieve equivalent
results?

17.8. Summary
Table 82 summarizes the shift instructions discussed in this section. As mentioned above, the
notation “32+32” means that the shift is in a pair of 32-bit general registers.

Function Operand length (bits) 32 32 + 32 64

SLA SLDA SLAG
Arithmetic shift
SRA SRDA SRAG
SLL SLDL SLLG
Logical shift
SRL SRDL SRLG
Rotating shift RLL RLLG
Table 82. Summary of shift instructions discussed in this section

Instructions Discussed in this Section

The instruction mnemonics and opcodes are shown in the following table:

260 Assembler Language Programming for IBM System z™ Servers Version 2.00
Mnemonic Opcode Mnemonic Opcode Mnemonic Opcode
RLL EB1D SLDL 8D SRDA 8E
RLLG EB1C SLL 89 SRDL 8C
SLA 8B SLLG EB0D SRL 88
SLAG EB0B SRA 8A SRLG EB0C
SLDA 8F SRAG EB0A

The instruction opcodes and mnemonics are shown in the following table:

Opcode Mnemonic Opcode Mnemonic Opcode Mnemonic

88 SRL 8D SLDL EB0C SRLG
89 SLL 8E SRDA EB0D SLLG
8A SRA 8F SLDA EB1C RLLG
8B SLA EB0A SRAG EB1D RLL
8C SRDL EB0B SLAG

Terms and Definitions

arithmetic shift
A movement of bits in a general register to the left or right, preserving the arithmetic sign of
the operand.
logical shift
A movement of bits in a general register to the left or right, inserting zero bits into any
vacated bit positions.
rotating shift
A movement of bits in a general register to the left in such a way that bits moved out of the
high-order bit position are inserted into the low-order bit position. (Also called a
“circulating” shift.)

Programming Problems
Problem 17.1.(2) Write a program that takes a positive word integer from the memory area
named Data and shifts it left until its next-to-highest-order bit (that is, bit number 1) is nonzero.
Store the result in a word area named Norm, and store at the halfword area Count the number of
shifts required. Print the contents of Data, Norm, and Count. Run the program with several
different values at Data such as 1, 999, 2147483647, and others.

Problem 17.2.(2) A programmer suggested using these instructions to convert the eight bits in a
byte to eight EBCDIC characters representing their value.

Chapter V: Basic Instructions 261

 ICM 1,B'1000',DataByte Put the byte at the left end of GR1
LH 2,=H'8' Set the bit count to 8
Loop SLLG 3,3,8 Make room in GG3 for the character
SR 0,0 Clear GR0
SLDL 0,1 Shift a low-order bit into GR0
A 0,=A(X'F0') Add X'F0' to make a character
ALR 3,0 Insert the character into GG3
SH 2,=H'1' Count down by 1
BP Loop Repeat for all 8 bits
STG 3,BitChars Store the 8 characters
- - -
BitChars DS D 8 EBCDIC 0 and 1 characters
Write a program with several data values to test her assertion.

Problem 17.3.(1) Using the instructions in Figure 119 on page 254, write a program to unpack
the four signed integers of Figure 122 on page 260 at the word named SgndVals and display
the unpacked values at First, Second, Third, and Fourth as fullword integers.

262 Assembler Language Programming for IBM System z™ Servers Version 2.00
Chapter V: Basic Instructions 263
18. Binary Multiplication and Division

11 8888888888
111 888888888888
1111 88 88
11 88 88
11 88888888
11 88888888
11 88 88
11 88 88
11 88 88
1111111111 888888888888
1111111111 8888888888

When we multiply two numbers, the product can be as long as the sum of their lengths. For
example, multiplying the three-digit decimal number 999 by itself, 999×999 gives 998001: six digits
long. Thus, we will need double-length registers if our products of single-length numbers can be
longer than a single register.

The terminology used for the operands is from mathematics:

multiplicand (first operand)
× multiplier (second operand)
product

18.1. Overview of Multiplication Instructions

The instructions we'll examine are summarized in Table 83. The notation “32×32” means the
product of two 32-bit integers, and similarly for “32×16”, “64×64”, and “64×32”.

Op Mnem Type Instruction Op Mnem Type Instruction

5C M R X Multiply (32 + 32←32×32) 1C MR R R Multiply Register
(32 + 32←32×32)
4C MH RX Multiply Halfword
(32←32×16)
71 MS RX Multiply Single B252 MSR R R E Multiply Single Register
(32←32×32) (32←32×32)
E351 MSY RXY Multiply Single
(32←32×32)
E30C MSG RXY Multiply Single B90C MSGR R R E Multiply Single Register
(64←64×64) (64←64×64)
E31C MSGF RXY Multiply Single B91C M S G F R R R E Multiply Single Register
(64←64×32) (64←64×32)
E396 ML RXY Multiply Logical B996 MLR R R E Multiply Logical Register
(32 + 32←32×32) (32 + 32←32×32)
E386 MLG RXY Multiply Logical B986 M L G R R R E Multiply Logical Register
(64 + 64←64×64) (64 + 64←64×64)
Table 83. Binary integer multiply instructions

264 Assembler Language Programming for IBM System z™ Servers Version 2.00
 The result of each multiply instruction is a 32-bit, 64-bit, or 128-bit product, as indicated by
“32←...” (for a single 32-bit register), “32+ 32←...” (for a 64-bit product in a pair of 32-bit regis-
ters), “64←...” (for a single 64-bit register), and “64+ 64←...” (for a 128-bit product in a pair of
64-bit registers). As we saw for signed and logical addition and subtraction, signed multiplications
sign-extend short operands, and logical multiplications zero-extend short operands.

As Table 83 on page 264 indicates, there are no instructions giving a 128-bit arithmetic product
of two signed 64-bit operands.112

None of these instructions change the CC setting.

Condition Code
Binary multiplication and division do not change the CC setting.

Signed multiply instructions are the most frequently used, so we'll discuss them first.

18.2. Arithmetic (Signed) Multiplication Instructions

The two types of arithmetic multiplication instructions give either single-length or double-length
products. Because double-length products are more often used, we'll start with those.

18.2.1. Double-Length Arithmetic Products

The instructions yielding arithmetic 64-bit double-length products are:

Op Mnem Type Instruction Op Mnem Type Instruction

5C M R X Multiply (32 + 32←32×32) 1C MR R R Multiply Register
(32 + 32←32×32)
Table 84. Double-length arithmetic multiply instructions

M and MR form the 64-bit product of two 32-bit operands. The first operand, the multiplicand,
is in the odd-numbered register of an even-odd register pair. The second operand, the multiplier,
is either in a register or a word in memory, as illustrated in Figure 123. Note that the initial
contents of the even-numbered register, GR R 1, are ignored (unless GR R 1 contains the second
operand).

R1 (even) R1+1 (odd)

┌──────────────────────┐┌──────────────────────┐
│//////////////////////││ Multiplicand │
└──────────────────────┘└──────────────────────┘
32 63 32 63

┌──────────────────────┐
│ Multiplier │ R2 or D2(X2,B2)
└──────────────────────┘ (in register or memory)
Figure 123. General layout of multiplication operands

After the operation completes, the 64-bit product is in the register pair, as shown in Figure 124
on page 266.

112 At the time of this writing. But new instructions are added regularly to the System z architecture, so check the Princi-
ples of Operation. However, you can generate signed products using the unsigned multiply instructions; see Exercises
18.3.2 and 18.3.3.

Chapter V: Basic Instructions 265

 R1 (even) R1+1 (odd)
┌──────────────────────┐┌──────────────────────┐
│ ││ │
└──────────────────────┘└──────────────────────┘
────────────────── Product ─────────────────
Figure 124. Double-length product of multiply operations

For M and MR, no fixed-point overflow is possible. As with the double-length shift instructions,
the even-numbered register is the high-order half of an even-odd register pair, and the next higher
odd-numbered register is the low-order half. The CPU takes the multiplicand from the odd-
numbered register and the multiplier from the address or register specified by the second operand.
The product replaces the original contents of the pair of registers, and the high-order bit of the
odd-numbered register is a part of the product, not necessarily a sign bit. The following
instructions produce the indicated results.
MR 2,7 c(GR2,GR3) = c(GR3) * c(GR7)
* Square the number in GR1
MR 0,1 c(GR0,GR1) = c(GR1) * c(GR1)
MR 8,8 c(GR8,GR9) = c(GR9) * c(GR8)
M 4,XX c(GR4,GR5) = c(GR5) * c(XX)
M 12,=F'932' c(GR12,GR13) = c(GR13) * 932
* Square the number in GR4
LR 5,4 Move multiplicand to GR5
MR 4,4 c(GR4,GR5) = c(GR5) * c(GR4)

The last two instructions show how to square the integer in GR4: the LR instruction copies the
multiplier to the odd-numbered register. The presence of the multiplier in the even-numbered
register does not cause it to be lost when that register is cleared at the beginning of the multiply
sequence; the multiplication takes place after the CPU has saved a copy of the multiplier. After
the LR we could also have used “MR 4,5”, giving c(GR5)×c(GR5).

The product generated by the M and MR instructions is 64 bits long. If we perform these
instructions:
L 1,=A(X'10000') c(GR1) = 65536 = 2**16
MR 0,1 Square it to get 2**32
ST 1,Product Store low-order half
- - -
Product DS F
we would find that the word stored at Product was zero, and that c(GR0) = 1. Similarly, if we
execute these instructions (where 32768 = 2 15):
L 1,=A(X'10000') c(GR1) = 65536
M 0,=A(X'8000') Multiply by 32768; result = +2**31
ST 1,Product Store +2**31 (??)
we would find that c(GR0)=0, and c(Product) = − 231!

There are two situations needing caution. First, the product may be so long that significant bits
occupy more than the low-order register. Second, whether or not the high-order register contains
significant bits, the leftmost bit of the low-order register can be interpreted as a sign bit only if the
product lies in the range
-231 ≤ product < +231
Otherwise, the low-order sign bit contains an arithmetically significant digit with positive weight.

As an example using a multiply instruction, suppose we want to evaluate A = B + G * D, a typical

expression in a high-level language. All quantities are word integers, and we assume all results are
small enough so that no overflows occur.

266 Assembler Language Programming for IBM System z™ Servers Version 2.00
 L 7,G c(GR7) = c(G)
M 6,D c(GR6,GR7) = G * D
A 7,B c(GR7) = B + (G*D)
ST 7,A Store result at A

We have used the symbols A, B, G, and D to denote both the names of word areas of memory and
the values of the contents of those areas (that is, as “variables”). This usage is typical of high-level
languages, where little distinction is made among the name associated with an area of memory,
the contents of that area, the value associated with the contents, and the name of the value.113

Suppose we wish to compute the sum of the cubes of the first N integers, where N is stored in the
word at NBR. We assume that N is a small enough positive integer that the sum of the cubes is
representable in a single word. The quantity called “K” is a counter that runs from 1 to N in
steps of 1.
SR 5,5 Sum carried in GR5
L 4,=F'1' Initialize K in GR4
Repeat LR 1,4 c(GR1) = K
MR 0,1 c(GR0,GR1) = K * K
MR 0,4 c(GR0,GR1) = K cubed
AR 5,1 Accumulate sum
A 4,=F'1' Increment K
C 4,NBR Compare to upper limit at NBR
BNH Repeat Repeat if K is not bigger
ST 5,Sum Store sum of first N cubes
- - -
NBR DC F'10' N

Figure 125 shows a slightly different version of this example; it counts from N down to 1:

SR 5,5 initialize sum to zero

L 4,NBR Initialize K from c(NBR) = N
Repeat LR 1,4 c(GR1) = K
MR 0,4 c(GR0,GR1) = K * K
MR 0,4 c(GR0,GR1) = K cubed
AR 5,1 Add to sum
S 4,=F'1' Decrement K by 1
BP Repeat Repeat if K is still positive
ST 5,SUM Store sum of first N cubes
Figure 125. Calculate the sum of the first 10 cubed integers

18.2.2. Single-Length Arithmetic Products

The instructions generating single-length arithmetic products are shown in Table 85 on page 268.

When you know a product will be small enough to fit correctly in a single-length register, or if
you don't care that some high-order bits may be lost, these instructions avoid needing an
even-odd register pair, and may also execute faster than the instructions generating double-length
products.

113 These distinctions are very important in Assembler Language, and can be very confusing to people whose first pro-
gramming experiences were with high-level languages.

Chapter V: Basic Instructions 267

Op Mnem Type Instruction Op Mnem Type Instruction
4C MH RS Multiply Halfword
(32←32×16)
71 MS RX Multiply Single B252 MSR R R E Multiply Single Register
(32←32×32) (32←32×32)
E351 MSY RXY Multiply Single
(32←32×32)
E30C MSG RXY Multiply Single B90C MSGR R R E Multiply Single Register
(64←64×64) (64←64×64)
E31C MSGF RXY Multiply Single B91C M S G F R R R E Multiply Single Register
(64←64×32) (64←64×32)
Table 85. Single-length arithmetic multiply instructions

The MH instruction produces a single-length (word) result, the low-order 32 bits of the product of
c(GR R 1) and the halfword second operand. Because only a word result is retained, R1 need not
be even. For example,
MH 5,=H'100' Multiply c(GR5) by 100
is a simple way to multiply the contents of GR5 by 100 without affecting the contents of the
lower even-numbered register, GR4. If X and Y are both halfword operands, their product may be
found by writing
LH 8,X Multiplicand in GR8 (even register!)
MH 8,Y Multiply by c(Y), product in GR8
and GR9 remains undisturbed. To square the halfword integer at N, we could write
LH 1,N c(N) in GR1
MH 1,N N squared in GR1

Because both operands are halfwords with at most 15 significant bits, the product will always fit
in a single register. The only halfword whose magnitude requires 16 bits ( − 215) when squared
yields 230, requiring only 31 bits.

As we've seen for MH, all the “Multiply Single” instructions place the product in a single-length
register. The register may be either even- or odd-numbered; the other register of the pair is not
changed. Other instructions generating a product in a 32-bit register are MS and MSR. For
example:
L 1,=F'12345' c(GR1) = 12345
MS 1,=F'12347' c(GR1) = 152423715

L 1,=F'12345' c(GR1) = 12345

L 7,=F'12347' c(GR7) = 12347
MSR 1,7 c(GR1) = 152423715
and the product is small enough to be held correctly in GR1.

MSG and MSGR, and MSGF and MSGFR produce a 64-bit product in a single 64-bit register.
MSG and MSGR are exact analogs of MS and MSR:
LG 1,=FD'12345678' c(GG1) = 12345678
MSG 1,=FD'23456789' c(GG1) = 289589963907942

LG 1,=FD'12345678' c(GG1) = 12345678

LG 7,=FD'23456789' c(GG7) = 23456789
MSGR 1,7 c(GG1) = 289589963907942

MSGF and MSGFR generate a 64-bit product of a 64-bit first operand and a 32-bit second
operand by first internally sign-extending the 32-bit second operand to 64 bits:

268 Assembler Language Programming for IBM System z™ Servers Version 2.00
 LG 1,=FD'12345678' c(GG1) = 12345678
MSGF 1,=F'23456789' c(GG1) = 289589963907942

LG 1,=FD'12345678' c(GG1) = 12345678

L 5,=F'23456789' c(GR5) = 23456789 (32 bits!)
MSGFR 1,5 c(GG1) = 289589963907942

Exercises
18.2.1.(1) + What is the value of the largest 64-bit product that can be generated by signed mul-
tiplication of 32-bit operands?

18.2.2.(4) Given two unsigned 32-bit integers stored in the words at X and Y, show first how
you can generate their unsigned 64-bit product using the arithmetic multiplication instructions
M and MR. Then, write a sequence of instructions that will store the product in the
doubleword at LogProd.
Let X be the logical (unsigned) representation corresponding to the arithmetic representation x
of some integer, and similarly for Y and y. To form the logical product of the operands X and
Y, we must modify the product xy given by the processor operation of multiplication, which
assumes that the operands are in the arithmetic representation. It will help to remember (from
Section 2.7) that
XY = (232+x)(232+y) = 264 + 232(x+y) + xy (modulo 264)

18.2.3.(2) + What is the value of the largest 48-bit product that can be generated by signed mul-
tiplication of 32-bit and 16-bit operands? The largest 96-bit value generated by signed multipli-
cation of 32-bit and 64-bit operands?

18.2.4.(3) + Write a sequence of instructions that forms the product of the positive word inte-
gers at A and B, leaves the result in (GR0,GR1), and transfers to Overflow if the result is too
large to be represented in a word.

18.2.5.(4) + Do the same as in Exercise 18.2.4, but make no restrictions on the signs of the
operands.

18.2.6.(4) + Rewrite your solution to Exercise 18.2.5 to branch to OverPos if the result is too
large and positive, and to OverNeg if the result is too large and negative.

18.2.7.(3) Suppose GR11 and GR12 contain the addresses of the first items in two tables of ten
consecutive halfword integers each. Write a code sequence that computes the “inner product”
of the two tables; that is, compute the product of the first elements from each table, add to it
the product of the second items, etc. Store the final sum as a double-length integer beginning at
the word named DwSum. The addresses in R11 and R12 may be modified. Since there are ten
products, the accumulated sum could overflow the capacity of a single register. Be sure to
handle negative products correctly.

18.2.8.(3) Simplify the coding of Exercise 18.2.2 assuming that the arithmetic representation
corresponding to x is known to be positive at all times.

18.2.9.(2) When we use the M and MR instructions, the first operand specifies an even-
numbered register. However, the multiplicand is actually in the next higher odd-numbered reg-
ister. Can you think of any reasons why the designers of System z did not require that the
actual (odd) multiplicand register be specified?

18.2.10.(2) + Write a simple sequence of instructions that will determine whether the 64-bit
product in (GR0,GR1) is too large to be carried in a single register.

18.2.11.(2) + If all values are positive, what is the value of the largest 48-bit product that can be
generated by multiplication of 32-bit and 16-bit operands? The largest 96-bit value generated by
multiplication of 32-bit and 64-bit operands?

Chapter V: Basic Instructions 269

 18.2.12.(3) Given a signed 32-bit operand A and an unsigned 32-bit operand B, write
instructions that will generate their signed 64-bit product.

18.2.13.(2) + A programmer wanted to test whether the product of two positive 32-bit binary
integers was too large to fit in a 32-bit register. Will these instructions do what he wants?
L 1,X Load first operand
M 0,Y Multiply by second operand
LTR 0,0 Check high-order 32 bits
BZ ProdOK If they're zero, product fits
- - - Not OK
X DC F'...'
Y DC F'...'

18.2.14.(3) + You have created a signed binary product in (GR0,GR1) using instructions like
L 1,X
M 0,Y
and you want to determine whether its value can be stored correctly in the 32-bit field Prod32
or (to be stored correctly) must be stored in the 64-bit field Prod64. Write instructions to make
that determination and store the result.

18.2.15.(2) What would be stored at Z by these instructions?

L 3,X
M 2,Y
SR 2,3
ST 2,Z
- - -
X DC F'9'
Y DC F'-7'
Z DS F

18.2.16.(1) + Suppose these two instructions are executed:

LH 1,N Get halfword from N
MSR 1,1 Square it
Show the value that will be in GR1 if the number at N is (1) X'8000' and (2) X'FFFF'.

18.3. Logical (Unsigned) Multiplication Instructions

Table 86 lists the logical multiplication instructions:

Op Mnem Type Instruction Op Mnem Type Instruction

E396 ML RXY Multiply Logical B996 MLR R R E Multiply Logical Register
(32 + 32←32×32) (32 + 32←32×32)
E386 MLG RXY Multiply Logical B986 MLGR R R E Multiply Logical Register
(64 + 64←64×64) (64 + 64←64×64)
Table 86. Logical multiply instructions

Logical multiply instructions are similar to arithmetic multiply instructions, except that the oper-
ands and results are unsigned. All four instructions generate a double-length product in an
even-odd register pair. Logical multiplication is frequently used when high- or multiple-precision
calculations are required114. Although you can use arithmetic multiplication instructions to gen-
erate logical products, and logical multiplication instructions to generate arithmetic products, extra

114 Some encryption and decryption algorithms use multiple-precision arithmetic extensively.

270 Assembler Language Programming for IBM System z™ Servers Version 2.00
 instructions and time are needed.115 It's simplest to use whichever instruction is best suited to the
type of operand.

For example, suppose you multiply the maximum negative 32-bit number by itself using arith-
metic and logical multiply instructions:
* Arithmetic multiplication
L 1,=X'80000000' c(GR1) = -2147483648
MR 0,1 c(GR0,GR1) = X'40000000 00000000'

* Logical multiplication
L 1,=X'80000000' c(GR1) = +2147483648
MLR 0,1 c(GR0,GR1) = X'40000000 00000000'

The result is the same in both cases. Arithmetically, the maximum negative number has value
− 231, and the same bit pattern as an unsigned number has value + 231. Thus, the product in both
cases is + 262. Now, let's try squaring a different operand, − 1:
* Arithmetic multiplication: (-1)*(-1) = +1
L 1,=F'-1' c(GR1) = X'FFFFFFFF'
MR 0,1 c(GR0,GR1) = X'00000000 00000001'

* Logical multiplication: (2**32-1)*(2**32-1) = 18446744065119617025

L 1,=F'-1' c(GR1) = X'FFFFFFFF'
MLR 0,1 c(GR0,GR1) = X'FFFFFFFE 00000001'

These results are very different! The bit pattern X'FFFFFFFF' represents −1 arithmetically, but
232 − 1 logically.

The MLG and MLGR instructions generate 128-bit products in an even-odd pair of 64-bit regis-
ters:
LG 1,=FD'74296604373' c(GG1) = 74296604373
MLG 0,=FD'9876543210' c(GG0,GG1) = 733793623446209457330

LG 1,=FD'74296604373' c(GG1) = 74296604373

LG 3,=FD'9876543210' c(GG3) = 9876543210
MLGR 0,3 c(GG0,GG1) = 733793623446209457330

These instructions can generate very large products!

Exercises
18.3.1.(1) What is the value of the largest 64-bit product that can be generated by logical multi-
plication of 32-bit operands?

18.3.2.(3) Given two signed 32-bit integers stored in the words at P and Q, show first how you
can generate their signed 64-bit product using the logical multiplication instructions ML and
MLR. Then, write a sequence of instructions that will store the product in the doubleword at
ArProd.

18.3.3.(4) Do the same as in Exercise 18.3.2, but this time form the 128-bit signed product of
two 64-bit signed operands at DP and DQ using the logical multiplication instructions MLG and
MLGR. Store the result in the pair of doublewords at ArProd2.

18.3.4.(4) As in Exercise 16.6.3 on page 229, form the product of the two 256-bit integers at
A256 and B256 to form a 512-bit product stored at Prod256.

115 Try Exercises 18.2.2 and 18.3.2.

Chapter V: Basic Instructions 271

18.4. How Multiplication Is Done (*)
To illustrate the method used in multiplication, we'll first use an example in decimal arithmetic.
Suppose we have a “processor” with registers that hold 3-digit decimal numbers that we assume
are positive, and we multiply 213 and 126. Since we are multiplying two 3-digit numbers, the
product can be 6 digits long. Thus, we assume there is a double-length 6-digit register whose right
and left halves hold a 3-digit number.

When working with pencil and paper, we form the product of the multiplier and each of the mul-
tiplicand digits in succession, and generate a series of partial products that must be properly
aligned and then added:
Multiplicand 213
Multiplier × 126
partial 1278
products 426
213
Product 26838

We'll now see how this manual process can be broken down into steps that are more like the
method used in a computer.
1. We place the multiplicand in the right half of the double-length register, and clear the left half
to zero.
Initial register contents 000 213
2. By examining the rightmost digit of the multiplicand we know how many times to add the
multiplier to the left half of the double-length register. As an aid in counting how many times
to add the multiplier, we decrement the rightmost multiplicand digit by 1 for each addition.
When the rightmost digit has been counted down to zero, the partial product of that digit
and the multiplier has been added to the accumulating result.
Initial register contents 000 213
Add multiplier to upper end +126
that's 1 time 126 212, count down at right
Add multiplier +126
that's 2 times 252 211, count down at right
Add multiplier +126
that's 3 times 378 210, count down at right
3. The entire double-length register is shifted right one digit position, at which time the (now)
zero digit at the right-hand end is lost, and a zero digit is inserted in the vacated position at
the left.
Shift right one place 037 821
Add multiplier +126
that's 1 time 163 820, count down at right
4. After the second shift, the final multiplicand digit is 2:
Shift right one place 016 382
Add multiplier +126
that's 1 time 142 381, count down at right
Add multiplier +126
that's 2 times 268 380, count down at right
Shift right one place 026 838

This process of adding the multiplier and counting down on the multiplicand digit continues until
the proper partial product has been added to the accumulated result. This process is repeated for
as many steps as there are multiplicand digits. When completed, the product is in the double-
length register, and all multiplicand digits have been shifted off the right-hand end.

The main points are:

• the multiplicand is initially placed in the right half of the double-length register;

272 Assembler Language Programming for IBM System z™ Servers Version 2.00
 • the left half is initially cleared to zero (after saving the multiplier if it was in the left half);
• the multiplier is added to the left end a number of times determined by the multiplicand digit
at the far right; and
• the least significant digit of the result is at the right-hand end of the double-length register,
because the number of right shifts was the same as the number of positions in a single-length
register.

When used for multiplying binary numbers, the above scheme is very easy to implement, because
testing the rightmost bit determines whether or not the multiplier is to be added, and no counting
is required. Suppose we have 5-digit binary numbers and registers, and wish to multiply B'00110'
(=6) by B'01001' (=9) to obtain a 10-bit product in a double-length register. The sequence of
steps in Figure 126 shows how this is done.

Initialize 00000 01001 Multiplicand, in right half of

double-length register

00110 Multiplier, in separate register

Step 1: Rightmost bit = 1,

Add multiplier 00110 01001
Shift right 1 place 00011 00100 (The 1-bit is lost)
Step 2: Rightmost bit = 0,
Shift right 1 place 00001 10010
Step 3: Rightmost bit = 0,
Shift right 1 place 00000 11001
Step 4: Rightmost bit = 1,
Add multiplier 00110 11001
Shift right 1 place 00011 01100 (The 1-bit is lost)
Step 5: rightmost bit = 0,
Shift right 1 place 00001 10110 Final product (=54)
Figure 126. Illustration of binary multiplication

It is important to observe that the product really is a double-length number, and not just two
single-length numbers joined end to end. If we consider the contents of the left and right halves of
the double-length register as ordinary single-length two's complement operands, we might believe
the result in the right, or low-order half, was negative! Since a product of two positive numbers
must be positive, a double-length register means that no special significance can be attached to the
sign bit of the low-order half of the result, unless we know in advance that the product is correctly
representable in a single register.116 The leftmost bit of the right-hand register is therefore not a
sign bit; it has positive weight in the double-length result, and the product's sign bit is the left-
most bit of the high-order register.

Modern processors gain speed by considering not just the rightmost bit of the multiplicand, but
groups of two, three, or even four bits. In cases where the arithmetic can be considered to be base
4, 8, or 16, the “proper multiple” is not found by counting down by ones on the multiplicand
bits, but by having internal shifting or table look-up circuits generate the proper factor of the mul-
tiplier in many fewer steps. This increases the speed of multiplication, since a separate addition is
not required for each 1 bit in the multiplicand.

116 Because many multiplications involve small numbers not needing a double-length product, the various “Multiply
Single” instructions were created. They can be faster than instructions generating double-length products.

Chapter V: Basic Instructions 273

18.5. Division Instructions
As with multiplication, the terminology is taken from mathematics:
Quotient
Divisor ) Dividend
- - - -
Remainder

While multiplying two n-digit numbers usually gives a 2n-digit product, dividing a 2n-digit divi-
dend by an n-digit divisor does not necessarily produce an n-digit quotient. If for example we use
3-digit decimal numbers, 999×999=998001; but 998001÷ 100 gives quotient 9980 and remainder 1,
with a 4-digit quotient.

If the divisor is zero, or if the quotient is too large to fit in a single-length register, a Fixed-Point
Divide interruption will occur, with Interruption Code 9. This condition cannot be suppressed (as
can Fixed-Point Overflow). It is important to be careful when preparing for division!

The divide instructions we'll consider are shown in Table 87.

Op Mnem Type Instruction Op Mnem Type Instruction

5D D R X Divide 1D DR R R Divide Register
(32,32←3 2 + 3 2 ÷ 32) (32,32←3 2 + 3 2 ÷ 32)
E30D DSG RXY Divide Single B90D DSGR R R E Divide Single Register
(64,64←64÷ 64) (64,64←64÷ 64)
E31D DSGF RXY Divide Single B91D D S G F R R R E Divide Single Register
(64,64←64÷ 32) (64,64←64÷ 32)
E397 DL RXY Divide Logical B997 DLR R R E Divide Logical Register
(32,32←3 2 + 3 2 ÷ 32) (32,32←3 2 + 3 2 ÷ 32)
E387 DLG RXY Divide Logical B987 D L G R R R E Divide Logical Register
(64,64←6 4 + 6 4 ÷ 64) (64,64←6 4 + 6 4 ÷ 64)
Table 87. Binary divide instructions

The notation describing the operands and results of these instructions shows the general register
results to the left of the “←” character, and the dividend and divisor to the right. For example,
for the D instruction, (32,32←32+32÷ 32) means that the quotient and remainder 32,32 are both
32-bit words; the dividend 32+32 is a pair of 32-bit registers, and the divisor is a 32-bit integer.
Similarly, for DSGF, (64,64←64÷ 32) means that the quotient, remainder, and dividend are 64-bit
integers, and the divisor is a 32-bit sign-extended integer.

As Table 87 indicates, there are no instructions (like DG, DGR) for dividing 128-bit arithmetic
operands by a signed 64-bit divisor of the form (64,64←128÷ 64), nor instructions (like DS, DSR)
for dividing 32-bit signed operands by 32-bit divisors.117

When any division instruction completes without interruption, the quotient is found in the odd-
numbered register of the pair, and the remainder in the even-numbered register, as illustrated in
Figure 127.

R1 R1+1
┌──────────────────────┐┌──────────────────────┐
│ Remainder ││ Quotient │
└──────────────────────┘└──────────────────────┘
Figure 127. General result of divide operation

117 At the time of this writing. But new instructions are added regularly to the System z architecture, so check the Princi-
ples of Operation.

274 Assembler Language Programming for IBM System z™ Servers Version 2.00
 None of the divide instructions changes the CC setting, and an even-odd register pair is always
required, even for the “Divide Single” instructions.

Register Pairs for Division

All System z binary integer divide instructions require an even-odd reg-
ister pair.

Exercises
18.5.1.(2) + If you divide an ND-digit dividend (numerator) by a DD-digit divisor (denomi-
nator), what are the minimum and maximum numbers of digits QD in the quotient and RD in
the remainder? Assume a valid division, and that zero is a valid result.

18.6. Arithmetic (Signed) Division Instructions

Table 88 summarizes the arithmetic division instructions:

Op Mnem Type Instruction Op Mnem Type Instruction

5D D R X Divide 1D DR R R Divide Register
(32,32←3 2 + 3 2 ÷ 32) (32,32←3 2 + 3 2 ÷ 32)
E30D DSG RXY Divide Single B90D DSGR R R E Divide Single Register
(64,64←64÷ 64) (64,64←64÷ 64)
E31D DSGF RXY Divide Single B91D D S G F R R R E Divide Single Register
(64,64←64÷ 32) (64,64←64÷ 32)
Table 88. Arithmetic divide instructions

The Divide Single instructions (DSG, DSGR, DSGF, and DSGFR) have only a single-length
dividend; we'll examine them shortly.

18.6.1. Double-Length Division

The most commonly used divide instructions are D and DR. The 64-bit double-length dividend
(the first operand) is placed in an even-odd pair of 32-bit registers, and the second operand (the
divisor) is in another register or a word in memory. This is illustrated in Figure 128.

R1 (even) R1+1 (odd)

┌──────────────────────┐┌──────────────────────┐
│ ││ │
└──────────────────────┘└──────────────────────┘
───────────────── Dividend ─────────────────

┌──────────────────────┐
│ Divisor │ R2 or D2(X2,B2)
└──────────────────────┘ (in register or memory)
Figure 128. Operands of double-length division

This type of division uses a double-length dividend and a single-length divisor, yielding single-
length quotient and remainder. The sign of the quotient is determined from the usual rules of
algebra; the sign of the remainder is the same as the sign of the original dividend, except that a
zero quotient or remainder always has a zero sign bit.

As with the double-length multiply instructions, the R1 digit is always even, and specifies the reg-
ister pair containing the double-length dividend. The quotient replaces the low-order half of the
dividend in the odd-numbered register, and the remainder replaces the high-order part of the divi-
dend in the even-numbered register. If a valid quotient cannot be computed, a Fixed-Point
Divide interruption occurs. (An improper division is shown in Figure 133 on page 277.)

Chapter V: Basic Instructions 275

 To illustrate, we divide the double-length number in (GR8,GR9) by the number in GR13.
DR 8,13 Divide c(GR8,GR9) by c(GR13)
To divide the same number by 10 we could write
D 8,=F'10' Divide c(GR8,GR9) by 10

The most common use of division occurs when dividing a 32-bit word operand by another. For
double-length dividends that must be 64 bits long, you can't just load the dividend operand into
an odd-numbered register and immediately divide, because the even-numbered register is treated
by the CPU as containing the most significant bits of the dividend. We must first extend the sign
bit of the single-length dividend to form its correct double-length representation.

There are two ways to do this:

1. Multiply the 32-bit dividend (in the odd-numbered register) by 1:
L 7,NN Load 32-bit dividend in GR7
M 6,=F'1' Times 1 gives 64-bit signed dividend
While easy to understand, this method may be slower than the next.
2. The most common method is to load the 32-bit dividend into the even-numbered register,
and then use an SRDA instruction:
L 6,NN c(GR6) = c(NN)
SRDA 6,32 c(GR6,GR7) = 64-bit signed dividend

Suppose we want to divide the positive or negative word integer at G by three, and store the
quotient at G_Over_3.

L 8,G Put numerator into even register

SRDA 8,32 Sign-extend to double length
D 8,=F'3' Divide by three
ST 9,G_Over_3 Store quotient
Figure 129. Example of division by 3

Suppose we want to compute the product of the integers in the words named A and B and force
the result to the next larger multiple of 29 if it is not already an exact multiple. (We assume that
the product is small enough that a fixed-point divide interruption will not occur when dividing by
29, and that the final result fits in a single word.)
L 3,A c(GR3) = c(A)
M 2,B c(GR2,GR3) = c(A) * c(B)
D 2,=F'29' Quotient in GR3
LTR 2,2 Test remainder in GR2
BZ Mult Branch if c(GR2) is zero
A 3,=F'1' increase quotient by 1
Mult M 2,=F'29' Form correct multiple of 29
ST 3,Result Store proper result
This example assumes the final product is correctly represented in the 32 bits of GR3.

Here are two examples of division with rounding.

1. Suppose we want to divide the positive integer at NN by 10, and store the rounded quotient at
QQ. This means that if the remainder is 5 or larger, the quotient must be increased by 1.

L 7,NN Low-order part of positive dividend in GR7

SR 6,6 Set high-order part to zero
D 6,=F'10' Divide by 10
C 6,=F'5' Compare remainder to 5
BL NoRound Branch if smaller than 5
A 7,=F'1' Otherwise round up
NoRound ST 7,QQ Store rounded result
Figure 130. Example of rounded integer division

276 Assembler Language Programming for IBM System z™ Servers Version 2.00
 2. Now, suppose the integer at NN can be either positive or negative. The above instruction
sequence will not work, for two reasons. First, the initial value of the dividend would not
have a correctly extended sign bit for negative arguments (because we used SR to set the
high-order register to zero). Second, because the sign of the remainder is always the same as
the sign of the original dividend, if c(NN) is negative the compare instruction will always
cause the following branch instruction to transfer control to NoRound, independent of the
magnitude of the remainder.
Here's an example of rounding the quotient of a signed dividend:

L 1,=F'1' Set up rounding increment

L 6,NN c(GR6) = c(NN)
SRDA 6,32 c(GR6,GR7) = 64-bit signed dividend
BNM Divide Jump if nonnegative dividend
LCR 1,1 Otherwise set roundoff to -1
Divide D 6,=F'10' Divide by 10
LPR 6,6 Take magnitude of remainder
C 6,=F'5' Compare to 5
BL NoRound Branch if smaller than 5
AR 7,1 Add correctly-signed roundoff
NoRound ST 7,QQ Store rounded quotient
Figure 131. Example of rounded integer division with signed dividend

See Exercise 18.6.13 for a more general technique for calculating a rounded quotient.

A simple check can be made to ensure that a fixed-point divide interruption does not occur: if the
inequality

|dividend| < |divisor| * 231

Figure 132. Ensuring a valid arithmetic division

is satisfied, then the quotient will be computed correctly. If an equality occurs in comparing these
two quantities, we must also check for the possibility that the quotient might be exactly equal to
− 231 .

To illustrate this relationship, suppose we want to divide the double-length dividend

X'0000000100000000' = 232
by two. Comparing dividend and divisor, the dividend might appear to be small enough to
produce a valid quotient:
X'0000000100000000' = 232 (dividend)
X'00000002' = 2 (divisor; high-order part of dividend is smaller?)

The divisor 2 multiplied by 231 is actually equal to the dividend, so that the inequality in
Figure 132 is not satisfied. Since both dividend and divisor are positive, the quotient must also
be positive; but the quotient is actually X'80000000', which is not representable as a positive
number for signed division.

Thus, a fixed-point divide interruption can be thought of as indicating a “quotient overflow”. To

show how this might occur in a program, consider the segment below.

L 1,=A(X'40000') c(GR1) = 2**18

MR 0,1 Square it, to generate 2**36
D 0,=F'10' Try to divide by 10
Figure 133. Causing a fixed-point divide interruption

Because 236 is not less than 10×231, a fixed-point divide interruption will occur.

Chapter V: Basic Instructions 277

 18.6.2. Single-Length Division
The arithmetic division instructions using a single-length dividend in a 64-bit register are DSG,
DSGR, DSGF, and DSGFR. Even though the dividend occupies a single 64-bit register (unlike
double-length dividends that require a register pair), a single-length dividend is always placed in
the odd-numbered register. (It's easiest to think of it as being extended internally to double length
before division begins.)

Even though the dividend is in the odd-numbered register, the instruction must specify the even-
numbered register as the R1 operand. This is illustrated in Figure 134 on page 278.

R1 (even) R1+1 (odd)

┌──────────────────────┐┌──────────────────────┐
│ //////////////////// ││ Dividend │
└──────────────────────┘└──────────────────────┘

┌──────────────────────┐
│ Divisor │ R2 or D2(X2,B2)
└──────────────────────┘ (in register or memory)
Figure 134. Operands of single-length division before division

After division, the results appear as in Figure 135.

R1 (even) R1+1 (odd)

┌──────────────────────┐┌──────────────────────┐
│ Remainder ││ Quotient │
└──────────────────────┘└──────────────────────┘
Figure 135. Operands of single-length division after division

For example, suppose you want to divide 12345678901 by 777:

LG 5,=FD'12345678901' c(GG1) = 12345678901
DSG 4,=FD'777' Divide by 777 (64-bit divisor)
* c(GG4) = 493 (remainder), c(GG5) = 15888904 (quotient)

LG 5,=FD'12345678901' c(GG1) = 12345678901

LG 9,=FD'777' c(GG9) = 777 (64 bits)
DSGR 4,9 Divide by 777

The same divisions using DSGF and DSGFR with 32-bit divisors are very similar:
LG 5,=FD'12345678901' c(GG1) = 12345678901
DSGF 4,=F'777' Divide by 777 (32-bit divisor)

LG 5,=FD'12345678901' c(GG1) = 12345678901

L 9,=F'777' c(GR9) = 777 (32 bits)
DSGFR 4,9 Divide by 777
and the 32-bit second operands are internally sign-extended to 64 bits.

Note that for single-length division, there is no need to initialize the even-numbered register R1.

Exercises
18.6.1.(2) In the inequality in Figure 132 on page 277 that assures that a division will be
correct, explain the factor of 231. Why isn't it a factor of 232?

18.6.2.(4) Suppose n is the number of some register. Under what circumstances will DR n,n not
cause a program interruption?

278 Assembler Language Programming for IBM System z™ Servers Version 2.00
 18.6.3.(2) + Write a sequence of instructions to simulate a “Divide Halfword” operation. That
is, given a word dividend at WDividen and a halfword divisor at HDivisor, store the halfword
quotient and remainder at HQuotent and HRemaind respectively.

18.6.4.(2) + Suppose the dividend in a signed fixed-point division can be correctly represented in
a word. Can division by a nonzero word divisor cause a fixed-point divide interruption?

18.6.5.(2) Under what circumstances can a fixed-point divide interruption occur in Figure 129
on page 276?

18.6.6.(2) Rewrite the example in Figure 130 on page 276 to round the result by adding 5
before dividing by 10. Determine carefully whether or not there might be a carry from the addi-
tion into the high-order register.

18.6.7.(2) Rewrite the example in Figure 131 on page 277 to round the dividend before
dividing by adding or subtracting 5. Determine carefully how to handle a possible carry or
borrow from the low-order to the high-order register.

18.6.8.(4) Consider the problem of simulating logical division by using arithmetic divide
instructions. Sketch a code sequence that will do this.

18.6.9.(2) Suppose the SRDA instruction is not available, and you want to divide the word
integer in GR1 by another in GR2. Show how you can set up the double-length dividend
without multiplying by 1.

18.6.10.(2) + Figure 131 on page 277 illustrates a rounded division with positive divisor and
signed dividend. Show what changes are needed if the divisor can also be negative.

18.6.11.(3) + Figure 130 on page 276 shows a way to compute a rounded quotient. The
rounding factor 5 is half the divisor, 10. Write a sequence of instructions to generalize this by
computing
quotient = (dividend / divisor) + 1/2

18.6.12.(1) + A programmer wanted to divide the positive number in GR5 by 2, and wrote
SR 4,4 Clear high-order word
D 4,=F'2' Divide c(GR5) by 2
Find a simpler way to do this.

18.6.13.(3) + Write an instruction sequence showing how to calculate a rounded integer quotient
using 32-bit operands, without knowing the magnitude of the divisor.

18.6.14.(2) + A table of 15 reasonably small halfword grades is stored starting at Grades. Write
instructions to compute their average value and store it at AvgGrade.

18.7. Logical (Unsigned) Division Instructions

The logical division instructions are shown in Table 89:

Op Mnem Type Instruction Op Mnem Type Instruction

E397 DL RXY Divide Logical B997 DLR R R E Divide Logical Register
(32,32←3 2 + 3 2 ÷ 32) (32,32←3 2 + 3 2 ÷ 32)
E387 DLG RXY Divide Logical B987 DLGR R R E Divide Logical Register
(64,64←6 4 + 6 4 ÷ 64) (64,64←6 4 + 6 4 ÷ 64)
Table 89. Binary divide instructions

Chapter V: Basic Instructions 279

 These four instructions divide a double-length unsigned dividend by a single-length unsigned
divisor, giving a single-length unsigned quotient in the odd-numbered register and the unsigned
single-length remainder in the even-numbered register.

If both dividend and divisor are positive, logical and arithmetic division generate the same results.
For example, dividing X'00000000 FFFFFFFF' by 3 generates quotient X'55555555' and remainder 0
for both types of division.

As you might expect, negative signed operands can produce very different results when used as
logical operands in unsigned division. For example, an arithmetic division of the maximum nega-
tive number (X'80000000') by −1 (X'FFFFFFFF') is invalid; but a logical division using the same
operands gives quotient zero and remainder X'80000000' (because 231 is smaller than 232 − 1).

Here is a case that succeeds for arithmetic division but fails for logical division:
L 0,=X'80000001' Set GR1 to -2**31+1
SRDA 0,32 Extend to 64 bits in (GR0,GR1)
D 0,=F'-1' Arithmetic division
The remainder is 0 and the quotient is + 231 − 1, as you would expect. For a logical division, the
dividend is (264 − 231 + 1) and the divisor is 232 − 1, which leads to a fixed-point divide interruption
because the quotient is greater than 232 − 1. As another example, consider

L 0,=F'-2' Set GR0 to X'FFFFFFFE'

SR 1,1 Set GR1 to X'00000000'
DL 0,=F'-1' Divide logically by X'FFFFFFFF'
Figure 136. Example of logical division

This time, both quotient and remainder are X'FFFFFFFE'!

As a final example:
L 0,=X'FFFFFFF8' Initialize GR0
LR 1,0 And GR1, with the same bits
DL 0,=X'FFFFFFFF' Divide by 2**32-1
The quotient is X'FFFFFFF9' and the remainder is X'FFFFFFF1'.

Exercises
18.7.1.(4) Show how you can use logical division instructions to generate the results that would
be obtained by using arithmetic division instructions with the same operands.

18.7.2.(2) By evaluating the expression quotient×divisor + remainder=dividend, show that the

results of the division in Figure 136 are valid.

18.8. How Division Is Done (*)

Division works much like multiplication, only in reverse. Instead of adding onto the high-order
half of the accumulating product, we subtract; instead of counting down in the rightmost digit
position, we count up; instead of shifting right, we shift left. As before, an example using decimal
arithmetic illustrates the process.

Since we start with a dividend and divisor and wish to find a quotient and remainder that satisfy
the equation
dividend = quotient × divisor + remainder
The dividend must be a double-length number.

Supposing again that our basic register length is three decimal digits, a requirement on the divi-
dend is clear: because (a) the quotient, to fit in a register, can be at most three digits long (that is,
not exceeding 999) and (b) the remainder must be less than the divisor, we must not have a divi-
dend larger than

280 Assembler Language Programming for IBM System z™ Servers Version 2.00
 999 × divisor + (divisor-1) = 103 × divisor - 1.

The factor of 10 3 is the base (10) raised to the power of the number of available digits (3). Since
multiplication by 10 3 in this example is equivalent to shifting left three places, the above relation
means that if the division is to produce a valid quotient, the high-order half of the dividend must
be less than the divisor. To illustrate: if the divisor is 456, then any dividend not smaller than
456000 = 10 3 × 456 would produce a 4-digit quotient; if the dividend is less than or equal to
455999 = 10 3 × 456 − 1, the quotient can be held in three digits. Note that the three high-
order digits, 455, are now less than the divisor.

Suppose we want to divide 162843 by 762. In ordinary long division, at each step we determine
how many multiples of the divisor can be subtracted from the leftmost part of the dividend, and
enter that number as the quotient digit. When the subtraction process has been completed, the
remainder, from which no further subtractions can be made, is 537, and the quotient is 213.
+ 213
762)162843
1524
1044
762
2823
2286
537

Just as a check, we find that 762×213+537=162843. Using decimal registers, the division works
like this:
162 843 High-order part of dividend less than divisor,
762 division may proceed.

1 628 430 Shift dividend left; save leftmost digit in an

- 762 “overflow digit” position.
Since dividend ≥ divisor,
0 866 431 Subtract, and count up at right end.
- 762 Dividend ≥ divisor; subtract again, count up
0 104 432 Dividend < divisor, no subtraction
1 044 320 Shift dividend left again
- 762 Dividend ≥ divisor; subtract and count up
0 282 321 Dividend < divisor; no subtraction
2 823 210 Shift left for the third and last time
- 762 Dividend ≥ divisor; subtract and count up
2 061 211 Subtract and count up by 1 at right end
- 762 Dividend ≥ divisor; subtract
1 299 212 and count up by 1
- 762 Dividend ≥ divisor; subtract and count up
537 213 Dividend now < divisor; stop.

As the successive digits of the quotient were developed, they appeared at the right end of the
double-length register, and were shifted left as the division progressed. Thus at the completion of
the division, the quotient is found in the right half of the register pair, and the remainder, from
which no further subtractions could be made, is in the left half.

As in multiplication, binary division is simplified by the fact that at most one subtraction need be
made for each quotient digit generated. To illustrate, consider an example using a five-bit divisor
and a ten-bit dividend. Let the dividend be B'00001 11011' (=59), and let the divisor be B'00110'
( = 6 ) . (Remember, the two halves of the double-length dividend are not two signed five-bit
numbers joined end to end: the leftmost bit of the right half of the dividend is not a sign bit but
an ordinary arithmetic digit.) If we make allowance for the sign bits of the quotient and
remainder, we actually need an extra shift at the beginning, to align the dividend correctly. This
leads to the following division scheme.
1. Shift the dividend left once. If the high-order (left) part of the dividend is not smaller than the
divisor, an illegal division is being attempted.

Chapter V: Basic Instructions 281

 2. Shift left one bit position. If the high-order part of the dividend is greater than or equal to the
divisor, subtract the divisor from the dividend, and insert a 1 bit in the rightmost digit posi-
tion. Otherwise, do nothing.
3. Return to step 2 until a total of 5 shifts has been done, including the shift of step 1.

We now illustrate the binary division of 59 by 6 in Figure 137, with less detail than in the multi-
plication example.

00011 10110 Shift left once and compare

(00110) Dividend < divisor, okay to continue

00111 01100 Shift left once (second shift)

00001 01101 Subtract divisor, insert 1
00010 11010 Shift left once (third shift)
Dividend < divisor; no subtraction
00101 10100 Shift left once (fourth shift)
Dividend < divisor; no subtraction
01011 01000 Shift left once (fifth and last shift)
00101 01001 Subtract divisor, insert 1.
Figure 137. Illustration of binary division

Thus the remainder B'00101' (=5) is in the left half, and the quotient B'01001' (=9) is in the
right half, as expected.

This example of binary division is meant to illustrate the general process. Many improvements
involving multiple dividend and divisor bits make division faster on modern processors than
testing single bits.

Division in System z involves a double-length register, either a pair of general registers or an

internal double-length register holding the extended single-length dividend. Since the high-order
register of the pair must be even-numbered, the quotient is found in the odd-numbered register,
and the remainder is found in the even-numbered register.

Exercises
18.8.1.(4) The results of a division operation must satisfy the relation
dividend = (quotient * divisor) + remainder.
However, this relation does not uniquely determine the quotient and remainder obtained from a
given divisor and dividend. Even requiring the magnitude of the remainder to be smaller than
the magnitude of the divisor,
|remainder| < |divisor|
does not lead to uniqueness! Consider the following choices:

1. sign(remainder) = sign(dividend) (System z)

2. remainder ≥ 0 (“modulo”)
3. − | divisor/2 | ≤ remainder < |divisor/2 | (“rounding”)

For cases (2) and (3), show how the System z rules concerning signs and magnitudes would
have to be modified.

18.8.2.(4) + Suppose n is the number of a general register. For each of these instructions, answer
the questions (1) Under what circumstances will this instruction cause an interruption? and (2)
What kind or kinds of interruption?

1. AR n,n
2. MR n,n
3. DR n,n

282 Assembler Language Programming for IBM System z™ Servers Version 2.00
18.9. Summary
Table 90 summarizes the multiply instructions we've discussed here.

Product length
32 32 + 32 64 64 + 64
Func- (bits)
tion Operand 1 length 32 32 64 64
Operand 2 length 16 32 32 32 64 64
MH MS M MSGF MSG
Arithmetic ×
MSR MR MSGFR MSGR
ML MLG
Logical ×
MLR MLGR
Table 90. Summary of multiply instructions discussed in this section

The divide instructions discussed in this section are shown in Table 91.

Dividend length (bits) 32 + 32 64 64 + 64

Divisor length 32 64 64
Function
Quotient & remainder
32 64 64 64
length
D DSG
Arithmetic ÷
DR DSGR
DL DSGF DLG
Logical ÷
DLR DSGFR DLGR
Table 91. Summary of divide instructions discussed in this section

Instructions Discussed in this Section

The instruction mnemonics and opcodes are shown in the following table:

Mnemonic Opcode Mnemonic Opcode Mnemonic Opcode

D 5D DSGFR B91D MR 1C
DL E397 DSGR B90D MS 71
DLG E387 M 5C MSG E30C
DLGR B987 MH 4C MSGF E31C
DLR B997 ML E396 MSGFR B91C
DR 1D MLG E386 MSGR B90C
DSG E30D MLGR B986 MSR B252
DSGF E31D MLR B996

The instruction opcodes and mnemonics are shown in the following table:

Chapter V: Basic Instructions 283

 Opcode Mnemonic Opcode Mnemonic Opcode Mnemonic
1C MR B90D DSGR E30D DSG
1D DR B91C MSGFR E31C MSGF
4C MH B91D DSGFR E31D DSGF
5C M B986 MLGR E386 MLG
5D D B987 DLGR E387 DLG
71 MS B996 MLR E396 ML
B252 MSR B997 DLR E397 DL
B90C MSGR E30C MSG

Terms and Definitions

arithmetic division
Division of two signed operands, generating a signed quotient and signed remainder.
arithmetic multiplication
Multiplication of two signed operands, generating a signed product.
dividend
A number to be divided by a divisor; the first operand; the numerator.
divisor
A number to be divided into the dividend; the second operand; the denominator.
logical division
Division of two unsigned operands, generating an unsigned quotient and unsigned remainder.
logical multiplication
Multiplication of two unsigned operands, generating an unsigned product.
multiplicand
In a multiplication, the number that is to be multiplied (the first operand) by another, the
multiplier (the second operand)
multiplier
See multiplicand
quotient
The primary result of a division operation.
remainder
The residual portion of a division left over when a dividend cannot be evenly divided by a
divisor. Smaller in magnitude than the divisor.

Programming Problems
Problem 18.1.(2) Write an Assembler Language program that finds the largest integer divisor x
of the integer function
f(n) = n3 - 1,
for values of n running from 2 to 8 in steps of 1, and such that “x” is less than f(n). Your
program should search for the divisor, and not compute it from the known factors of f(n).

Problem 18.2.(3) Write an Assembler Language program to compute and print the values of Xn
and the quotient and remainder of the fraction
(Xn)**2 + 10727*Xn - 14
2*Xn - 5
where Xn is given by Xn = 2**(3*n), for n = 1, 2, ..., 10.

284 Assembler Language Programming for IBM System z™ Servers Version 2.00
 Problem 18.3.(4) In the early 17th century, Mersenne conjectured that the number
M(p) = (2**p) - 1
is prime for a particular sequence of prime values of p. Though the conjecture is now known to
be false, several efficient tests for the primality of M(p) have been devised; we will use one (due
to the French mathematician Lucas) for testing a set of such “Mersenne Numbers”, as follows:

1. Compute M(p), and set S(1) (the initial term of a series) to the value 4. (Note that M(p)
can be calculated very simply by shifting.)
2. Compute the next term S(n+1) of the series as the remainder of the division of
(S(n)*S(n) − 2) by M(p).
3. Stop when S(p − 1) has been calculated, and print the values of p, M(p), and S(p − 1). If
S(p − 1) is zero, M(p) is prime.

Write a program that tests M(p) for values of p = 3, 5, 7, 11, 13, 17, 19, 23, 29, and 31.

Problem 18.4.(3) For values of the integer variable X running from 0 to 12 in steps of 1,
compute and print the quotient and remainder of the quantity
(X4 + 7X2 - 11) / (X3 - 21X2 + 131X - 231)
If you find that the denominator is zero for any value of X, print the largest negative magnitude
for both quotient and remainder (that is, the word integer with hex representation X'80000000').

Problem 18.5.(2) Write a program to compute a table of factorials. (Remember that we use the
notation N! for the factorial of N; define 0! = 1, and N! = N*(N − 1)!.) Print the values of N
and N! until N! will not fit into a word; print a value of − 1 for that factorial, and stop.

Problem 18.6.(4) Write a program to calculate the day and month of Easter for the year Y,
using these steps:118

1. Divide Y by 19; keep remainder A

2. Divide Y by 100; keep quotient B and remainder C
3. Divide B by 4; keep quotient D and remainder E
4. Divide 8B+13 by 25; keep quotient G
5. Divide 19A+B-D-G+15 by 30; keep the remainder H
6. Divide A+11H by 319; keep quotient M
7. Divide C by 4; keep quotient J and remainder K
8. Divide 2E+2J-K-H+M+32 by 7; keep remainder L
9. Divide H-M+L+90 by 25; keep quotient N
10. Divide H-M+L+N+19 by 32; keep remainder P

Then, Easter Sunday is the P-th day of the N-th month of year Y. (Note that this applies to
the Gregorian calendar, for years after 1582.)

Problem 18.7.(2) Write a program to print a hexadecimal addition table, like the one you
created in your solution to Exercise 2.2.4.

Problem 18.8.(2) Write a program to print a hexadecimal multiplication table, like the one you
created in your solution to Exercise 2.2.4.

Problem 18.9.(4) The constant “e” (2.718...) is the base of natural logarithms. Its value is
defined by
e = Sum (k=0,∞ ) (1/k!)
Evaluating e by calculating the terms of this sequence is very slow (and difficult to do with
fixed-point binary arithmetic, because the third and following terms are less than one). If you
rewrite the value as

118 From Scientific American, March 2001, page 82.

Chapter V: Basic Instructions 285

 e-2 = (1/2)*(1+(1/3)*(1+(1/4)*(1+(1/5)*(1+(1/6)*(1+...(1/k))))...)))
there's an easy way to generate successive digits:

1. Multiply the rightmost (k-th) numerator term (initially 1) by 10 and divide by k.

2. Retain the remainder as the numerator for generating the next digit.
3. Multiply the next higher-order numerator by 10, add the quotient from the previous term,
and divide by (k-1).
4. Repeat until k=2. At this point, the final quotient is a digit of e.
5. Repeat from the first step to generate successive digits of e.

As a general rule, the number of digits to be generated is the same as the number of terms you
evaluate.
Write a program to generate the first 50 fraction digits of e, and print the value of the constant.

Problem 18.10.(2) + Write a program that searches for and prints the 25 prime numbers less
than 100.

Problem 18.11.(2) Write a program that creates a base-seven multiplication table like the one
you made for Exercise 2.4.6.

286 Assembler Language Programming for IBM System z™ Servers Version 2.00
Chapter V: Basic Instructions 287
19. Logical Operations

11 9999999999
111 999999999999
1111 99 99
11 99 99
11 99 99
11 999999999999
11 999999999999
11 99
11 99
11 99 99
1111111111 999999999999
1111111111 9999999999

In this section we'll examine instructions that perform logical operations, and give examples of
their use. These operations are very different from logical (unsigned) arithmetic. Here, “logical”
is used in the sense of the symbolic logic of truth and falsehood; the operations are often called
“Boolean” operations. 119

The basic capabilities of a computer are derived from interconnections of basic circuits performing
logical functions. Some of the same logical functions are also performed by the CPU on oper-
ands in memory and in the general registers using “logical” instructions. The instructions in this
section are shown in Table 92.

Op Mnem Type Instruction Op Mnem Type Instruction

44 N RX AND (32) 14 NR RR AND Register (32)
E380 NG RXY AND (64) B980 NGR RRE AND Register (64)
46 O RX O R (32) 16 OR RR OR Register (32)
E381 OG RXY O R (64) B981 OGR RRE OR Register (64)
57 X RX Exclusive OR (32) 17 XR RR Exclusive OR Register (32)
E382 XG RXY Exclusive OR (64) B982 XGR RRE Exclusive OR Register (64)
Table 92. Logical operations involving general registers

There is no difference between operations involving 32- and 64-bit registers, so we'll describe only
the 32-bit forms. You can easily extend the 32-bit operations to their 64-bit equivalents.

119 George Boole (1815-1864) was a British mathematician and philosopher who wrote extensively on logic, especially in
his book An Investigation of the Laws of Thought (1854).

288 Assembler Language Programming for IBM System z™ Servers Version 2.00
19.1. Logical Operations
Unlike logical arithmetic, in which carries and borrows may propagate from a bit position to one
or more of its higher-order neighbors, boolean logical operations always operate on pairs of bits,
with no interactions among neighboring bits.

The three logical operations provided by System z are AND, OR, and Exclusive OR, abbreviated
“XOR”. These operations between pairs of bits produce a result depending only on the values of
the two bits participating in the operation. The effect of the three operations is given in
Figure 138. In each box, the two bits participating in the operation are given in the left column
and the top row; the result bit is at the intersection of the corresponding row and column.

┌─────┬─────┐ ┌─────┬─────┐ ┌─────┬─────┐

AND │ 0 │ 1 │ OR │ 0 │ 1 │ XOR │ 0 │ 1 │
┌─────┼─────┼─────┤ ┌─────┼─────┼─────┤ ┌─────┼─────┼─────┤
│ 0 │ 0 │ 0 │ │ 0 │ 0 │ 1 │ │ 0 │ 0 │ 1 │
├─────┼─────┼─────┤ ├─────┼─────┼─────┤ ├─────┼─────┼─────┤
│ 1 │ 0 │ 1 │ │ 1 │ 1 │ 1 │ │ 1 │ 1 │ 0 │
└─────┴─────┴─────┘ └─────┴─────┴─────┘ └─────┴─────┴─────┘
Figure 138. Logical operations AND, OR, and XOR

• In the first case, the result bit is 1 only if the first AND the second operand bits are 1.
• In the second case, the result bit is 1 if either the first OR the second operand bit is 1.
• In the last case, the result bit is 1 if either the first OR second operand bits is 1, Exclusive of
the case where both are 1 (that is, one but not both bits are 1). 120

The AND operation is often used to set bits to zero; OR is used to set them to one; and XOR is
used to change bits from zero to one and vice versa.

Sometimes the notation for logical operators is shorter, and text descriptions and formulas may
use other symbols: AND is represented by “∧” (or “×” or “.”), OR is represented by “∨” (or
“ + ”), and XOR is represented by “⊕ ”. In high-level languages, there are many different repres-
entations for each operation. We will use the more readable forms in Figure 138.

Exercises
19.1.1.(1) Taking 1 to represent true and 0 to represent false, rewrite the three diagrams in
Figure 138 as truth tables.

19.2. Register-Based Logical Instructions

In practice, the RR and RX forms of the logical operations are not used frequently. Logical oper-
ations are often used to examine and manipulate individual bits in memory, typically using the
SI-type instructions that we'll see in Section 24.

For the operations in Table 93, the CC is always set.

Operation CC setting
AND
0: all result bits are zero
OR
1: result bits are not all zero
XOR
Table 93. CC settings by logical instructions

120 The distinction between OR and XOR often causes problems in English, where the word “or” is often interpreted one
way when the other was intended. “Question: “Are you tired or hungry?” Answer: “Yes”, usually implying “both”.

Chapter V: Basic Instructions 289

 Unlike logical arithmetic, the result of each of these logical operations is obtained by matching the
corresponding bits of each operand, without interactions between neighboring bits. For example,
suppose c(GR4) = X'01234567', and c(GR9) = X'EDA96521'. Then if each of the following
instructions is executed, the final contents of GR4 will be as shown.
Operation AND OR XOR
Instruction NR 4,9 OR 4,9 XR 4,9

c(GR4) X'01234567' X'01234567' X'01234567'

c(GR9) X'EDA96521' X'EDA96521' X'EDA96521'
Result X'01214521' X'EDAB6567' X'EC8A2046'

To see in more detail how these results are obtained, examine the fourth hexadecimal digit (3 and
9) for each case:

AND OR XOR
3 0011 3 0011 3 0011
9 1001 9 1001 9 1001
1 0001 B 1011 A 1010
Figure 139. Examples of logical operations

Exercises
19.2.1.(1) The CC settings after the logical operations indicate whether or not the result is or is
not completely zero. Can you think of any reason why a CC setting to indicate a result of all
1-bits was not provided in the design of System/360?

19.3. Logical AND

The most important use of the N and NR instructions is for “masking” operations where we need
to isolate or extract portions of a word. For example, suppose we want only the third of the four
positive integers packed in the data word illustrated in Figure 115 on page 249. As we saw in
Section 17, we can extract it by shifting in an even-odd register pair:
L 0,DataWord Get data word with integers
SRL 0,6 Drop off fourth one
SRDL 0,13 Move third one into GR1
SRL 1,19 Position for storing
ST 1,Third Store
Or, we can use a only single register:
L 0,DataWord Get data word
SLL 0,13 Drop off first and second
SRL 0,19 Drop off fourth, and reposition
ST 0,Third Store

If the integers could have negative values, the SRL instructions would be replaced by SRA.

The following instruction sequences use Logical AND, and may be faster. (The bits of the four
integers are represented by “a”, “b”, “c”, and “d”, respectively.)
L 1,DataWord B'aaaaaaaaabbbbcccccccccccccdddddd'
N 1,Mask1 B'0000000000000ccccccccccccc000000'
SRL 1,6 B'0000000000000000000ccccccccccccc'
ST 1,Third Store desired third integer
- - -
Mask1 DC 0F,BL4'1111111111111000000' Mask: 13 0's 13 1's, 6 0's

290 Assembler Language Programming for IBM System z™ Servers Version 2.00
 The 0F operand in the DC statement ensures that the bit pattern at Mask1 falls on a word
boundary; type B constants have no implied alignment, and are padded on the left with zero bits.

We can do the same extraction by shifting first and then ANDing:

L 1,DataWord B'aaaaaaaaabbbbcccccccccccccdddddd'
SRL 1,6 B'000000aaaaaaaaabbbbccccccccccccc'
N 1,MASK2 B'0000000000000000000ccccccccccccc'
ST 1,Third Store Result
- - -
Mask2 DC A(X'1FFF') 13 1-bits at right end of word

Both masks have 1-bits only in positions corresponding to the bits of the third integer of the data
word (named “c”). When the N instruction is executed, all of the bit positions where a mask bit
is zero are set to zero, since a 0-bit ANDed to any other bit gives a zero result. In all of the
mask's 1-bit positions, the result is the same as the original bit from the data word, because a
1-bit ANDed to any other bit gives a result identical to the other bit, as we saw in Figure 138 on
page 289.

Exercises
19.3.1.(1) + In the second example in Section 15.2 on page 205, shifts were used to set the left-
most 7 bits of GR8 to zero. Show how to do this with a logical AND operation.

19.4. Logical OR
In Figure 115 on page 249, we wanted to insert a new value for the third integer into the proper
part of the data word. We could do this by shifting the various pieces into place:
L 0,DataWord Get 4 packed integers
SRDL 0,6 Move fourth into GR1
L 0,NewThird Get new value of third integer
SRDL 0,13 Move it in with fourth
L 0,DataWord Get integers again
SRL 0,19 Drop old third and fourth
SRDL 0,13 Move full word into GR1
ST 1,DataWord Store updated result

Using the AND and OR instructions, we can use logical operations:

L 0,DataWord Get 4 packed integers

N 0,MaskC Clear a space for third (C's)
L 1,NewThird Get new value of third integer
SLL 1,6 Shift into proper position
OR 0,1 'OR' into place in GR0
ST 0,DataWord Store new dataword
- - -
DS 0F Align
MaskC DC X'FFF8003F' 13 0-bits in third-integer position
Figure 140. Inserting a new integer value using A N D and O R

The N instruction zeros all the bit positions into which the third integer will be placed. The OR
instruction then forms the logical OR of all the bits of GR0 and GR1. Since the only bits in
GR1 that might be ones are in the 13 positions corresponding to the space provided in the word
in GR0, and because the result of ORing a zero bit to any other bit is the value of the other bit,
the effect is to insert the new value of the third integer in its proper position in GR0. This of
course assumes that the contents of NewThird is a positive integer of at most 13 significant bits; if
not, an
N 1,Mask1
instruction should be inserted before the OR instruction to ensure that no extraneous bits are
ORed into GR0.

Chapter V: Basic Instructions 291

 Exercises
19.4.1.(2) + The word at Data contains information to be shifted circularly: that is, bits shifted
off one end of the register should reappear at the other end. For example, a circular left shift of
the operand X'12345678' by 12 bit positions would produce X'45678123'. Without using a
rotating shift, write a code sequence using logical operations to shift c(Data) circularly to the
left by N places, where N is a nonnegative word integer stored at NShifts. Compare your
solution to the solution you found for Exercise 17.3.17.

19.4.2.(2) + Modify the coding of exercise 19.4.1 so that if N is negative, the shift is a circular
right shift instead. Again, don't use a rotating shift. Compare your solution to the solution
you found for Exercise 17.3.18.

19.4.3.(2) + What will happen if the instructions OR 3,3 and NR 3,3 are executed? what is the
difference between these two and LTR 3,3 ?

19.4.4.(2) Write a code sequence using logical instructions to unpack each of the four integers
illustrated in Figure 115 on page 249.

19.4.5.(2) Now that you have completed Exercise 19.4.4, rewrite your solution to Exercise
17.3.10 to pack the four integers into the word illustrated in Figure 115 on page 249, but now
use logical instructions.

19.5. Logical Exclusive OR

The X and XR instructions are used to invert bits. We saw in Figure 138 on page 289 that the
effect of XORing a 0-bit to any other bit is to leave it undisturbed, and the effect of XORing a
1-bit is to invert it from 1 to 0 or from 0 to 1. Any bit XORed with itself gives a zero bit. This
gives a simple way to set a register to zero.121
XR 1,1 Set GR1 to zero

We can rewrite Figure 140 on page 291 (in a somewhat roundabout way) to use an X instruc-
tion:

L 0,DataWord Get integers

O 0,Mask3 Set third-integer space to all 1's
X 0,Mask3 Now set them to zeros
L 1,NewThird Etc., as before
SLL 1,6 Etc.
N 1,Mask3 Make sure there are no extra bits
OR 0,1 Etc.
ST 0,DataWord Store updated result
- - -
DS 0F
Mask3 DC X'0007FFC0'
Figure 141. Data masking using Exclusive O R

The O instruction first sets all bits in the third integer's position to 1-bits, and the X instruction
then resets them all to zero. We'll see another use of this technique in Figure 143 on page 293.

As another example of the use of the Exclusive OR instruction, suppose we want to force the
integer in GR7 to be the next larger multiple of 8 if it is not already a multiple of 8. (We saw a
different way to do this in Figure 109 on page 246.) Consider the two following code segments.

121 This is a very efficient way to zero a general register, because (unlike subtracting the register's contents from itself),
the CPU need not check for a possible overflow.

292 Assembler Language Programming for IBM System z™ Servers Version 2.00
 A 7,=F'7' Force carry if any 1s in low 3 bits
N 7,=F'-8' Now, set last 3 bits to zero
Figure 142. Rounding to the next multiple of 8

That is a faster method, but space is required for the two constants. We can also use the “OR
then XOR” technique:

LH 0,=H'7' c(GR0) = 7 = alignment mask

AR 7,0 Force carry if any 1's in low 3 bits
OR 7,0 Now force those three bits to 1
XR 7,0 And now set them to zero
Figure 143. Rounding to the next multiple of 8

This method is more economical of total instruction length than those illustrated previously.

As a more detailed example, suppose we need to shift the (nonzero) integer contents of GR6 to
the left so that the most significant bit is immediately to the right of the sign bit, and store the
number of positions shifted at Norm. The most significant bit is the leftmost bit that differs from
the sign bit.
XR 8,8 Set shift count in GR8 to zero
Shift SLA 6,1 Shift left one bit position
BO Finish Branch if overflowed
AH 8,=H'1' Increment shift count
B Shift Try again
Finish SRA 6,1 Reposition
X 6,Digit Restore the lost bit
ST 8,Norm Store shift count
- - -
Norm DS F Storage space and alignment
Digit DC X'40000000' Mask bit for lost bit

We shift left until the overflow condition indicates that a bit different from the sign bit has been
shifted out of bit position 1. The following right shift moves everything back in place, but instead
of restoring the lost bit, extends the sign bit into the second bit position of R6, from which the
most significant bit was just lost. Since the sign is known to be the opposite of the lost bit, the X
operation inverts the second bit to give the correct result.

We can form the ones' complement of the number in GR7 by subtracting it from a word of all
1-bits, or by executing
X 7,=F'-1'
that does the same thing more simply. Thus, we can use the X instruction to form the two's
complement of a double-length integer, as in Figures 90 and 91 on page 226.

LM 8,9,Arg 64-bit operand in (GR8,GR9)

X 8,=F'-1' Ones' complement of high-order part
X 9,=F'-1' Ones' complement of low-order part
AL 9,=F'1' Add low-order 1-bit
BC B'1100',NoCarry Branch if no carry out
AL 8,=F'1' Add carry into high-order part
NoCarry STM 8,9,ARG Store complemented result
- - -
Arg DS 2F Double-length word integers
Figure 144. Complementing a double-length integer

This is definitely not the most efficient way to form a complement, but does show one use of
XOR.

Chapter V: Basic Instructions 293

 Exercises
19.5.1.(2) + Show by examining the possible bit patterns that the sequence of instructions given
below exchanges the contents of GR1 and GR2 without using any other register.
XR 1,2
XR 2,1
XR 1,2
Can the same be done between a register and a word in memory, using three instructions?

19.5.2.(2) What is the result of replacing the XR instructions in Exercise 19.5.1 with SR
instructions?

19.5.3.(4) Suppose you are programming on a processor that has addition and subtraction oper-
ations, a logical AND operation, but no OR or Exclusive OR. 122 By examining various bit
combinations (particularly at the left end of a register), show that you can compute the missing
logical functions from
A OR B = (A + B) - (A AND B)
X XOR B = (A OR B) - (A AND B)

19.5.4.(2) + Consider these four logical expressions:

(1) A XOR (A XOR B)
(2) A XOR (B XOR A)
(3) (A XOR B) XOR A
(4) (B XOR A) XOR A
What is the result of each operation?

19.5.5.(2) + Figure 141 on page 292 was rewritten by a student as follows:

L 0,DataWord Get old packed integers in GR0
L 1,NewThird Get new third integer in GR1
SLL 1,6 Position new value correctly
XR 1,0 XOR with old data in GR0
N 1,Mask3 Mask all but 3rd integer's GR1 bits
XR 0,1 XOR those bits back into GR0
ST 0,DataWord Store updated packed result
where Mask3 defines the same bit pattern. By suitable examples, prove that this program
segment either does or does not work.

19.5.6.(2) Rewrite Figure 142 on page 293 to use a single literal. Are any new problems
created in testing the Condition Code?

19.5.7.(2) Write a DC statement with an A-type constant to specify the mask in Figure 141 on
page 292.

19.5.8.(2) Write code sequences using logical instructions to extract the first, second, and fourth
integers packed in a word at DataWord in the format illustrated in Figure 115 on page 249, and
store the resulting values in the words at First, Second, and Fourth.

19.5.9.(3) The word at Pack contains four positive integers in the format illustrated in
Figure 115 on page 249. Write a code sequence that will retrieve and store at DataItem the
first, second, third, or fourth of the packed binary integers, depending on the value of the
halfword binary integer stored at ItemNbr, which may have value 1, 2, 3, or 4. (It may help to
use tables of masks and shift counts.)

122 This was true of some very early “Von Neumann” or “Institute-type” processors like the ILLIAC 1.

294 Assembler Language Programming for IBM System z™ Servers Version 2.00
19.6. Interesting Uses of Logical Instructions (*)
The examples of logical instructions in the previous sections show “normal” uses. You can do
some other interesting things with them; we will illustrate a few.123
1. Test a nonzero, nonnegative number to see if it's a power of 2:
Y = ((2*X)-1) AND X) XOR X
If Y is zero, X is a power of 2. (Note that if X is zero or is the maximum negative number,
Y = 0 . ) To illustrate:
L 0,=F'5' X in GR0 X'00000005'
LR 1,0 Copy X to GR1 X'00000005'
SLL 1,1 2*X X'0000000A'
S 1,=F'1' (2*X-1) X'00000009'
NR 1,0 (2*X-1) AND X X'00000001'
XR 1,0 ((2*X-1) AND X) XOR X X'00000004'
JZ PowerOf2 Branch if a power of 2
so that 5 is not a power of 2.
2. Isolate a number's rightmost 1-bit. If X is a nonzero, nonnegative number:
Y = (((X-1) XOR X)+1)/2
then Y is the rightmost 1-bit of X. To illustrate:
L 0,=F'6' X in GR0 X'00000006'
LR 1,0 Copy X to GR1 X'00000006'
S 1,=F'1' (X-1) X'00000005'
XR 1,0 (X-1) XOR X X'00000003'
A 1,=F'1' ((X-1) XOR X)+1 X'00000004'
SRL 1,1 Y=(((X-1) XOR X)+1)/2 X'00000002'
which is the rightmost bit of 6 = B'00...0110'. If X is zero or the maximum negative
number, Y will be zero.
3. Turn off the rightmost 1-bit of a positive binary number X:
Y = X AND (X-1)
To illustrate:
L 0,=F'6' X in GR0 X'00000006'
LR 1,0 Copy X to GR1 X'00000006'
S 1,=F'1' (X-1) X'00000005'
NR 1,0 (X-1) AND X X'00000004'
If this process is repeated, the number of iterations is determined by the power of two
represented by the leftmost 1-bit.
4. Right-propagate the rightmost 1-bit of a nonzero word:
Y = X OR (X-1)
To illustrate:
L 0,=F'12' X in GR0 X'0000000C'
LR 1,0 Copy X to GR1 X'0000000C'
S 1,=F'1' (X-1) X'0000000B'
OR 1,0 (X-1) OR X X'0000000F'
5. Isolate the rightmost 1-bit of a word:
Y = X AND (-X)
To illustrate:

123 Some of these examples are based on IBM Thomas J. Watson Research Center Report RC 5809 Functions
Realizable with Word-Parallel Logical and 2's-Complement Addition Instructions by Henry S. Warren, Jr.

Chapter V: Basic Instructions 295

 L 0,=F'12' X in GR0 X'0000000C'
LCR 1,0 Copy -X to GR1 X'FFFFFFF4'
NR 1,0 (-X) AND X X'00000004'
6. Turn off the rightmost contiguous string of 1-bits in a word:
Y = [(X OR (X-1)) + 1] AND X
To illustrate:
L 0,=F'23' X in GR0 X'00000017'
LR 1,0 Copy X to GR1 X'00000017'
S 1,=F'1' (X-1) X'00000016'
OR 1,0 (X-1) OR X X'00000017'
A 1,=F'1' ((X-1) OR X)+1 X'00000018'
NR 1,0 (((X-1) OR X)+1) AND X X'00000010'
and B'00..010111' becomes B'00..010000'.
7. Left-propagate the bit at position k in a word:
Y = [(X AND (2k+ 1 )) XOR 2k] − 2k
A more “natural” way to program this might be to write:
L 0,X
SLL 0,K
SRA 0,K
but that wouldn't be as interesting.
8. Test if a number is a power of 2, minus 1:
Y = (X XOR (X+1))
if Y is zero, X is of the form 2 N − 1.
To illustrate:
L 0,=F'31' X in GR0 X'0000001F'
LR 1,0 Copy X to GR1 X'0000001F'
A 1,=F'1' (X+1) X'00000020'
XR 1,0 (X+1) XOR X X'00000000'
so 31 is a power of 2 minus 1.

Exercises
19.6.1.(2) + In example 1 of this section, it is stated that if X is 0 or the maximum negative
number, Y=0. Verify this statement.

19.6.2.(3) In example 1 of this section, what result Y is obtained if X is the negative of a

number that is a power of 2?

19.6.3.(3) In example 2 of this section, what result Y is obtained if X is zero? What result is
obtained if X is a negative number?

19.6.4.(2) + In example 3 of this section, what will happen if X is a negative number?

19.6.5.(2) + In example 3 of this section, what will happen if X is zero?

19.6.6.(2) + In example 4 of this section, what will happen if X is zero? If X is negative?

19.6.7.(2) In example 5 of this section, what will happen if X is zero? If X is negative?

19.6.8.(2) + In example 6 of this section, what will happen if X is zero? If X is negative?

19.6.9.(2) Example 7 above shows how to left-propagate a bit in a general register. Suppose
there is an integer K between 1 and 31 stored in the word at KWord. Write a code sequence that

296 Assembler Language Programming for IBM System z™ Servers Version 2.00
 will left-propagate the bit in position K of the word in GR5, using the detailed formula (not the
“natural” solution).

19.6.10.(2) + Use the techique of example 3 of this section to count the number of 1-bits in the
word in GR0, and leave the result in GR2.

19.6.11.(2) In example 8 of this section, will the technique work if the value of X is unsigned?

19.6.12.(3) + It is claimed that this formula:

(NOT X) AND (X+1)
will create a mask that isolates the rightmost zero bit of X. That is, if X=7, the resulting mask
is X'00000008'. Write instructions testing a range of negative and positive values of X to vali-
date or invalidate this claim. What will be the result if X=0?

19.6.13.(3) + It is claimed that all three of these formulas:

(NOT X) AND (X-1), NOT(X OR -X), and (X AND -X)-1
will form a mask matching all trailing zero bits. That is, if X=12, the resulting mask is
X'00000003'. Write instructions testing a range of negative and positive values of X to validate
or invalidate this claim for all three formulas. What will be the result if X=0?

19.6.14.(3) + It is claimed that this formula:

X XOR (X-1)
will form a mask matching the rightmost one bit of X, and all trailing zero bits. That is, if
X=8, the resulting mask is X'0000000F'. Write instructions testing a range of negative and pos-
itive values of X to validate or invalidate this claim. What will be the result if X=0?

19.7. Summary
Table 94 gives a compact summary124 of the three logical operations:

Anything with
Operation
One Zero Itself
It remains It is changed to It remains
AND
unchanged zero unchanged
It is changed to It remains It remains
OR
one unchanged unchanged
It remains It is changed to
XOR It is inverted
unchanged zero
Table 94. Summary of the logical operations AND, OR, XOR

The instructions discussed in this section are summarized in Table 95.

Function Operand length (bits) 32 64

A N D (memory) N NG
A N D (register) NR NGR
O R (memory) O OG
O R (register) OR OGR
XOR (memory) X XG
XOR (register) XR XGR
Table 95. Logical-operation instructions discussed in this section

124 Courtesy of Michael Stack.

Chapter V: Basic Instructions 297

 Exercises
19.7.1.(4) Given the four logical operations AND, OR, XOR, and NOT, where (NOT A) is
equivalent to (1 X O R A): which of each can be expressed in terms of two of the other three?

Instructions Discussed in this Section

The instruction mnemonics and opcodes are shown in the following table:

Mnemonic Opcode Mnemonic Opcode Mnemonic Opcode

N 54 O 56 X 57
NG E380 OG E381 XG E382
NGR B980 OGR B981 XGR B982
NR 14 OR 16 XR 17

The instruction opcodes and mnemonics are shown in the following table:

Opcode Mnemonic Opcode Mnemonic Opcode Mnemonic

14 NR 56 O B982 XGR
16 OR 57 X E380 NG
17 XR B980 NGR E381 OG
54 N B981 OGR E382 XG

Terms and Definitions

AND operation
A logical (boolean) operation between two bits, whose result is 1 only if both operand bits
are 1.
OR operation
A logical (boolean) operation between two bits, whose result is 1 if either operand bit is 1.
XOR operation
A logical (boolean) operation between two bits, whose result is 1 if either operand bit is 1
while the other is zero. If the operand bits are identical, the result is zero.

Programming Problems
Problem 19.1.(4) In binary addition, the sum S of two binary digits A and B is
S = A XOR B,
and the carry bit is
c = A AND B.
Thus, to add two numbers composed of a string of binary digits, we must form the sum bit S(i)
of the appropriate digits A(i) and B(i), as well as the carry bit from the next lower-order digit
position, c(i − 1). The logical formulas for the sum and carry digits then become
S(i) = A(i) XOR B(i) XOR c(i-1)
and the new carry bit is
c(i) = (A(i) AND B(i)) OR (B(i) AND c(i-1)) OR (A(i) AND c(i-1))

298 Assembler Language Programming for IBM System z™ Servers Version 2.00
That is, c(i) is 1 if two or more of A(i), B(i), and c(i − 1) are 1.
Write a program that computes the logical sum of several pairs of words A and B by per-
forming the above operations 32 times, once on each bit position in the word in succession.
Save or calculate enough information during this process so that when the operation is com-
plete, you can store a byte at CCL whose value is the same as the CC setting that would result if
the AL or ALR instructions had been used to add the same operands. Your sample values
should generate all four possible CC values.
If you can, store at CCA a byte whose value is the same as the CC setting that would result if
the A or AR instructions had been used to add the same operands.
Thus, you should detect the presence or absence of a final carry, and whether the result is zero
or nonzero and positive or negative, by examining the bits as the operation progresses.

Problem 19.2.(3) Write a code sequence that forms the logical sum of two word operands A
and B, using the same logical formulas as in Problem 19.1. In this case, however, the oper-
ations should be performed on all 32 bits at once. (Show that there is no interference between
neighboring bit positions.) One method is to generate a word containing
S(1) = A XOR B
and a word
c(1) = A AND B.
The word S(1) contains the sum digits for the first addition, and the word c(1) contains the
carries generated in the first addition step. Shift c(1) left one bit position, and repeat the cycle
by ANDing and XORing S to c, generating a new sum S(2) and a new set of carries c(2).
Repeat the process until either c(n) is zero for some n, or 32 steps have been done. That is,
S(n+1) = S(n) XOR (2*c(n))
c(n+1) = S(n) AND (2*c(n))
Store the final sum at Sum, and set the word at CCodeL to contain the value of the Condition
Code setting as it would have been produced by the AL or ALR instructions.

Problem 19.3.(2) Modify the logical operation sequences in Problem 19.2 (or in Problem 19.1)
to perform additions or subtractions, as indicated by whether the word at SubFlag is or is not
zero. Test your program on a representative set of values for A and B.

Problem 19.4.(3) There are two parts to this problem. First, a small table of prime numbers is
computed using a method called the “Sieve of Eratosthenes”, and then the table is condensed
for printing.
To construct the table of primes, lay out in memory a table area of 400 units of any convenient
size; the choice of size is up to you. Consider them to be numbered from 1 to 400. Then,
beginning with table entry number 2, mark in some way each multiple of 2 (other than 2 itself),
up to 400. Then find the next unmarked quantity in the table (which will be 3), and mark each
multiple of that number. Then search for the next unmarked number (which will be 5), and
continue in this fashion.
Only prime numbers will remain unmarked. You need not make passes over the table marking
multiples of any number greater than 19, since the first unmarked number to be marked in this
“sieving” process will be the square of the number whose multiples are being marked.
From this table, produce a condensed version in a string of 400 bits (50 bytes) such that 1-bits
indicate that the corresponding number is unmarked (and therefore prime). Define the string in
a statement such as
PrimeBts DC XL50'00' Space for 400 bits
so that an appropriate single statement will print the entire string of 100 hexadecimal digits, that
should start with X'EA28...', representing 1, 2, 3, 5, 7, 11, 13, ....
If you wish, you may compute the final bit string directly, without having to go through the
intermediate steps of forming a byte table.

Chapter V: Basic Instructions 299

 Problem 19.5.(3) In Problem 19.4, you produced a string of bits indicating whether the number
that gave its position in the string was a prime number. Half the bits in the table are wasted,
since all even numbers except 2 cannot be prime.
Write a program that will produce a string of 200 bits (25 bytes) indicating which of the odd
numbers less than 400 are prime. That is, if the k-th bit of the string is a 1-bit, the number
2k-1 is prime. Your string of 200 bits should start with X'F6D32D...', representing 1, 3, 5, 7, 11,
13, ....
If you had a string of 230 bytes (1GB) available for storing the bits, what is the largest prime
whose primality you could indicate in that bit string?

Problem 19.6.(2) Choose an example from Section 19.6 on page 295 and write a program to
test the given formula for a range of values.

300 Assembler Language Programming for IBM System z™ Servers Version 2.00
Chapter VI: Addressing, Immediate Operands, and Loops

VV VV IIIIIIIIII
VV VV IIIIIIIIII
VV VV II
VV VV II
VV VV II
VV VV II
VV VV II
VV VV II
VV VV II
VV VV II
VVVV IIIIIIIIII
VV IIIIIIIIII

The previous chapters have described many different types of instructions. Recent additions to the
original System/360 architecture include extensions to those basic types that can make your pro-
grams more efficient, and often much easier to write.
• Section 20 describes different types of address generation and the important concept of
addressing modes and the very useful “Load Address” instruction.
• Section 21 introduces instructions with immediate operands that operate on data in the general
registers.
• Section 22 examines old and new forms of branch instructions, some of which have immediate
operands. These instructions help manage loops efficiently for iterative processing.

Chapter VI: Addressing, Immediate Operands, and Loops 301

20. Address Generation and Addressing Modes

2222222222 00000000
222222222222 0000000000
22 22 00 00
22 00 00
22 00 00
22 00 00
22 00 00
22 00 00
22 00 00
22 00 00
222222222222 0000000000
222222222222 00000000

20.1. Address Generation

System z provides three forms of Effective Address generation:
1. base-displacement with unsigned 12-bit displacements;
2. base-displacement with signed 20-bit displacements; and
3. relative-immediate.
The next three subsections will describe them.

20.1.1. Address Generation With 12-Bit Displacements

We saw in Sections 5.1 and 5.3 on pages 62 and 63 how Effective Addresses are generated from
instructions using base-displacement addressing: the CPU adds the displacement to the contents
of the base register (and the index register, if any is specified). Figure 19 on page 62 and
Figure 21 on page 64 illustrate the process.

In this form, 12-bit displacements are limited to the range

0 ≤ displacement ≤ + 212 − 1, or 0 ≤ displacement ≤ + 4095.

20.1.2. Address Generation With 20-Bit Displacements

In Section 14.7 we saw examples of RXY-type instructions (like LG and STG) that use a 20-bit
signed displacement. Table 96 illustrates the RXY- and RSY-type instruction formats:

opcode R1 X2 B2 DL 2 DH2 opcode

Table 96. Format of RXY- and RSY-type instructions

For RSY-type instructions the X 2 field is replaced by an R3 field, but that doesn't affect address
generation other than not supporting indexing.

302 Assembler Language Programming for IBM System z™ Servers Version 2.00
An Effective Address is generated for these “long-displacement” instructions in much the same
way it is generated for RX and similar types with an unsigned 12-bit displacement. In this case
the displacement is a signed 20-bit number; the displacement fields are rearranged and combined
as shown in Figure 145.

─ ─┬───┬───┬───────────┬────────┬─ ─
Instruction │ x │ b │ DL │s DH │
─ ─┴───┴───┴─────┬─────┴───┬────┴─ ─
 
┌─────────┼─────────┘
 
┌────────────────────────────────────────────────────┐
│──────── sign─extended ─────┼s DH │ DL │ 64─bit signed displacement
└──────────────────────────┬─────────────────────────┘
 Add to
┌──────────────────────────┴─────────────────────────┐
│ c(base register b) │
└──────────────────────────┬─────────────────────────┘

Effective Address
Figure 145. Effective Address generation for long-displacement instructions

In these instructions, the traditional 12-bit unsigned displacement field (named “D”) is now
named “DL”, and the high-order 8-bit signed displacement extension is named “DH”. A 20-bit
signed displacement is formed from DH and DL: DH is concatenated at the left end of DL, and
then sign-extended to 64 bits. This gives a displacement value in the range

− 219 ≤ displacement ≤ + 219 − 1, or − 524288 ≤ displacement ≤ + 524287.

rather than the limited 12-bit displacement range

0 ≤ displacement ≤ 4095.

If the DH field is zero, the result is generated from the familiar 12-bit unsigned displacement.

If the instruction is RXY-type, the address calculation adds both the base and index register con-
tents, if applicable.

The Assembler uses the same resolution rules described in Sections 10.9 (on page 127) and 10.13
(on page 132) with one added step:
5. If no nonnegative displacement can be assigned, choose the register giving a negative dis-
placement with the smallest magnitude.

To illustrate, suppose X has value X'2468A0'. With traditional 16-bit addressing halfwords, these
statements would fail:
Using X,3
L 9,X-4 Addressability error

The operand X-4 is not addressable, because the RX-type instruction L provides only an unsigned
12-bit displacement. The LY instruction has an extended 3-byte base-displacement, so that
Using X,3
LY 9,X-4
will resolve the implied address with an extended 3-byte base-displacement X'3 FFC FF', where
the “true” displacement from the base location in GR3 to the operand location is X'FFFFC'. That
is, B2 = 3 , D L 2 = X'FFC', and D H 2 = X'FF'.

The instructions
Using X,3
LY 9,X+4

Chapter VI: Addressing, Immediate Operands, and Loops 303

 will resolve the implied address with an extended 3-byte base-displacement X'300400', where the
traditional 16-bit addressing halfword X'3004' is in the first two bytes and DH2 = X'00'.

Long displacements provide far greater addressability than the traditional 12-bit displacements,
which are limited to 4KB.

0 ┌───────────────────────────────────┐── Base Register

4KB └───────────────────────────────────┘
Figure 146. Addressability range with 12-bit displacements

You can address very large data areas with a single base register, by setting the base address at (or
near) the “middle” of the area, as shown in Figure 147.

 ┌───────────────────────────────────┐ −512K
│ ├───────────────────────────────────┤
│ ├───────────────────────────────────┤
│ ├───────────────────────────────────┤
│ : :
│ : :
1MB ├───────────────────────────────────┤── Base Register
│ ├───────────────────────────────────┤
│ : :
│ : :
│ ├───────────────────────────────────┤
│ ├───────────────────────────────────┤
 └───────────────────────────────────┘ +512K−1
256 × 4KB
Figure 147. Addressability range with 20-bit displacements

With 12-bit unsigned displacements, addressing 1MB could require 256 base registers.

Some RX-type and SI-type instructions have equivalent forms with long displacements. They are
shown in the following table (and some of them will be described later).

12-bit dis- 20-bit dis- 12-bit dis- 20-bit dis- 12-bit dis- 20-bit dis-
placement placement placement placement placement placement
A AY LA LAY S SY
AH AHY LD LDY SH SHY
AL ALY LE LEY SL SLY
C CY LH LHY STCM STCMY
CH CHY LM LMY STC STCY
CL CLY M MY STD STDY
CLI CLIY MH MHY STE STEY
CLM CLMY MS MSY STH STHY
CVB CVBY MVI MVIY STM STMY
CVD CVDY N NY ST STY
IC IC NI NIY TM TMY
ICM ICMY O OY X XY
L LY OI OIY XI XIY

There are many other instructions with long displacements that are not direct extensions of other
RX-type and SI-type instructions.

304 Assembler Language Programming for IBM System z™ Servers Version 2.00
 20.1.3. Address Generation With Relative-Immediate Operands
The formats of the two relative-immediate instruction types are shown in Tables 97 and 98.

Opcode R1 Op RI 2
Table 97. Format of R-I instructions with 16-bit immediate
operands

Opcode R1 Op RI 2
Table 98. Format of R-I instructions with 32-bit immediate operands

Unlike the arithmetic and logical immediate operands we'll see in Sections 21.1 through 21.3,
these RI 2 relative-immediate operands do not involve data in memory or in a general register.
Instead, they are used to form the Effective Address:
1. Sign-extend the immediate operand to 64 bits, and shift it left once, giving 2×RI 2.
2. Add the address of the current relative-immediate instruction (not the address in the IA of the
PSW); the result is the Effective Address. Thus, the Effective Address is relative to the
address of the current instruction.

This process is illustrated in Figure 148.

RI2
┌──────────────┬──────────────┐
│ Opcode, regs │sbbbbbbbbbbbbb│ RI─type instruction
└──────────────┴───────┬──────┘
┌┘ Shift left 1 bit

┌─────────────────────────────────────────────┴───────┐
│─────────── sign─extended ─────────┼sbbbbbbbbbbbbb0│ 64─bit signed offset
└──────────────────────────┬──────────────────────────┘
 Add to
┌──────────────────────────┴──────────────────────────┐
│ address of the instruction itself │ (Not the PSW's IA!)
└──────────────────────────┬──────────────────────────┘

Effective Address
Figure 148. Effective Address formation for relative-immediate instructions

In effect, you have added or subtracted the number of halfwords specified by the RI2 operand to
the address of the instruction.125 The signed RI2 value means that the Effective Address can either
precede or follow the address of the instruction. For 16-bit RI2 fields,

Instruction's address − 65536 ≤ Effective Address ≤ Instruction's address + 65534,

and for 32-bit RI2 fields,

Instruction's address − 4294967296 ≤ Effective Address ≤ Instruction's address + 4294967294.

Both these “offsets” from the instruction's address are adequate for most programs.

To resolve the implied addresses of instructions with relative addressing, the Assembler calculates
the difference between the locations of the operand and the instruction and divides the result by 2.
The target operand must

125 The RI 2 operand is doubled because the Effective Address usually forms a branch address, which must always refer
to a halfword boundary. For some other processor architectures, the Instruction Address is called the “Program
Counter”, and Effective Addresses calculated relative to the address of the instruction are then called “PC-relative”.

Chapter VI: Addressing, Immediate Operands, and Loops 305

 • be aligned on a halfword boundary, and
• have the same relocation attribute as the instruction. (This rule can be relaxed if the target
operand is an external symbol, as we'll see in Section 38.)

For example, a “Branch Relative on Condition” instruction (we'll discuss it in Section 22.1)
might look like this:
BRC 8,Target Branch if Condition Code 0
- - -
Target L 0,NewValue
and the Assembler will calculate the correct RI2 offset from the BRC instruction to the Target
instruction.

Exercises
20.1.1.(1) The RI-type instruction at address X'174629C' generates an Effective Address. For
each of the four following RI2 operands, show the generated Effective Address. Assume the
generated address is 32 bits long.

1. −1
2. 6845
3. − 65536
4. 2

20.1.2.(1) The RIL-type instruction at address X'7B1EF0' generates an Effective Address. For
each of the following RI2 operands, show the generated Effective Address. Assume the gener-
ated address is 32 bits long.

1. −1
2. 384593
3. − 512044
4. 3

20.1.3.(2) Suppose c(GR4)=X'FFFFFF7C' and c(GR7)=X'9610B6C0'. Show the Effective

Address generated by each of these instructions. Assume the generated address is 32 bits long.

1. L 0,0(4,7)
2. L 0,3624(4,7)
3. LG 0,4(4,7)
4. LG 0,-8194(4,7)

20.1.4.(1) In Figure 148 on page 305, there is a comment saying “(Not the PSW's IA!)”. Why?

20.1.5.(1) Relative address offsets can be either 2 or 4 bytes long. What is the maximum
allowed distance to an operand from a referencing instruction with (a) a 2-byte offset, (b) a
4-byte offset?

20.1.6.(1) Suppose a relative-immediate instruction is at address X'27B9AE'. For each of the fol-
lowing four 2-byte immediate operands, what is the Effective Address of the instruction?

(1) X'0003'
(2) X'FFE4'
(3) X'700F'
(4) X'8000'

20.1.7.(2) How can you generate an odd Effective Address using relative-immediate operands?

20.1.8.(1) Some coders refer to operands like “A+8” and “*+6” as “relative addressing”. How
would you describe such operands?

306 Assembler Language Programming for IBM System z™ Servers Version 2.00
20.2. Addressing Modes
We've seen how an Effective Address is generated; what happens when we use it? The answer
depends on the CPU's current addressing mode, often abbreviated “AMode”. All the instructions
we've discussed have ignored AMode considerations; we now consider some basic aspects of this
important topic.

System z supports three addressing modes: 24-bit, 31-bit, and 64-bit. 24-bit addressing was used
in the original System/360, when memory was very expensive: a large processor may have had as
much as 256K bytes of storage, and many had far less.126 24-bit addresses could reference up to
224 (16 million) bytes, which seemed so large that 24-bit Effective Addresses were expected to be
enough for a very long time. Continued application growth was managed by adding virtual
addressing facilities in the early 1970s, but addresses were still limited to 24 bits.127

In the late 1970s and early 1980s, rapid application growth required more addressability; 31-bit
addressing was introduced, which provided addressability up to 2G bytes. Because existing appli-
cations usually needed to continue executing using 24-bit addressing, great care was taken to
ensure that addressing extensions were compatible with older applications.

The growth demands on applications and operating systems continued. Techniques like parti-
tioning 128 allowed some relief, but it was soon clear that more than 31-bit addressing was needed,
at least to manage physical memories much larger than 2G. Thus, in the early 2000s, 64-bit
addressing and 64-bit general registers were introduced with z/Architecture.

When 31-bit addressing was introduced, it was necessary to distinguish areas of memory address-
able with 24-bit Effective Addresses — that is, addresses between 0 and 224 − 1 — from addresses
requiring 31-bit Effective Addresses. The separation between these areas was called the “line”, so
that the first 224 bytes were “below the line” and the rest were “above the line”. Similarly, when
64-bit Effective Addresses were provided with System z, the separation of areas having addresses
less than 231 and those having larger addresses was called the “bar”, so that bytes having addresses
between 0 and 231 − 1 were “below the bar” and those with greater addresses were “above the
bar”.

Each of the three addressing modes affects the generation of z/Architecture Effective Addresses:
• in 24-bit mode, the leftmost 40 bits of the Effective Address (0-39) are set to zero, leaving the
rightmost 24 bits intact.

0 39 40 63
┌────────────────────────────────────────────────────┬─────────────────────────────────┐
│ ── 00000 .... 00000 ── │ │
└────────────────────────────────────────────────────┴─────────────────────────────────┘
────────────── ignored ─────────────────────────── ──────── 24─bit address ───────

• in 31-bit mode, the leftmost 33 bits of the Effective Address (0-32) are set to zero, leaving the
rightmost 31 bits intact.

0 33 63
┌───────────────────────────────────────────┬──────────────────────────────────────────┐
│ ── 00000 ..... 00000 ── │ │
└───────────────────────────────────────────┴──────────────────────────────────────────┘
────────────── ignored ────────────────── ──────────── 31─bit address ────────────

126 Some of the most popular System/360 models had only 32K bytes of storage, of which 14K was needed for the
operating system, leaving 18K bytes for applications. Programs were written very carefully, and often in Assembler
Language!
127 Another memory-saving technique was overlay, which we'll describe briefly in Section 38.9.
128 Partitioning uses address translation to allow more than one operating system to run in a single physical memory,
each behaving as if its set of “real” addresses starts at zero.

Chapter VI: Addressing, Immediate Operands, and Loops 307

 • in 64-bit mode, all 64 bits form the Effective Address.

0 63
┌──────────────────────────────────────────────────────────────────────────────────────┐
│ │
└──────────────────────────────────────────────────────────────────────────────────────┘
───────────────────────────────────64─bit address ──────────────────────────────────

Remember:
An Effective Address is not the same as the contents of a register, even
though it may be derived from the contents of one or more registers.

The areas of addressability for the three addressing modes are sketched in Figure 149.

2**64 ┌─────────────────────┐
│ │ 
│ │ │
│ │ │
: : │ Addressable
│ │ │ with AMODE 64
: : │
│ │ │
│ │ │
2**31 ├─────────────────────┤ │ ── the “bar”
│ │ │ 
│ │ │ │ Addressable
: : │ │ with AMODE 31
│ │ │ │
│ │ │ │
2**24 ├─────────────────────┤ │ │ ── the “line”
│ │ │ │ 
: : │ │ │ Addressable with AMODE 24
│ │   
└─────────────────────┘
Figure 149. Areas of memory addressed by three AMODEs

Instructions that place or update addresses in the general registers are called “modal” instructions,
because the result depends on the addressing mode. We'll see some examples in Section 20.3.

Effective Address addressing-mode considerations

• In 24-bit or 31-bit addressing modes, 40 or 33 high-order bits of the
64-bit Effective Address (respectively) are set to zero.
• If a value in a general register is used for addressing, its high-order bits
are not set to zero (as for generated addresses), but are ignored.

The CPU's current addressing mode is determined by two bits in the Program Status Word,
“Basic addressing mode” and “Extended addressing mode”, illustrated in Figure 150.

────────────────────────────────── 128─bit PSW ──────────────────────────────────

┌──────────────────┬─┬─┬──────────────────┬─────────────────────────────────────────┐
│ │E│B│ │ Instruction Address (IA) │
└──────────────────┴─┴─┴──────────────────┴─────────────────────────────────────────┘
0 31 32 63 64 127
Figure 150. System z PSW showing addressing-mode bits

The meanings of the E and B bit settings are shown in Table 99 on page 309.

308 Assembler Language Programming for IBM System z™ Servers Version 2.00
 E B Addressing mode
0 0 24-bit mode
0 1 31-bit mode
1 0 Invalid combination
1 1 64-bit mode
Table 99. PSW addressing-mode bits

Almost all instructions that reference operands in memory depend in some way on the current
addressing mode; and instructions that update addresses in registers also depend on the addressing
mode. These are called modal instructions. Other instructions (like AR) are called non-modal
because their results are independent of addressing modes.
In Section 38 we will see instructions used to change addressing modes, and show why attention
to addressing modes can be very important — and very useful..

Exercises
20.2.1.(1) + Suppose c(GG1)=X'00000000 82006A04' and c(GG2)=X'00000000 FFFF8200'. An
RXY-type instruction at address X'629D58' looks like this:

opcode A 2 1 X'A06' X'04' opcode

What Effective Address does it generate in 24-bit addressing mode? In 31-bit addressing mode?
In 64-bit addressing mode?

20.2.2.(2) Repeat Exercise 20.1.3, showing how the generated Effective Addresses depend on the
addressing mode.

20.3. Load Address Instructions

The name “Load Address” is misleading: the instruction loads a register (but not from memory or
another register), and its operand may or may not be an address: the Effective Address of the
second operand is loaded into the R1 register. Thus, it might more properly be named “Load
Effective Address”.

Although we normally wouldn't consider it a logical instruction, Load Address is often classified
that way. The three instructions are listed in Table 100.

Op Mnem Type Instruction Op Mnem Type Instruction

41 LA R X Load Address E371 LAY RXY Load Address
C00 LARL RIL Load Address Relative Long
Table 100. Load Address instructions

LA and LAY are RX- and RXY-type instructions, and LARL generates the Effective Address
from its address and the 32-bit RI2 operand, as described in Section 20.1.3 on page 305. In each
case, the Effective Address replaces the contents of GR R 1.

The affected parts of GR R 1 depend on the CPU's current addressing mode. As noted in Section
20.2, some of the high-order bits of the Effective Address may be set to zero.

Suppose the following LAY instruction is at address X'003B6D0E', and addressability has been
established. Then if we execute
LAY 0,-1 Put -1 in register 0 (?)
the result depends on the addressing mode:

Chapter VI: Addressing, Immediate Operands, and Loops 309

 • in 24-bit mode, the Effective Address is X'00FFFFFF', and the high-order 32 bits of GG0 are
unchanged.
• in 31-bit mode, the Effective Address is X'7FFFFFFF', and the high-order 32 bits of GG0 are
unchanged.
• in 64-bit mode, the Effective Address is X'FFFFFFFFFFFFFFFF', and the high-order 32 bits of
GG0 are changed.

Modal Instructions
LA, LAY, and LARL are modal instructions: the resulting Effective
Address depends on the addressing mode.

In any addressing mode, a nonnegative integer “n” between 0 and 4095 can be placed in a register
by executing
LA r,n(0,0)
where the displacement contains the constant “n”. Instead of writing
L 2,=F'1'
requiring 8 bytes (4 for the instruction and 4 for the constant generated by the literal), or
LH 2,=H'1'
requiring 6 bytes, we can write either
LA 2,1 or LA 2,1(0,0)
This requires only 4 bytes and less execution time, because no memory access is required.
Large signed integer values can be placed in a 64-bit register using LAY if the addressing mode is
64-bit, as shown in Figure 151.

LAY 0,500000 c(GR0) = +500000

LAY 1,-500000 c(GG1) = -500000 (64-bit mode only!)
Figure 151. Loading integer constants with the LAY instruction

You can also use values assigned to absolute symbols:

HalfMiln Equ 500000 Value = +500000
LAY 2,HalfMiln c(GR2) = +500000
LAY 2,-HalfMiln c(GG2) = -500000 (64-bit mode only!)
This can often eliminate the need for constants in memory and the storage references needed to
access them.
For signed arithmetic values, it can be safer to initialize a register with one of the arithmetic
immediate instructions described in Section 21.2 on page 321.

Be Very Careful!
The Effective Address will depend on the addressing mode! LAY 0,-1
generates X'00FFFFFF' in 24-bit addressing mode, and X'7FFFFFFF' in
31-bit mode.

For example, see Exercise 20.3.8.

Because LA and LAY do not affect the CC, we can clear a register without disturbing a CC
setting that may be required at a later point in the program. For example, suppose we wish to add
c(A) and c(B) and clear the result to zero if it overflows, without changing the CC set by the
addition. These two instruction sequences will work:

310 Assembler Language Programming for IBM System z™ Servers Version 2.00
 L 0,A L 0,A
A 0,B A 0,B
BNO ST BNO ST
LA 0,0 L 0,=F'0'
ST ST 0,Answer ST ST 0,Answer
Because the LA instruction computes an Effective Address, it also provides a simple way to incre-
ment a number in a register (other than register 0) by a small positive amount. We put the incre-
ment into the displacement, and use the same register for the R1 and B2 digits. For example,
LA 4,17(0,4)
increases the contents of GR4 by 17, if the original value in GR4 is not corrupted. For example,
in 24-bit addressing mode, c(GR4) must lie between − 17 and 224 − 18. Using LA to increment
register contents is usually limited to cases where the quantity being incremented is an address or
a reasonably small integer.

Be Careful!
Don't use a Load Address instruction to increment a negative number, or
a number large enough that the result might be affected by the current
addressing mode.

Suppose we want to perform the shifting operation described in Figures 113 and 114 on page 248,
where we wanted to shift the word at N to the right enough places so that its rightmost bit is a
1-bit. Now, however, we also require that the number of positions shifted be stored at the
halfword named Count.

L 4,N Get integer to shift

LA 3,1 Set GR3 to 1
LCR 3,3 Initial shift count set to -1
Shift SRDL 4,1 Shift a bit into GR5
LTR 5,5 Test sign of GR5
LA 3,1(0,3) Increment GR3 by 1
BNM Shift Branch if GR5 not negative
SLDL 4,1 Move bit back into place
STH 3,Count Store shift count
Figure 152. Counting number of shifts to make rightmost bit a 1-bit

By setting the shift count to − 1 initially, we guarantee that the correct value will be in GR3 when
we exit from the loop. The first time the LA instruction is executed, the result in GR3 will be
zero. The placement of the LA instruction between the LTR and the ensuing BNM shows that
no change is made to the CC; normally, we would place the LTR just before the BNM because
the relation between the two is then clearer to the program's readers.
A third use of the LA instruction, and possibly the most important, is to generate addresses for
operands in memory. For example, we may require the address of some operand to be in a given
register while executing a segment of code. Suppose we want to add three integers, and branch
after all additions are completed to NoErr if no overflow occurs, and to Err1 if one or more over-
flows occur. Let the integers to be added be stored in successive words beginning at QQ.

LA 9,NoErr Set branch address for no errors

L 2,QQ Get first integer
A 2,QQ+4 Add second integer
BNO OK1 Branch if no overflow
LA 9,Err1 Set branch address for overflow
OK1 A 2,QQ+8 Add third integer
BNOR 9 Branch if no or one overflow
B Err1 Branch, some addition overflowed
Figure 153. Using LA to set a branch address

The last unconditional branch instruction could also be written

Chapter VI: Addressing, Immediate Operands, and Loops 311

 BO Err1
without affecting the operation of the code, since that instruction is reached only if the branch
condition for the immediately preceding instruction is not met. By specifying an unconditional
branch it is clear that the branch must always be taken if it is reached.
There is an important assumption in Figure 153 on page 311 regarding the two LA instructions:
the locations named NoErr and Err1 must be addressable, since the LA instruction simply per-
forms the address computation specified by the base and displacement assigned by the Assembler.
It's sometimes easy to forget that symbols used in LA instructions must be addressable, since no
direct reference is being made to a memory location: only an Effective Address is being generated,
and no checks are made for the validity of that address.
The addressability limitations of LA can often be overcome using LAY or LARL.

Exercises
20.3.1.(1) The LARL instruction has a signed 32-bit RI2 immediate operand. Why can LARL
not be used to load the R 1 register with a large even integer value?

20.3.2.(1) If the CPU is executing in 24-bit addressing mode, show how the LA instruction can
be used as a masking instruction, producing the same result in a register as
N reg,=A(X'FFFFFF')

20.3.3.(1) + Can the first machine instruction in Figure 153 on page 311 be written
LA 9,A(NoErr) ?

20.3.4.(1) + Can the first machine instruction in Figure 153 on page 311 be written
LA 9,=A(NoErr) ?

20.3.5.(2) + The following two instructions usually have an equivalent effect:

LA 9,NoErr c(GR9) = A(NoErr)
L 9,=A(NoErr) c(GR9) = A(NoErr)
Under what circumstances would you use one in preference to the other? Under what circum-
stances would the two not be equivalent?

20.3.6.(2) + Suppose there is a number between 0 and 7 in GR5, and you want to place into
GR8 a single bit whose position within the low-order byte of that register is given by the
number in GR5. Thus, if GR5 contains X'00000006', GR8 should contain X'00000002'. A
student claimed that the following code sequence does the job; prove or disprove that claim.
LA 8,X'100'(0,5)
SRL 8,1(8)

20.3.7.(2) Discuss the differences between

LA x,number(0,x)
and AH x,=H'number'
as techniques for incrementing the contents of register GRx by a small positive integer
“number”. Under what circumstances would the result be different, and in what ways? Will it
work for all values of GRx? Which values will work, and which values won't? What differ-
ences may be required if “number” is defined by an EQU statement like this?
number EQU 29

20.3.8.(3) In Figure 151 on page 310, what will the assembled instructions look like? How will
the results depend on the current addressing mode?

20.3.9.(2) Suppose you execute these two instructions in 24-bit addressing mode:

312 Assembler Language Programming for IBM System z™ Servers Version 2.00
 L 6,=A(X'FFFFFF')
LA 6,2(,6)
What value will be in GR6?
What value will be in GR6 if the first instruction had been written
L 6,=A(X'FFFFFF00') ?

20.3.10.(2) In Figure 152 on page 311, we might want to initialize GR3 to − 1 using
LAY 3,-1
What reasons might be given for not using LAY?

20.3.11.(2) + If x and y are numbers between 1 and 15, what are the differences between
these two instructions?
LR x,y and LA x,0(0,y)

20.3.12.(3) + Suppose GR15 contains one of the values 0, 4, 8, or 12. Depending on c(GR15),
you want to branch to A, B, C, or D respectively.129 For a program with a base
register providing addressability to the code, you might write
B BList(15) Branch into table of branches
BList B A Branch if c(GR15) = 0
B B Branch if c(GR15) = 4
B C Branch if c(GR15) = 8
B D Branch if c(GR15) = 12
Suppose your program has no base register to provide addressability for the code.
How can you accomplish this task?

20.3.13.(1) Why can't use use LA or LAY to increment a small nonnegative number in GR0?

20.3.14.(2) + We are given these two definitions of the symbol Number:

1. Number DC X'1234'
2. Number DC X'ABCD'

Assuming 24-bit addressing mode: what hexadecimal value is left in GR10 by this instruction
sequence?
LH 10,Number
SLL 10,8
LA 10,0(10,0)
SRL 10,8
Now, in 31-bit addressing mode, what hexadecimal value is left in GR10 for each definition of
Number?

20.3.15.(2) + Suppose the contents of general registers 0, 1, and 2 are given by

c ( G R 0 ) = X'2112E6D8', c(GR1)=X'9B017822', and c(GR2)=X'00FFFF00'. What Effective
Address is generated in 24-bit addressing mode for each of the following addressing halfwords?

1. X'00FE'
2. X'1AF9'
3. X'2109'

Now, find the Effective Addresses generated in 31-bit addressing mode.

20.3.16.(2) + Suppose this instruction is at address X'543B6D0E':

129 This is a common convention for handling a “return code” from a called subroutine.

Chapter VI: Addressing, Immediate Operands, and Loops 313

 LAY 0,*
What Effective Address will be generated in (1) 24-bit, (2) 31-bit, and (3) 64-bit addressing
mode?

20.3.17.(3) + A programmer claims that you can test whether adding a length in GR1 to an
existing address in GR2 will cross a known power-of-two boundary with the instructions
shown below. Write a test program with various input values to test his assertion.
LAY 1,-1(1,2)
XR 1,2
N 1,Mask
JNZ Crossed Branch if adding crosses
- - -
Mask DC A(-8192) Negative of power of 2 boundary

20.4. 64-Bit Virtual Addresses

We saw in Figure 22 on page 68 how 31-bit virtual addresses are divided into shorter compo-
nents for mapping with translation tables into real addresses. The same technique is used for
64-bit virtual addresses, except that an additional 33 high-order bits must be mapped. This is illus-
trated in Figure 154.
33 11 8 12
┌───────────────────────────────────────────────────┬──────────────┬─────────┬──────────────────┐
│ region index │ segment │ page │ byte │
│ │ index │ index │ index │
└───────────────────────────────────────────────────┴──────────────┴─────────┴──────────────────┘
Figure 154. 64-bit Virtual Address

Because a 33-bit translation table would be extremely large, the region index is subdivided into
three portions, called “region first“, “region second”, and “region third” indexes, for which the
mapping tables are more manageable. This is sketched in Figure 155.
11 11 11 11 8 12
┌────────────────┬────────────────┬─────────────────┬──────────────┬─────────┬──────────────────┐
│ region 1st │ region 2nd │ region 3rd │ segment │ page │ byte │
│ index │ index │ index │ index │ index │ index │
└────────────────┴────────────────┴─────────────────┴──────────────┴─────────┴──────────────────┘
Figure 155. 64-bit Virtual Address with Region Indexes

Fortunately, these details are handled by the operating system so we can focus on our applica-
tions.

20.5. Summary
In this section, we discussed addressing modes and the three instructions shown in Table 101.

Instruc- Result in R1 general register

Function
tion AMode = 24 AMode = 31 AMode = 64
Load LA
Address LAY
Effective Address in Effective Address in
(based)
bits 40-63; bits 33-63; Effective Address in
zero in bits 32-39; zero in bit 32; bits 0-63.
Load LARL
bits 0-31 unchanged. bits 0-31 unchanged.
Address
(relative)
Table 101. Load Address instructions described in this section

314 Assembler Language Programming for IBM System z™ Servers Version 2.00
 Instructions Discussed in this Section
The instruction mnemonics and opcodes are shown in the following table:

Mnemonic Opcode Mnemonic Opcode Mnemonic Opcode

LA 41 LARL C00 LAY E371

The instruction opcodes and mnemonics are shown in the following table:

Opcode Mnemonic Opcode Mnemonic Opcode Mnemonic

41 LA C00 LARL E371 LAY

Terms and Definitions

addressing mode
One of three modes supported by System z that determines the length of an Effective
Address.
AMode
An abbreviation for “addressing mode”.
DH
In an instruction supporting 20-bit displacements, the 5th byte of the instruction containing
the signed High-order 8 bits of the displacement.
DL
In an instruction supporting 20-bit displacements, the unsigned Low-order 12 bits of the dis-
placement.
modal instruction
An instruction that places or updates addresses in the general registers, with results that
depend on the addressing mode.
relative address
An Effective Address determined by an offset relative to an instruction containing an RI 2
operand.

Chapter VI: Addressing, Immediate Operands, and Loops 315

21. Immediate Operands

2222222222 11
222222222222 111
22 22 1111
22 11
22 11
22 11
22 11
22 11
22 11
22 11
222222222222 1111111111
222222222222 1111111111

In Section 4.2 on page 51 we saw the five basic instruction classes introduced with System/360.
The only class with immediate data was the SI-type instructions, where a byte of data in the
instruction operated on, or was stored into, a byte in memory, as sketched in Figure 14 on
page 52. We'll learn more about those in Section 23.

Many new instructions include “immediate’ data that is part of the instruction, rather than being
in memory. Thus, it is “immediately” available. Most immediate operands work with data in the
general registers, rather than memory: Figure 156 shows how immediate operands in RI- and
RIL-type instructions interact with data in registers. 130 You may want to compare it to Figure 14
on page 52.

┌─────────────────────────────┐
│ Registers │
└─┬───────┬──────────┬──────┬─┘
 └────────┘ 
RI,│ RR │
RIL│ │
┌───────────────┴───┐ │RX,
│ Instruction │ │RS
└───────────────┬───┘ │
SI│ SS │
 ┌────────┐ 
┌─┴───────┴──────────┴──────┴─┐
│ Memory │
└─────────────────────────────┘
Figure 156. Instruction classes, including RI, RIL

In early processors, the relative speeds of memory accesses and instruction execution using
memory operands were nearly the same. As processor speeds have increased, instructions can
often be completed in much less time than it takes to access memory operands. As this speed
difference has grown, the relative cost of memory accesses has also grown, despite many methods

130 Because z/Architecture continues to evolve, you should check the z/Architecture Principles of Operation regularly;
some newer instructions operate on immediate data in the instruction and data in memory.

316 Assembler Language Programming for IBM System z™ Servers Version 2.00
 providing intermediate stages of “buffering”, using special internal cache memories. Caches can
help reduce, but not eliminate, the speed difference.

Because memory accesses in many applications refer to constant data, instructions containing
these constants provide immediate access to the data without additional memory references. The
resulting improvements in application performance have shown the value of these relative-
immediate instructions.

Two immediate-operand lengths are supported. In RI-type instructions, the I2 immediate

operand occupies a halfword, the last 16 bits of the 32-bit instruction.

opcode R1 Op I2
Table 102. RI-type instruction

In RIL-type instructions, the immediate operand I 2 occupies a word, the last 32 bits of the 48-bit
instruction.

opcode R1 Op I2
Table 103. RIL-type instruction

Several of the instructions we'll examine use the last two letters of the instruction mnemonic to
indicate a specific portion of the R1 register, with combinations of “H” and “L”. The first letter
refers to the High half of a 64-bit register or the Low half of the register. Similarly, the second
letter refers to the High halfword or the Low halfword of the half of the register specified by the
first letter.131 This is illustrated in Figure 157.

───────── High Half ───────── ────────── Low Half ─────────

High High High Low Low High Low Low
┌───────────────┬───────────────┬───────────────┬───────────────┐ 64─bit
│ HH │ HL │ LH │ LL │ operand
└───────────────┴───────────────┴───────────────┴───────────────┘ register
0 15 16 31 32 47 48 63
Figure 157. Four halfwords in a 64-bit general register

Another way of describing this:

HH High Half's High Half (bits 0-15)
HL High Half's Low Half (bits 16-31)
LH Low Half's High Half (bits 32-47)
LL Low Half's Low Half (bits 48-63)

Other instructions with 32-bit immediate operands end in the letters “H” or “L” meaning the H
or Low half of the register, followed by “F” to indicate that the immediate operand is a fullword.

We'll now investigate these instructions in three groupings: insert and load, arithmetic, and
logical.

131 See the comments at the start of Section 14, on page 178.

Chapter VI: Addressing, Immediate Operands, and Loops 317

21.1. Insert and Load Instructions with Immediate Operands
21.1.1. Logical-Immediate Insert Instructions
The insert group of logical-immediate instructions is summarized in Table 104.

Op Mnem Type Instruction Op Mnem Type Instruction

C08 IIHF RIL Insert Logical Immediate C09 IILF RIL Insert Logical Immediate
(high) (64←32) (low) (64←32)
A50 IIHH RI Insert Logical Immediate A51 IIHL RI Insert Logical Immediate
(high high) (64←16) (high low) (64←16)
A52 IILH RI Insert Logical Immediate A53 IILL RI Insert Logical Immediate
(low high) (64←16) (low low) (64←16)
Table 104. Insert-Immediate instructions

The sketch in Figure 158 shows the operation of these six instructions. For example, IIHF inserts
its 32-bit (Fullword) immediate operand into the high half of GG R 1.

───────── High Half ───────── ────────── Low Half ─────────

High High High Low Low High Low Low
┌───────────────┬───────────────┬───────────────┬───────────────┐
│ HH │ HL │ LH │ LL │
└───────────────┴───────────────┴───────────────┴───────────────┘
 └───┬───┘   └───┬───┘ 
IIHH│ │IIHF │IIHL IILH│ │IILF │IILL
│ └─────┐ └──┐ ┌──┘ ┌─────┘ │
└───────────┐ │ │ │ │ ┌────────────┘
┌───────────────┬───┴─┴────┴─────────┴────┴─┴─────┐
│ Instruction │ 16─ or 32─bit Immediate operand │
└───────────────┴─────────────────────────────────┘
Figure 158. Operation of six Insert Immediate instructions

The insert-immediate operations are similar to the capabilities of the ICM and ICMH instructions
that refer to storage operands. For example, these two instructions have the same result:
ICM 5,B'1100',=C'LH' Insert 'LH' into bits 0-15 of GR5
IILH 5,C'LH' The same with an immediate operand
except that IILH avoids a memory reference. Similarly, these two are equivalent:
ICMH 3,B'1111',=F'-3' Insert -3 into bits 0-31 of GG3
IIHF 3,-3 The same with an immediate operand

You can think of the IILF instruction as though it's a “Load Immediate” instruction: 132
IILF 11,123456789 has the same result as...
L 11,=F'123456789' so you could even think of it as L
*** LI 11,123456789 ...but not as LI!

These instructions let you insert 16- or 32-bit operands into any halfword or word portion of a
general register without disturbing other parts of the register.

21.1.2. Arithmetic- and Logical-Immediate Load Instructions

These instructions are listed in Table 105 on page 319.

132 But you could implement your own LI macro instruction using the macro instruction capabilities of the Assembler.

318 Assembler Language Programming for IBM System z™ Servers Version 2.00
Op Mnem Type Instruction Op Mnem Type Instruction
A78 LHI RI Load Halfword Immediate A79 LGHI RI Load Halfword Immediate
(32←16) (64←16)
C01 LGFI RIL Load Immediate (64←32)
C0E LLIHF RIL Load Logical Immediate C0F LLILF RIL Load Logical Immediate
(high) (64←32) (low) (64←32)
A5C LLIHH RI Load Logical Immediate A5D LLIHL RI Load Logical Immediate
(high high) (64←16) (high low) (64←16)
A5E LLILH RI Load Logical Immediate A5F LLILL RI Load Logical Immediate
(low high) (64←16) (low low) (64←16)
Table 105. Load and insert instructions with immediate operands

The LHI, LGHI, and LGFI instructions are arithmetic load operations, where the I2 immediate
operand is sign-extended from 16 to 32 bits or from 32 to 64 bits, as required by the R1 register
length. They operate just like the corresponding LH, LGH, and LGF instructions, except that
the second operand is found in the I2 field of the instruction rather than in memory. For
example, compare the operation of the LHI instruction in Figure 159 with the operation of LH
in Figure 62 on page 183:

┌───────────────────┬───────────────────┐
│─ sign─extended ─┼s │ GR R1
└───────────────────┴───────────────────┘
0  31
┌───────────────────┬─────────┴─────────┐
│ LHI Instruction │s │ Halfword in LHI instruction
└───────────────────┴───────────────────┘
16 31
Figure 159. Operation of L H I instruction

A valuable application of instructions like LHI involves symbolically-defined constants. Suppose

you have a table of data items, and you define a symbol NItems whose value is the number of
items:
Table DS 0F Start of table
Item1 DS CL(ItemLen) Each item has length 'ItemLen'
- - - Space for more similar items
TableEnd DS 0X End of the table
*
NItems Equ ((TableEnd-Table)/ItemLen) Number of items in table

Then, you can place the count of data items into GR8 using LHI:
LHI 8,NItems Initialize item counter

Defining symbols like NItems symbolically means that if the table expands or contracts, you need
only reassemble the program and the value of NItems will be recalculated automatically.

LGHI extends its 16-bit operand to 64 bits in GG R 1, as shown in Figure 160.

┌─────────────────────────────────────────────────────────┬───────────────────┐
│────────────────── sign─extended ──────────────────────┼s │ GG R1
└─────────────────────────────────────────────────────────┴───────────────────┘
0 48  63
┌───────────────────┬─────────┴─────────┐
│ LGHI Instruction │s │
└───────────────────┴───────────────────┘
16 31
Figure 160. Operation of L G H I instruction

Chapter VI: Addressing, Immediate Operands, and Loops 319

 Similarly, the LGFI instruction extends its 32-bit operand to 64 bits, as shown for LGF in
Figure 73 on page 195.

Suppose c(GG9)=X'12345678 00000000'; then

LHI 9,X'CBA9' Load a halfword-immediate operand
will set the rightmost 32 bits of GR9 to X'FFFFCBA9', leaving the high-order 32 bits of GG9
unchanged. Now suppose c(GG9)=X'12345678 9ABCDEF0'; the other two load-immediate
instructions give the sign-extended results shown in Figure 161:

LGHI 9,X'CBA9' c(GG9)=X'FFFFFFFF FFFFCBA9' extend 1-bit

LGFI 9,X'789ABCDE' c(GG9)=X'00000000 789ABCDE' extend 0-bit
Figure 161. Examples of load-immediate instructions

The other six logical instructions have an unusual property: the I 2 immediate operand is placed
in the proper 16 or 32 bits of the 64-bit general register, and (unlike the insert-immediate
instructions) the rest of the entire register is set to zero! The Load Logical instructions we dis-
cussed in Section 14.11 on page 195 did zero-extension only on the left, rather than also zeroing
bits to the right of the loaded operand.

The following figure pictures the operation of these six logical load instructions.

───────── High Half ───────── ────────── Low Half ─────────

High High High Low Low High Low Low
┌───────────────┬───────────────┬───────────────┬───────────────┐
│ HH │ HL │ LH │ LL │
└───────────────┴───────────────┴───────────────┴───────────────┘
 └───┬───┘   └───┬───┘ 
LLIHH│ │LLIHF │LLIHL LLILH│ │LLILF │LLILL
│ └─────┐ └──┐ ┌──┘ ┌─────┘ │
└───────────┐ │ │ │ │ ┌────────────┘
┌───────────────┬───┴─┴────┴─────────┴────┴─┴─────┐
│ Instruction │ 16─ or 32─bit Immediate operand │
└───────────────┴─────────────────────────────────┘
Figure 162. Operation of six logical load instructions

In each case, after the I2 operand has been loaded into the specified part of GG R 1, the rest of
the register is set to zero. For example, if c(GG9)=X'FEDCBA9876543210', executing each of the
following instructions will change GG9 as indicated:
LLIHF 9,X'13579BDF' c(GG9)=X'13579BDF 00000000'
LLILF 9,X'FDB97531' c(GG9)=X'00000000 FDB97531'
LLIHH 9,X'2468' c(GG9)=X'24680000 00000000'
LLIHL 9,X'2468' c(GG9)=X'00002468 00000000'
LLILH 9,X'2468' c(GG9)=X'00000000 24680000'
LLILL 9,X'2468' c(GG9)=X'00000000 00002468'

The Load Logical Immediate instructions are useful whenever you need to place a value into part
of a general register and set the rest of the register to zero, and they help you avoid unnecessary
clearing of the target register. For example, if the LLIHF instruction was not available and you
wanted to load X'13579BDF' into the high-order 32 bits of GG9 (as in the first instruction above),
you would have to do something like
L 9,=F'13579BDF' c(GR9)=X'13579BDF'
SLLG 9,9,32 c(GG9)=X'13579BDF 00000000'

requiring both a memory reference and an extra instruction. Similarly, to get the result of the
LLILH instruction above, you would have to do these two instructions
SGR 9,9 Set GG9 to zero
IILH 9,X'2468' c(GG9)=X'00000000 24680000'
which uses one of the immediate-operand instructions. Or, another use could have been

320 Assembler Language Programming for IBM System z™ Servers Version 2.00
 SGR 9,9 Set GG9 to zero
ICM 9,B'1100',=X'2468' c(GG9)=X'00000000 24680000'
again requiring an extra instruction and a memory access.

Exercises
21.1.1.(1) What will the Assembler do if you write LHI 0,76543 ? What will be placed in
GR0?

21.1.2.(1) What is the difference between an I2 operand and an RI 2 operand?

21.2. Arithmetic Instructions with Immediate Operands

The arithmetic instructions with immediate operands can be arranged in three groups:
• add and subtract instructions
• compare instructions
• multiply instructions
These instructions can be arranged into very regular patterns, like the related RX-type instructions
we saw in Section 16.

21.2.1. Arithmetic-Immediate Add and Subtract Instructions

The four arithmetic and four logical instructions in this group are shown in Table 106.

Op Mnem Type Instruction Op Mnem Type Instruction

A7A AHI RI Add Halfword Immediate A7B AGHI RIL Add Halfword Immediate
(32←16) (64←16)
C29 AFI RIL Add Immediate (32) C28 AGFI RIL Add Immediate (64←32)
C2B ALFI RIL Add Logical Immediate (32) C2A ALGFI RIL Add Logical Immediate
(64←32)
C25 SLFI RIL Subtract Logical Immediate C24 SLGFI RIL Subtract Logical Immediate
(32) (64←32)
Table 106. Arithmetic-immediate add and subtract instructions

These instructions are very useful: they can replace most memory references to constants and
literals. Consider the example in Figure 88 on page 223 where we add the first N odd numbers,
but now we use immediate values instead of literals. Three storage references have been replaced
by immediate operands in the statements marked with * in the comment field.
LHI 4,1 * c(GR4) = accumulated sum
LR 7,4 c(GR7) = count of additions
Test CH 7,NN Compare count to c(NN)
BE Store Branch if equal, N terms added
LR 0,7 Compute next odd integer
AR 0,0 Counter + counter = 2N
AHI 0,1 * Add 1, giving next odd term
AR 4,0 Add term to sum
AHI 7,1 * Increment count by 1
B Test Branch back to see if finished
Store ST 4,SUM Store result

Almost every previous example using a halfword or word literal can be replaced by an immediate
operand. This saves both execution time and the bytes needed for the storage operand.

Chapter VI: Addressing, Immediate Operands, and Loops 321

 21.2.2. Arithmetic-Immediate Compare Instructions
The four arithmetic and two logical instructions in this group are shown in Table 107.

Op Mnem Type Instruction Op Mnem Type Instruction

A7E CHI RI Compare Halfword Imme- A7F CGHI RI Compare Halfword Imme-
diate (32←16) diate (64←16)
C2D CFI RIL Compare Immediate (32) C2C CGFI RIL Compare Immediate
(64←32)
C2F CLFI RIL Compare Logical Immediate C2E CLGFI RIL Compare Logical Imme-
(32) diate (64←32)
Table 107. Arithmetic-immediate compare instructions

Suppose you must examine a character in storage to see if it is a special character, or a letter or
digit, and retain the character in GR0 for further processing. (Remember that letters and digits in
the EBCDIC representation have values greater than X'80'.) You could write the test like this:
LLC 0,Char Get character, clear rest of GR0
CHI 0,X'80' Test for special character
BNH Special Special if representation <= X'80'

The LLC instruction was illustrated in Figure 75 on page 197.

It helps to remember that these compare-immediate instructions always refer to operands in regis-
ters, never in memory:
CH 2,NN Compare to halfword in memory...
* CHI 2,NN ... but this would fail if assembled
- - -
NN DC H'42'

21.2.3. Arithmetic-Immediate Multiply Instructions

Table 108 lists the two arithmetic multiply-immediate instructions:

Op Mnem Type Instruction Op Mnem Type Instruction

A7C MHI RI Multiply Halfword Imme- A7D M G H I RI Multiply Halfword Imme-
diate (32←16) diate (64←16)
Table 108. Arithmetic-immediate multiply instructions

There are no multiply-immediate instructions with 32-bit operands. 133 This is rarely a problem,
because you can use instructions like IILF or LGFI to put a 32-bit operand into a temporary
register. For example, if the product and operands are small enough you can use MHI:
L 1,Operand1 Get a number to be multiplied
MHI 1,36 Multiply by 36, product in GR1
and if the product and operands are larger, you can use IILF:
L 1,Operand2 Get another number to be multiplied
IILF 15,629036721 Put multiplier temporarily in GR15
MR 0,15 Form long product in (GR0,GR1)

133 At the time of this writing. But new instructions are added regularly to the System z architecture, so check the Princi-
ples of Operation.

322 Assembler Language Programming for IBM System z™ Servers Version 2.00
 Exercises
21.2.1.(1) Why is there a SLFI instruction, but no SFI instruction?

21.2.2.(2) Do Exercise 18.2.7 on page 269, using immediate-operand instructions and no literals.

21.3. Logical Operations with Immediate Operands

As we have seen, the last two letters of these instruction mnemonics refers to a word or halfword
in part of a 64-bit general register. The three logical operations are AND, OR, and XOR.

The portions of the first operand in GG R 1 not involved in the operation of these instructions is
not affected, and remain unchanged. This was shown in Figure 158 on page 318, where the
“Insert Immediate” instructions involve either 16 or 32 bits of the register, and the remaining bits
are unchanged. (The “Load Immediate” instructions do clear the remaining fields of the register!)

21.3.1. Logical-Immediate AND Instructions

The AND group of logical-immediate instructions is summarized in Table 109.

Op Mnem Type Instruction Op Mnem Type Instruction

C0A NIHF RIL AND Immediate (high) C0B NILF RIL AND Immediate (low)
(64←32) (64←32)
A54 NIHH RI AND Immediate (high high) A55 NIHL RI AND Immediate (high low)
(64←16) (64←16)
A56 NILH RI AND Immediate (low high) A57 NILL RI AND Immediate (low low)
(64←16) (64←16)
Table 109. AND-immediate instructions

The last example in Section 19.3 uses a bit mask in memory. We can improve it by using an
immediate operand in an NILL instruction.

L 1,DataWord B'aaaaaaaaabbbbcccccccccccccdddddd'
SRL 1,6 B'000000aaaaaaaaabbbbccccccccccccc'
NILL 1,X'1FFF' B'0000000000000000000ccccccccccccc'
ST 1,Third Store Result
Figure 163. Extracting an unsigned integer value using A N D Immediate

The last example in Section 19.4 uses a bit mask in memory. We can also improve it using an
NILF immediate operand:

L 0,DataWord Get 4 packed integers

NILF 0,X'FFF8003F' Clear a space for third (c's)
L 1,NewThird Get new value of third integer
SLL 1,6 Shift into proper position
OR 0,1 'OR' into place in GR0
ST 0,DataWord Store new data word
Figure 164. Inserting a new integer value using A N D Immediate

21.3.2. Logical-Immediate OR Instructions

The OR group of logical-immediate instructions is summarized in Table 110 on page 324.

Chapter VI: Addressing, Immediate Operands, and Loops 323

Op Mnem Type Instruction Op Mnem Type Instruction
C0C OIHF RIL OR Immediate (high) C0D OILF RIL OR Immediate (low)
(64←32) (64←32)
A58 OIHH RI OR Immediate (high high) A59 OIHL RI OR Immediate (high low)
(64←16) (64←16)
A5A OILH RI OR Immediate (low high) A5B OILL RI OR Immediate (low low)
(64←16) (64←16)
Table 110. OR-immediate instructions

Suppose you want to set the sign bit of GG8 to a 1-bit. You can use either of these:
OIHH 8,X'8000' Set sign bit to 1
OIHF 8,X'80000000' Set sign bit to 1
but OIHF is 6 bytes long while OIHH is only 4 bytes long.

21.3.3. Logical-Immediate XOR Instructions

The XOR group of logical-immediate instructions is summarized in Table 111.

Op Mnem Type Instruction Op Mnem Type Instruction

C06 XIHF RIL XOR Immediate (high) C07 XILF RIL XOR Immediate (low)
(64←32) (64←32)
Table 111. XOR-immediate instructions

You might wonder why there are no XIHH, XIHL, XILH, and XILL instructions, like those for
the 16-bit operands of the logical-immediate AND and OR instructions. (See Exercise 21.3.1.)

The example in Figure 141 on page 292 uses AND, OR, and XOR instructions referring to oper-
ands in memory. We can rewrite it to use immediate operands:

L 0,DataWord Get integers

OILF 0,X'0007FFC0' * Set third-integer space to all 1's
XILF 0,X'0007FFC0' * Now set them to zeros
L 1,NewThird Load new value for third integer
SLL 1,6 Move to correct position
NILF 1,X'0007FFC0' * Make sure there are no extra bits
OR 0,1 Insert the new third value
ST 0,DataWord Store updated result
Figure 165. Data masking using immediate operands

We can improve this example to reduce the possibility of typographic errors, by defining the mask
symbolically:

Int3Mask Equ X'0007FFC0' Mask for isolating the 3rd integer

L 0,DataWord Get integers
OILF 0,Int3Mask Set third-integer space to all 1's
XILF 0,Int3Mask Now set them to zeros
L 1,NewThird Load new value for third integer
SLL 1,6 Move to correct position
NILF 1,Int3Mask Make sure there are no extra bits
OR 0,1 Insert the new third value
ST 0,DataWord Store updated result
Figure 166. Data masking using a symbolically defined immediate operand

This technique is recommended whenever one value must be used in several instructions. If you
mistype the mask value, it needs correcting in only one place.

324 Assembler Language Programming for IBM System z™ Servers Version 2.00
 Exercises
21.3.1.(2) + Explain why there is actually no need for the four XOR halfword-immediate
instructions XIHH, XIHL, XILH, and XILL.

21.3.2.(2) + Show why the “Halfword” forms of the AND-immediate logical NIxx instructions
(like NILH, etc.) are unnecessary.

21.3.3.(2) + Show why the “Halfword” forms of the OR-immediate logical OIxx instructions
(like OIHL, etc.) are unnecessary.

21.3.4.(1) Use instructions with immediate operands to set the high-order byte of GR1 to zero.

21.3.5.(1) Use instructions with immediate operands to invert the sign bit of GG7.

21.3.6.(1) Use instructions with immediate operands to round c(GR2) to the next higher mul-
tiple of 16, if it is not already a multiple of 16.

21.3.7.(2) A programmer wanted to test the value of some bits in GR3, and wrote these
instructions:
NILL 3,X'00F0' Isolate the 4 interesting bits
BZ AllZeros Branch if all 4 bits were zero
CH 3,=X'0070' Check if leftmost bit is 1
BNL BitWas1 Branch if that bit was 1
- - - Test other values
What value will be in GR3 when control arrives at the instruction named BitWas1?

21.3.8.(2) + A programmer wanted to extract the six low-order bits of GR4, and considered
these three sequences of instructions:
(1) N 4,=X'0000003F'
(2) SLL 4,26
SRL 4,26
(3) SRDL 4,26
SR 4,4
SLDL 4,26
Criicize each sequence in terms of its simplicity and/or efficiency, and suggest a single instruc-
tion to use in place of each.

21.3.9.(2) + A friend of the programmer in Exercise 21.3.8 suggested using an instruction with
an immediate operand:
NILL 4,X'003F'
Is his solution acceptable? Explain why or why not.

21.4. Summary
The immediate-operand instructions described in this section can provide savings in three ways:
1. they eliminate the need to access operands from storage,
2. they save the space that those operands needed, and
3. they help eliminate the need for base registers that might have been required to address those
operands.

The load- and insert-immediate instructions are summarized in Table 112 on page 326. The
insert-immediate instructions don't affect any part of the R1 register other than the bit positions
where the immediate operand has been inserted.

Chapter VI: Addressing, Immediate Operands, and Loops 325

 Operand 1 32 bits 64 bits
Operation
Operand 2 16 bits 32 bits 16 bits 32 bits
Arithmetic Load LHI LGHI LGFI
LLIHH LLIHF
LLIHL LLILF
Logical Load
LLILH
LLILL
IIHH IIHF
IIHL IILF
Insert
IILH
IILL
Table 112. Load and insert instructions with immediate operands

The arithmetic-immediate instructions are summarized in Table 113.

Operand 1 32 bits 64 bits

Operation
Operand 2 16 bits 32 bits 16 bits 32 bits
Arithmetic Add/Subtract AHI AFI AGHI AGFI
ALFI ALGFI
Logical Add/Subtract
SLFI SLGFI
Arithmetic Compare CHI CFI CGHI CGFI
Logical Compare CLFI CLGFI
Multiply MHI MGHI
Table 113. Arithmetic instructions with immediate operands

The logical-immediate instructions are summarized in Table 114. The logical-immediate

instructions don't affect any part of the R1 register other than the bit positions where the imme-
diate operand has been ANDed, ORed, or XORed.

Operand 1 32 bits 64 bits

Operation
Operand 2 16 bits 32 bits 16 bits 32 bits
NIHH NIHF
NIHL NILF
AND
NILH
NILL
OIHH OIHF
OIHL OILF
OR
OILH
OILL
XIHF
XOR
XILF
Table 114. Logical instructions with immediate operands

Instructions Discussed in this Section

The instruction mnemonics and opcodes are shown in the following table:

326 Assembler Language Programming for IBM System z™ Servers Version 2.00
Mnemonic Opcode Mnemonic Opcode Mnemonic Opcode
AFI C29 IILF C09 NIHH A54
AGFI C28 IILH A52 NIHL A55
AGHI A7B IILL A53 NILF C0B
AHI A7A LGFI C01 NILH A56
ALFI C2B LGHI A79 NILL A57
ALGFI C2A LHI A78 OIHF C0C
CFI C2D LLIHF C0E OIHH A58
CGFI C2C LLIHH A5C OIHL A59
CGHI A7F LLIHL A5D OILF C0D
CHI A7E LLILF C0F OILH A5A
CLFI C2F LLILH A5E OILL A5B
CLGFI C2E LLILL A5F SLFI C25
IIHF C08 MGHI A7C SLGFI C24
IIHH A50 MHI A7D XIHF C06
IIHL A51 NIHF C0A XILF C07

The instruction opcodes and mnemonics are shown in the following table:

Opcode Mnemonic Opcode Mnemonic Opcode Mnemonic

A50 IIHH A5F LLILL C0B NILF
A51 IIHL A78 LHI C0C OIHF
A52 IILH A79 LGHI C0D OILF
A53 IILL A7A AHI C0E LLIHF
A54 NIHH A7B AGHI C0F LLILF
A55 NIHL A7C MGHI C24 SLGFI
A56 NILH A7D MHI C25 SLFI
A57 NILL A7E CHI C28 AGFI
A58 OIHH A7F CGHI C29 AFI
A59 OIHL C01 LGFI C2A ALGFI
A5A OILH C06 XIHF C2B ALFI
A5B OILL C07 XILF C2C CGFI
A5C LLIHH C08 IIHF C2D CFI
A5D LLIHL C09 IILF C2E CLGFI
A5E LLILH C0A NIHF C2F CLFI

In general, these immediate-operand instructions don't do anything you can't do with operands in
memory. But on modern CPUs, they will execute much faster and will help reduce the size of
your program.

Chapter VI: Addressing, Immediate Operands, and Loops 327

 Terms and Definitions
immediate operand
An operand contained in a field of the instruction itself.

Programming Problems
Problem 21.1.(2) Rewrite Problem 18.7 to generate a hexadecimal addition table, using imme-
diate operands wherever possible.

Problem 21.2.(2) Rewrite Problem 18.8 to generate a hexadecimal multiplication table, using
immediate operands wherever possible.

328 Assembler Language Programming for IBM System z™ Servers Version 2.00
22. Branches, Loops, and Indexing

2222222222 2222222222
222222222222 222222222222
22 22 22 22
22 22
22 22
22 22
22 22
22 22
22 22
22 22
222222222222 222222222222
222222222222 222222222222

Programs often process data repetitively or iteratively under the control of a counter or some
other condition. In this section we examine several instructions that simplify coding “loops”,
sequences of instructions executed repeatedly.

First, we'll describe a newer form of branch instruction, the relative-immediate branch.

22.1. Branch Relative on Condition Instructions

The conditional relative branch instructions BRC and BRCL calculate their branch address by
adding twice the immediate operand to the address of the branch instruction, as described in
Section 20.1.3 on page 305. They have the formats shown in Tables 115 and 116.

A7 M1 4 RI 2
Table 115. Format of the BRC instruction

RI-type branch instructions for which the value of the RI2 operand lies in the range
−215 ≤ RI2 ≤ 215−1, or
−32768 ≤ RI2 ≤ 32767
allow the relative offset to the branch target to lie as far as − 65536 and + 65534 bytes away.

C0 M1 4 RI 2
Table 116. Format of the BRCL instruction

For RIL-type branch instructions the value of the RI 2 operand lies in the range
−231 ≤ RI2 ≤ 231−1, or
−2147483648 ≤ RI2 ≤ 2147483647

Chapter VI: Addressing, Immediate Operands, and Loops 329

 This means the offset of the branch target can be more than 4 billion bytes away from the
RIL-type instruction, in either direction. 134

Relative branch instructions can help you reduce or even eliminate the need for base registers to
address your instructions. We will describe conditional relative branches here, and examine other
forms of relative branch shortly.

In almost every situation where you use an RX-type conditional branch (introduced in Section
15) you can replace it with a branch relative on condition instruction. For example, if you want
to branch to the instruction named Equal if c(GR3)=c(GR12), you might have written a based-
branch instruction like
CR 3,12 Compare c(GR3) to c(GR12)
BC 8,Equal Branch if they're equal
or, you could use a relative branch by writing
CR 3,12 Compare c(GR3) to c(GR12)
BRC 8,Equal Branch if they're equal

While this may seem extra effort for no obvious gain, the relative branch has one major advan-
tage: the target of any relative branch can be very distant from the branch instruction, while a
based branch target can be at most + 4094 bytes from the address of the based branch. The only
(and usually minor) disadvantage is that relative branch instructions can't be indexed.

Like the extended mnemonics shown in Table 61 on page 210, the Assembler supports a similar
set of extended mnemonics for branch relative on condition instructions, listed in Table 117.
Because the most-used forms of these extended mnemonics begin with the letter “J”, they are
often called “Jump” instructions.

RI Mnemonic RIL Mnemonic Mask Meaning

BRC JC BRCL JLC M1 Conditional Branch
BRU J BRUL JLU 15 Unconditional Branch
Branch if Not Ones (T)
BRNO JNO BRNOL JLNO 14
Branch if No Overflow (A)
BRNH JNH BRNHL JLNH 13 Branch if Not High (C)
BRNP JNP BRNPL JLNP 13 Branch if Not Plus (A)
BRNL JNL BRNLL JLNL 11 Branch if Not Low (C)
Branch if Not Minus (A)
BRNM JNM BRNML JLNM 11
Branch if Not Mixed (T)
BRE JE BREL JLE 8 Branch if Equal (C)
BRZ JZ BRZL JLZ 8 Branch if Zero(s) (A,T)
BRNZ JNZ BRNZL JLNZ 7 Branch if Not Zero (A,T)
BRNE JNE BRNEL JLNE 7 Branch if Not Equal (C)
BRL JL BRLL JLL 4 Branch if Low (C)
Branch if Minus (A)
BRM JM BRML JLM 4
Branch if Mixed (T)
BRH JH BRHL JLH 2 Branch if High (C)
BRP JP BRPL JLP 2 Branch if Plus (A)
Branch if Ones (T)
BRO JO BROL JLO 1
Branch if Overflow (A)
JNOP JLNOP 0 No Operation
Table 117. Extended branch relative on condition mnemonics and their branch mask values

134 That ought to be enough for most programs. (But that's what they said at one time about 24-bit addressing.)

330 Assembler Language Programming for IBM System z™ Servers Version 2.00
 Note:
The letter L in these mnemonics sometimes means “Long” (as in JLU)
and sometimes “Low” (as in JL).

The previous example could be rewritten as

CR 3,12 Compare c(GR3) to c(GR12)
JE Equal Branch if they're equal
and no base register is needed for the JE instruction.
The Assembler checks that the branch target is within the current control section, so that you
won't accidentally branch to an instruction that isn't part of the program containing the branch.
(Such a branch is allowed if the target is an external symbol; we'll discuss this case in Section 38.)
Using explicit offsets from the current instruction is generally a poor practice:
CR 3,12 Compare c(GR3) to c(GR12)
JE *+10 Branch 10 bytes if they're equal
This will cause maintenance problems if another instruction is added or removed between the JE
and whatever instruction is 10 bytes away. The assembler generates X'A784 0005', where the
offset value 10 has been halved at assembly time so that the Effective Address at execution time
will be correct.
An even poorer coding technique is writing the RI2 operand explicitly:
CR 3,12 Compare c(GR3) to c(GR12)
JE 10 Branch 10(?) bytes if they're equal
The Assembler will issue a warning and then generate the instruction with the explicit absolute
operand in the RI 2 field, X'A784 000A' so that the branch target is actually 20 bytes away!
Branch relative instructions can be very helpful in programs larger than 4K bytes, where using
based branch instructions may require more than one base register to provide addressability.
With relative branches, you can often reduce the number of “program base” registers (or even
eliminate them entirely), freeing registers for other more productive uses.

Exercises
22.1.1.(1) The extended mnemonic for the “Long” relative branch instructions is formed by
adding the letter L after the initial letter “J”. But the Long unconditional relative branch mne-
monic is JLU, not JL. Why?

22.1.2.(1) Can you think of situations where JNOP and JLNOP will be useful?

22.1.3.(2) + What machine instruction is generated by each of these statements?

(1) J *-10
(2) J *+2046
(3) J -40
(4) JL *+2
What will happen if the last of these is executed?

22.2. A Simple Example of a Loop

We will use variations on a simple example to illustrate some basic principles. Suppose a string —
a one-dimensional array — of 80 bytes containing character data in the EBCDIC representation
begins at Str and ends at Str+79. The character string could represent data read from an
80-character record.

Chapter VI: Addressing, Immediate Operands, and Loops 331

 We want to scan the string and replace all special (non-alphanumeric) characters by blanks. That
is, any character with EBCDIC representation less than C'a' (X'81') should be replaced by C' '
(X'40').135 Thus, letters and digits will be unchanged.
We begin with the example in Figure 167. It performs the required processing in a straightfor-
ward but perhaps clumsy way. This “problem” will be used for several more examples, so try to
understand the basic idea here.

SR 0,0 Characters are inserted into GR0

LR 1,0 Character count in GR1, initially 0
LA 2,C'a' c(GR2) = X'00000081'
LA 3,C' ' c(GR3) = X'00000040'
LA 4,Str First byte's address in GR4
GetChar IC 0,0(,4) Get a byte from the string
CR 0,2 Compare to letter 'a'
JNL Okay Branch if a letter or digit
STC 3,0(,4) Otherwise replace by a blank
Okay LA 4,1(,4) Increment character address by 1
LA 1,1(,1) Increase character count by 1
C 1,=F'80' Compare count to 80 (string length)
JL GetChar Loop if less than 80 done so far
- - -
Str DC CL80'String-to,be(Scanned+For*Special=Characters$#'
Figure 167. A simple loop to scan and replace characters

The character comparisons are made in the rightmost bytes of registers GR0 and GR2. 136 The
address of the byte being examined is in GR4, and is incremented by 1 at each step, and was
initialized to the address of the first character before entering the loop. The branch instruction at
the end of the loop must branch if the contents of GR1 is less than 80, not if it is less than or
equal to 80: otherwise, the final test would cause the byte at Str+80 to be examined and possibly
changed. The string ends at Str+79.

Exercises
22.2.1.(2) + Show the result at Str after the program segment in Figure 167 completes exe-
cution.

22.2.2.(1) Revise the program in Figure 167 to use extended relative branch mnemonics and no
literals.

22.3. Simple Tables and Array Indexing

The next version of this program uses the indexing capabilities of the IC and STC instructions. 137
Assume that the character string at Str has been defined as in Figure 167.

135 Table 13 on page 87 shows that in the EBCDIC character representation, all letters and numeric digits have
encodings greater than X'80'.
136 LA (and not LHI) was used to load GR2 and GR3 with C'a' and C' '. LA and LHI are both very fast instructions;
the CPU pays special attention to LA, because address generation is a fundamental operation. Basically, there's no
detectable difference in speed.
137 Review Sections 5.3 and 9.5 for a quick summary of indexing.

332 Assembler Language Programming for IBM System z™ Servers Version 2.00
 SR 0,0 Clear GR0 for character insertion
SR 1,1 Initialize index to 0
LA 3,C' ' c(GR3) = blank at right end
GetChar IC 0,Str(1) Get a character from string
C 0,=A(C'a') Compare to letter 'a'
JNL Okay Jump if not less than X'81'
STC 3,Str(1) Replace by a blank
Okay LA 1,1(,1) Increment index by 1
C 1,=F'80' Compare to length of string
JL GetChar Branch if not done
- - -
Figure 168. A simple loop, using indexing

The byte being examined is now addressed using GR1 as an index register. The first time the IC
instruction named GetChar is executed, the contents of GR1 is zero and the Effective Address
generated will be the address of Str. On the last execution of the IC instruction, the contents of
GR1 is 79, and the last byte of the string is inserted into GR0 for examination. Then, after the
LA instruction named Okay is executed, the contents of GR1 is 80, the branching condition for
the final JL instruction is not met, and control will pass to the following instruction.

A minor difference in this version is that the 32-bit word containing the EBCDIC representation
of the letter 'a' is now a word in memory, specified by the literal =A(C'a'), rather than in GR2 as
before.138

Figure 169 illustrates another use of indexing. Three fullword integers stored beginning at QQ are
added with tests for overflow. In this case, however, after the sum is complete, a branch to NoErr
is made if no overflows occurred, to Err1 if exactly one overflow occurred, and to Err2 if two.

SR 1,1 Set overflow count in GR1 to zero

L 0,QQ Load first integer into GR0
A 0,QQ+4 Add second integer
JNO A1 Branch if no overflow
LA 1,4(,1) Indicate one overflow
A1 A 0,QQ+8 Add third integer
JNO A2 Branch if no overflow
LA 1,4(,1) Indicate an overflow
A2 B BrTbl(1) Indexed(!) branch into branch table
BrTbl J NoErr 0-overflow branch
J Err1 1-overflow branch
J Err2 2-overflow branch
Figure 169. Indexing into a branch table

When the instruction named A2 is reached, GR1 contains the number of overflows multiplied by
four. This is used as an index in computing the Effective Address of the BC instruction at A2,
which will be BrTbl, BrTbl+4, or BrTbl+8. The appropriate branch instruction will then transfer
control to the desired location. The symbol BrTbl need not be on a fullword boundary: the index
in GR1 is incremented by 4 for each overflow to account for the length of the J instructions.

Branch tables provide a fast and efficient way to route control to different parts of a program.

Exercises
22.3.1.(2) A list of N halfword integers is stored beginning at DATA and the number N is a
halfword integer at NBR. Write a code sequence that will store at the fullwords POS, NEG, and
NZT respectively the sum of the positive terms, the sum of the negative terms, and the number
of zero terms.

138 While =F'129' and =A(X'81') would give identical results, using the fullword integer literal is a poor practice, because
your reader can't tell that the literal is intended for use in a character comparison.

Chapter VI: Addressing, Immediate Operands, and Loops 333

 22.3.2.(1) What will happen if the conditional branch instruction named A2 in Figure 169 is
changed to a relative branch instruction?

22.3.3.(2) + Revise Figure 168 on page 333 to use immediate operands to replace references to
operands in memory.

22.4. Branch on Count Instructions

The branch on count instructions are shown in Table 118. None of them changes the CC
setting.

Op Mnem Type Instruction Op Mnem Type Instruction

46 BCT R X Branch on Count (32) 06 BCTR R R Branch on Count Register
(32)
E346 BCTG RXY Branch on Count (64) B946 B C T G R R R E Branch on Count Register
(64)
A76 BRCT RI Branch Relative on Count A77 B R C T G R I Branch Relative on Count
(32) (64)
Table 118. Branch on count instructions

Like the conditional relative branches, the Assembler provides extended mnemonics for the two
branch relative on count instructions:

Instruction Extended Mnemonic

BRCT JCT
BRCTG JCTG
Table 119. Extended mnemonics for branch relative on count instructions

The Branch on Count instructions simplify counting and branching operations like those in
Figures 167 and 168 above. As with the BCR and BC instructions, the branch address is
obtained either from R 2 for BCTR and BCTRG (unless the R 2 digit is zero, in which case no
branch is ever taken); or from the Effective Address for BCT and BCTG.

The branch address is computed first. Then, the branching condition is determined by first arith-
metically reducing the contents of R1 by one, and branching only if the resulting contents of R1 is
not zero. That is, the branch does not occur only when the result is zero.

The CC is unchanged, and has no effect on the branching condition. An interruption condition is
never recognized, even if an internal fixed-point overflow occurs (that is, if the new contents of R1
“wraps around” from the largest negative number to the largest positive number).

We can rewrite our original example in Figure 167 on page 332 to use a JCT instruction, by
stepping backwards along the string of characters starting at Str+79 and ending at Str. This lets
us use the same quantity both as an index and a counter.

SR 0,0 Clear GR0

LA 1,80 Set GR1 to number of characters
LA 2,C'a' c(GR2) = letter 'a'
LA 3,C' ' c(GR3) = blank
Next IC 0,Str-1(1) Get a character
CR 2,0 Compare 'a' to character
JNH Okay Branch if 'a' is low or equal
STC 3,Str-1(1) Otherwise blank it out
Okay JCT 1,Next Count down by 1, jump if not 0
Figure 170. A backward loop to scan and replace characters

334 Assembler Language Programming for IBM System z™ Servers Version 2.00
We used the implied address Str− 1 in the second operand of the IC and STC instructions
because the possible values in GR1 now run from 80 to 1, rather than from 0 to 79 as before.
The range of values is different, but the direction of incrementation makes no difference in this
example. This can be thought of as reflecting a difference in numbering the bytes in the string: if
we number them from 0 to 79 they are addressed by writing the operand as Str(1); but if the
bytes are numbered from 1 to 80, they must be addressed by writing the operand as Str− 1(1).

On the final pass through the loop, the contents of GR1 will be 1; when the JCT instruction is
executed, the contents of GR1 is reduced to zero, the branching condition is finally not met, and
control passes to the next sequential instruction. We see an immediate gain in program efficiency
over the example in Figure 168 on page 333: if we count the instructions inside the loop, we
have reduced them from 7 to 5, and we would expect about the same reduction in processing
time.

The Branch on Count instructions are especially useful when a predetermined number of loop
iterations is needed, and no special attention must be paid to indexing quantities. The count of
loop iterations is often set at execution time rather than at assembly time.

To illustrate several uses of these instructions, consider these examples taken from previous
sections.
1. The word at Nbr contains a positive integer N; compute the sum of the cubes of the first N
integers. (See Figure 125 on page 267.)
L 4,Nbr c(GR4) = index 'K', initially N
SR 5,5 Initialize sum to zero
Next LR 1,4 c(GR1) = K
MR 0,1 K * K
MR 0,4 K cubed
AR 5,1 Add to sum
JCT 4,Next Decrease K by 1, and loop
ST 5,Sum Store sum
2. The halfword at NN contains a positive integer N; store at NSq the sum of the first N odd
integers. (See Figure 82 on page 218.)

SR 0,0 Clear sum to zero

LH 1,NN Get N from memory
Loop LA 2,0(1,1) (Count + Count) in GR2
BCTR 2,0 (2 * Count) - 1
AR 0,2 Add to sum
JCT 1,Loop Reduce count and branch
ST 0,NSq Store result
Figure 171. Calculate the sum of the first N odd integers

Because N is positive and at most 15 bits long, we can use the LA instruction to compute
(N+N) in one step, since we know the result will fit in the rightmost 24 bits of GR2 for any
addressing mode (so long as N is less than 222). The following BCTR instruction does not
branch, because the R 2 digit is zero; its only effect is to reduce the contents of GR2 by one,
as required. (The K-th odd integer is 2K − 1.)
3. Find the two's complement of the double-length integer stored in the pair of words at Arg.
(See Figure 91 on page 226.)
LM 6,7,Arg Double-length number in (GR6,GR7)
LCR 6,6 Complement high-order part
LCR 7,7 Complement low-order part
JZ XXX Branch if carry out of GR7
BCTR 6,0 Otherwise reduce c(GR6) by 1
XXX STM 6,7,Arg Store complemented result
This is identical to the example in Figure 91 on page 226 except that the BCTR instruction
replaces

Chapter VI: Addressing, Immediate Operands, and Loops 335

 SL 6,=F'1'
or
AHI 6,-1
so the CC setting may be different when the STM is executed. The BCTR instruction with
R 2=0 may be used this way anywhere in a program; it is shorter than subtracting a constant
“1” from memory, but has the possible (minor) disadvantage that the CC is not set. 139

As a further example of the BCT instruction, the program segment in Figure 172 stores the cubes
of the integers from 1 to 10 in a table of ten successive fullwords starting at the word named Cube,
but this time working backwards so the words are stored in descending order.

NCubes Equ 10 Number of table entries

LA 4,NCubes c(GR4) = number to be cubed
Mult LR 3,4 Move it to GR3
MR 2,3 Square it
MR 2,4 And cube it
LR 1,4 Set up index in RX
SLL 1,2 Multiply by 4 for word length
ST 3,Cube-4(1) Store in correct table position
JCT 4,Mult Branch back (NCubes-1) times
- - -
Cube DS (NCubes)F Space for 'NCubes' Words
Figure 172. Store the cubes of the first 10 integers

In this case we used the integer argument in GR4 to index the desired word in the table. Since the
table entries are 4-byte words, the index must be multiplied by four for each item, so we use SLL
to multiply. Because the first entry in the table corresponds to “1 cubed”, the implied address of
the ST instruction must be Cube-4 so that the address of each entry will be calculated correctly.

Exercises
22.4.1.(2) + In Figure 171 on page 335, show how you can eliminate one instruction from the
body of the loop.

22.4.2.(1) + In the BCT and BCTR instructions, what initial values of GR R 1 will cause a
fixed-point overflow when the instruction is executed?

22.4.3.(2) A string of N bytes is stored beginning at String, and N is a halfword integer stored
at NN. Store the string at Gnirts in reversed order.

22.4.4.(3) Suppose there is a nonnegative integer K whose value is stored in memory at the
word integer KK. Starting at Str is a string of bytes whose bits are a random assortment of
zeros and ones. Write a code sequence that will find the K-th one-bit in the string, and store its
bit offset in the word at BitOff. For example, if the string starts with X'C607...', then if K=1
the bit offset is 0; if K=4 the bit offset is 6; and if K=6, the bit offset is 14.

22.4.5.(2) + If b is the number of a register, what will happen if you execute these instructions?
BCT b,0(,b) or BCT b,0(b,0)

22.4.6.(3) + A list of 100 fullword integers is stored beginning at the word named IntList.
Write a code sequence that moves the integers into a list beginning at NewList, but do not
move an item if it is identical to its predecessor. Store the number of items in the new list at
NumNews. For example, if the first six values at IntList are 3, 5, 5, 5, 4, 3, then the list at
NewList would begin with 3, 5, 4, 3.

139 AHI and BCTR are both very fast, and AHI sets the condition code.

336 Assembler Language Programming for IBM System z™ Servers Version 2.00
22.4.7.(2) The following code sequence is supposed to calculate the same sum of N odd integers
as in Figure 171 on page 335. Why doesn't it? What does it calculate?
LH 7,NN
LA 1,1
XXX LA 0,1(7,7)
AR 1,0
JCT 7,XXX
ST 1,Nsq

22.4.8.(3) For the program below, determine first the machine code assembled for each of the
instruction statements. Then when (at execution time) control reaches the SVC instruction,
determine c(GR2). (Don't try to assemble and then execute the program, since the SVC will
undoubtedly do something undesirable.)
Ex22_4_8 START 0
USING *,8 Establish addressability
BASR 8,0 Set base register
LA 4,4 Initialize counter
LA 7,AA Initialize address
SR 2,2 Set sum box to zero
Loop NOPR 0 Let the CPU catch its breath
AH 2,0(,7) Add a data item to the sum
LA 7,2(0,7) Increment address by 2
BCT 4,Loop Branch back if not done
SVC 3 Do something unforgettable
AA DC H'1,2,3,4,5,6,7,8,9' Table of numbers
END Ex22_4_8

22.4.9.(4) Repeat Exercise 22.4.6, but this time the results at NewList may not contain any
duplicate items. For example, if the six initial values at IntList are 2, 3, 2, 4, 2, 3, NewList
would begin with the values 2, 3, 4.

22.4.10.(2) Write a sequence of instructions that will count the number of 1-bits in GG1 and
leave the count in GG0. The original contents of GG1 need not be preserved.

22.4.11.(2) + Repeat Exercise 17.2.6 using a BCT instruction to count the number of shifts.

22.4.12.(3) + These instructions are intended to form the sums C(J)=A(J) + B(J) for values of J
from 1 to 64. Show the generated object code, assuming that the PrintOut instruction generates
exactly 32 bytes on the first available halfword boundary.
Loc Object Code Assembler Language Statements
____ _____________ BASR 12,0
____ _____________ Using *,12
____ _____________ LA 3,64
____ _____________ LA 7,A
____ _____________ Using A,7
____ _____________ Loop L 0,A
____ _____________ A 0,B
____ _____________ ST 0,C
____ _____________ BCT 3,Loop
____ _____________ Drop 7
____ _<32 bytes>__ PrintOut *
____ _____________ A DS 64F
____ _____________ B DS 64F
____ _____________ C DS 64F

22.4.13.(2) + In Exercise 22.4.12, the instructions don't perform the expected calculation.
Explain what happens, and what needs to be fixed.

Chapter VI: Addressing, Immediate Operands, and Loops 337

 22.4.14.(3) + An exercise required writing instructions to count the number of 1-bits in GR1
and leave the count in GR0. A student wrote:
SR 0,0 Set count to zero
LA 2,32 Count 32 bits
Loop SLL 1,1 Shift a bit into sign position
LTR 1,1 Test sign bit
BZ Next Branch if sign bit is zero
LA 0,1(,0) Add 1 to count of 1-bits
Next BCT 2,Loop Repeat for all 32 bits
The instructions didn't work. Find and fix the errors.

22.4.15.(3) + Write instructions to count the number of 1-bits in GR1, leave the count in GR0,
and leave GR1 unchanged without saving and then restoring its contents.

22.4.16.(2) + State the cases in which each of the following five instruction sequences give dif-
ferent results, and explain the differences.
(1) LCR 0,0 (2) X 0,=F'-1' (3) X 0,=F'-1'
A 0,=F'1' AL 0,=F'1'

(4) BCTR 0,0 (5) S 0,=F'1'

X 0,=F'-1' X 0,=F'-1'

22.4.17.(2) + Consider these three instructions:

LCR 1,1
BCTR 1,0
LCR 1,1

1. What do these instructions do?

2. What instruction(s) do they imitate?
3. How do final Condition Code settings differ between these three instructions and the
instruction(s) they imitate? For at least these initial values in GR1:
(1) X'00000000'
(2) X'00000001'
(3) X'7FFFFFFF'
(4) X'80000000'
(5) X'FFFFFFFF'
determine the resulting c(GR1) and the CC setting from executing the three instructions,
and compare the results to what you get by executing the “imitated” instruction.

22.5. Looping in General

Most of these programming examples used loops to perform some iterative task, and the termi-
nation condition depended on a counting operation. More generally, many applications require
that
• some quantity be established as an index
• whose value is changed regularly by an increment
• and is then compared to some comparand;
• a branch may then be made depending on some condition determined by the comparison.

These four terms — index, increment, comparand, and condition — will appear in several forms
when we look at the branch on index instructions in Section 22.6.

338 Assembler Language Programming for IBM System z™ Servers Version 2.00
 The term “index” means the variable quantity that controls or determines completion of the loop;
it may or may not be related to a value used as an index in an RX-type instruction (that is, speci-
fied by an index register specification digit).

If the increment is negative it might be more appropriate to call it a decrement. Rather than using
special names to distinguish the sign of the increment, we will assume the increment can be either
positive or negative.

Loops have many forms; here are two of the most common. The loops we have seen tested for
loop completion at the end of the loop; this is called a “Do-Until” loop, because the loop is
executed until the termination condition is reached. This is illustrated in Figure 173.

┌──────────────────────┐ ┌────────┐ ┌───────────────┐ ┌────────────┐

── │ Initialize index, ├──── │ loop ├── │ add increment ├── │ compare to ├── done
│ increment, comparand │  │ body │ │ to index │ │ comparand │
└──────────────────────┘ │ └────────┘ └───────────────┘ └─────┬──────┘
└────────────────────────────────────────┘ not done
Figure 173. Sketch of a Do-Until loop

As this figure indicates, a Do-Until loop is always executed once.140

The other form is called a “Do-While” loop, because the loop is executed only while the termi-
nation condition has not been reached. This is illustrated in Figure 174.

┌──────────────────────────────────────────┐
┌──────────────────────┐  ┌────────────┐ ┌────────┐ ┌─────┴─────────┐
── │ Initialize index, ├──── │ compare to ├────── │ loop ├── │ add increment │
│ increment, comparand │ │ comparand │ not │ body │ │ to index │
└──────────────────────┘ └─────┬──────┘ done └────────┘ └───────────────┘
done └──────
Figure 174. Sketch of a Do-While loop

For the Branch on Count instructions, the four loop-control items are all implied by the instruc-
tion: the index is in register R1, the increment is − 1, the comparand is zero, and the condition for
branching is inequality. This rather limited set of possibilities may be sufficient for you to code
your loop effectively.

Note!
The terminology for Do-While and Do-Until loops can be misleading.
Such a loop is executed until the test condition becomes false, or only
while the test condition remains true.

Figure 175 on page 340 shows another method to calculate a table of the first 10 cubes. The
difference from Figure 172 on page 336 is that an address, rather than a subscripting index, is
used as the varying quantity controlling execution of the loop.

140 For many years, this was the characteristic behavior of loops in the FORTRAN programming language.

Chapter VI: Addressing, Immediate Operands, and Loops 339

 NCubes Equ 10 Number of table entries
LA 1,Cube+0*4 Address of first table entry
LA 2,Cube+(NCubes-1)*4 Address of last table entry
LA 3,1 c(GR3) = number to be cubed
Mult LR 5,3 Move multiplicand to GR5
MR 4,3 Square
MR 4,3 Cube
ST 5,0(,1) Store in table
LA 3,1(,3) Increment number to be cubed
LA 1,4(,1) Increment table address
CR 1,2 Compare to end address
JNH Mult Jump back if not past end of table
- - -
Cube DS (NCubes)F Table of resulting values
Figure 175. Store the cubes of the first 10 integers in a different way

In this case an explicit address in the ST instruction is used, rather than an implied address as in
Figure 172 on page 336. This means that the loop termination condition is determined from
address arithmetic, not from tests on any of the quantities being calculated in the loop. It's often
convenient to perform such addressing calculations explicitly, rather than rely on the Assembler to
assign all bases and displacements. The “index” of the entries in the table can be thought of as
running from 0 to (NCubes − 1)*4 = 36 in steps of 4.
We used indexing in Figures 172 and 175 to compute a table of cubes. In Figure 172 on
page 336, the “index” of the loop in GR4 is also used in GR1 to “index” the ST instruction; in
Figure 175, the “index” of the loop is the address contained in GR1, but no RX-style “indexing”
is done in any of the RX instructions.
Do-Until and Do-While loops are examples of “Structured Programming” forms, but other types
of loop structures are often used. For example, you can test for a loop-exit condition in the body
of the loop:
┌────────────────────────────────────────────────┐
┌────────────┐  ┌────────────┐ ┌────────┐ ┌────────────┐ │
── │ Initialize ├──── │ loop body, ├── │ exit ├── │ loop body, ├── ┘
└────────────┘ │ first part │ │ test │ │ remainder │
└────────────┘ └───┬────┘ └────────────┘
done └──────

Exercises
22.5.1.(2) A table of N halfword integers is stored beginning at HH, and N is a halfword integer
at NHwds. Store the integers into the table starting at RR in reverse order.

22.5.2.(2) Your solution to Exercise 22.4.9 will probably contain two loops. What are their
types?

22.5.3.(1) What type of loop is illustrated in Figure 175?

22.6. Branch on Index Instructions

Because indexed loops are a key part of many programs, System z provides the Branch on Index
High and Branch on Index Low or Equal instructions shown in Table 120 on page 341. They
can greatly simplify coding of loops.

340 Assembler Language Programming for IBM System z™ Servers Version 2.00
Op Mnem Type Instruction Op Mnem Type Instruction
86 BXH RS Branch on Index High (32) EB44 BXHG RSY Branch on Index High (64)
87 BXLE RS Branch on Low or Equal EB45 BXLEG RSY Branch on Index Low or
(32) Equal (64)
84 BRXH RSI Branch Relative on Index EC44 B R X H G RIE Branch Relative on Index
High (32) High (64)
85 BRXLE RSI Branch Relative on Low or EC45 BRXLG RIE Branch Relative on Index
Equal (32) Low or Equal (64)
Table 120. Branch on index instructions

As there are no essential differences between BXH/BXLE and BXHG/BXLEG other than using
32-bit registers for the former and 64-bit registers for the latter, our examples will use the 32-bit
forms. None of the instructions changes the CC setting.

As with Branch on Count, these instructions provide the three functions of incrementation, com-
parison, and conditional branching, but with much greater flexibility. BXH and BXLE are
RS-type instructions requiring two register specification digits R1 and R 3, as indicated in Tables
121 and 122.

opcode R1 R3 B2 D2
Table 121. RS-type BXH and BXLE instructions

BXHG and BXLEG are RSY-type instructions that also require R 1 and R 3 operands:

opcode R1 R3 B2 DL 2 DH2 opcode

Table 122. RSY-type B X H G and BXLEG instructions

The relative-immediate forms of the branch on index instructions use two different instruction
formats, RSI and RIE:

opcode R1 R3 RI 2
Table 123. RSI-type BRXH and BRXLE instructions

opcode R1 R3 RI 2 opcode
Table 124. RIE-type B R X H G and BRXLG instructions

Like the STM and LM instructions, the use of registers other than GR R 3 may be implied. First,
note that all of the loop-control quantities (index, increment, and comparand) are carried in regis-
ters. The index is always in GR R 1, and the increment is always in GR R 3. The comparand is
contained either in (GR R 3 + 1) (if R3 is even), or in GR R 3 (if R3 is odd).

Thus, if we write
BXLE 7,4,NEXT
then the index is in GR7, the increment is in GR4, and the comparand is in GR5. On the other
hand, if we write
BXLE 7,5,NEXT
the index is again in GR7, but both the increment and the comparand are in GR5. Using an
odd-numbered register for both the increment and the comparand will be discussed in Section
22.9.

We use a simple notational device to illustrate the fact that the comparand is always in an odd-
numbered register: that is, if the R3 operand is even, the comparand is in GR(R3 + 1), and if the
R 3 operand is odd, the comparand is in GR R 3. We write R3 |1 to mean that the register con-

Chapter VI: Addressing, Immediate Operands, and Loops 341

 taining the comparand is determined by ORing a low-order 1 bit into the R3 digit. Thus, GR8 |1
refers to GR9, and GR9 |1 is the same as GR9.141

The operation of Branch on Index instructions, as sketched in Figure 176, is:

1. The sum of the index and increment is computed internally, and any overflow occurring in
forming the sum is ignored.
2. The sum is then compared algebraically to the comparand. Whether or not the branching
condition is met is noted: for “Branch on Index High” this means that the sum is algebra-
ically greater than the comparand, and for “Branch on Index Low or Equal” that the sum is
algebraically less than or equal to the comparand.
3. The sum then replaces the index, and the branch is taken if the branching condition is met.

┌─────────┐ ┌─────────┐ ┌───────────┐ ┌───────────┐

┌───────┐ │ Decode: │ │ Compute │ │ Compare │ │ Is Branch │ yes
── │ Fetch ├─ │ Compute ├─ │ index + ├─ │ sum to ├─ │ condition ├────┐
└───────┘ │ branch │ │Increment│ │ Comparand │ │ met? │ │
│ address │ └─────────┘ └───────────┘ └─┬─────────┘ │
└─────────┘ no│ │
┌─────────────┐ ┌──────────────┐ │ ┌────────┐ │
│ Fetch next │ │ Sum replaces │  │ Br.Addr│ │
───┤ instruction │────┤ index │────┴──┤ to IA │─┘
└─────────────┘ └──────────────┘ └────────┘
Figure 176. Operation of BXH and BXLE instructions

The branching condition is not reflected in the CC setting: neither of the “Branch on Index”
instructions changes the CC.

Because the branch address is computed during the “Decode” portion of the instruction cycle
before incrementation takes place, the Effective Address may not be as expected if the R1 and B2
digits are the same (unless both are zero, which is very unlikely.)

It's important to note that the comparison takes place before the sum replaces the index; we will
see examples of situations where this is important. (Exercise 22.9.8 is recommended!)

Figure 177 shows another way to visualize the execution of BXH and BXLE.

┌───────────────────┐
┌── │ sum ≤ comparand ? ├───────── ┐
BXLE│ └────────┬──────────┘ no │
┌─────────┐ │ yes│ │ ┌───────┐
│ sum = │ ┌───┴─────┐  ┌─────────────┐  │ sum │
── │ index + ├── │ opcode? │ ├── │Br.addr to IA├── •── │ to ├─
│increment│ └───┬─────┘  └─────────────┘  │ index │
└─────────┘ │ yes│ │ └───────┘
BXH│ ┌────────┴──────────┐ no │
└── │ sum > comparand ? ├───────── ┘
└───────────────────┘
Figure 177. Operation of BXH and BXLE instructions

The Branch on Index instructions are powerful and useful, though they sometimes seem difficult.
Normal uses require three general registers, of which two must be an even-odd register pair.

The placement of the comparand in R 3 |1 rather than in R 3+1 (as would seem more useful and
natural) is undoubtedly due to a design requirement for the original models of System/360: it was
simpler to OR than to add a low-order one-bit to the register specification digit. Also, other

141 We are using the PL/I-language notation for the logical “OR” operation, represented by the vertical-bar character
“ |”.

342 Assembler Language Programming for IBM System z™ Servers Version 2.00
 double-length instructions such as M, D, and SLDA specify an even-numbered R1 register, and
the corresponding odd-numbered register may be “addressed” in the CPU by forcing a low-order
one-bit into the register specification digit R1.

Like the conditional relative branches, the Assembler provides extended mnemonics for the four
branch relative on index instructions:

Instruction Extended Mnemonic

BRXH JXH
BRXHG JXHG
BRXLE JXLE
BRXLG JXLEG
Table 125. Extended mnemonics for branch relative on index instructions

Exercises
22.6.1.(3) In the execution of the BXH and BXLE instructions, any overflow in forming the
sum of the index and the increment is ignored. However, the comparison of the sum and the
comparand requires an internal subtraction, in which an overflow might occur.
Make a table that includes all of the eight possible combinations of (1) BXH or BXLE, (2) sign
of result of subtraction is + or − , and (3) an internal overflow did or did not occur during the
subtraction. Determine for each of the eight combinations whether or not a branch will occur.

22.7. Examples Using BXLE

To illustrate BXH and BXLE, consider the example given in Figure 167 on page 332 in Section
22.2, where we want to replace non-alphanumeric characters by blanks. We'll rewrite the code
sequence to use a BXLE instruction.

LM 0,3,=F'0,0,1,79' Preset registers GR0-GR3

* Chars inserted in GR0, index in GR1,
* increment in GR2, comparand in GR3.
LM 4,5,=A(C'a',C' ')
* Letter 'a' in GR4, blank in GR5.
GetChar IC 0,Str(1) Get a character from the string
CR 0,4 Compare to letter 'a' in GR4
BNL Alpha Branch if alphanumeric
STC 5,Str(1) Otherwise, store a blank
Alpha BXLE 1,2,GetChar Increment, test, and branch
- - -
Figure 178. Replacing special characters with blanks, using BXLE

The values of the index run from 0 to 79; when control reaches the BXLE instruction, the incre-
ment ( + 1) in GR2 is added to c(GR1). Because GR2 is an even-numbered register, the sum is
compared to the comparand in the next higher-numbered register, GR3. If the sum is less than or
equal to 79, the branching condition is met, and control will be transferred to the instruction
named GetChar after the sum is placed back into GR1. When control finally passes to the instruc-
tion following the BXLE, c(GR1) will be 80.

To give an example where BXLE appears in a more normal context, we will rewrite Figures 172
and 175 to compute a table of the cubes of the first 10 integers, stored starting at Cube.

Chapter VI: Addressing, Immediate Operands, and Loops 343

 NCubes Equ 10 Number of table entries
LA 7,1 Initial integer = 1
SR 4,4 Set index to zero
LA 2,4 Increment of +4 for indexing
LA 3,4*(NCubes-1) Comparand (=36) in GR3
Mult LR 1,7 N in GR1
MR 0,1 N * N
MR 0,7 N cubed
ST 1,Cube(4) Store in table
AHI 7,1 Increase N by 1
BXLE 4,2,Mult Increase index by 4 and loop
- - -
Cube DS (NCubes)F Space for table of cubes
Figure 179. Creating a table of cubed integers using BXLE

This segment uses fewer instructions inside the loop, at the expense of some extra instructions
outside the loop: this is often a valuable technique, especially for loops executed many times. The
following two code segments do the same calculation, but are set up slightly differently.

NCubes Equ 10 Number of table entries

LA 7,1 Initial value of N = 1
LA 4,4 Set increment in GR4 to 4
LR 2,4 Initial index in GR2 is 4
LA 5,4*NCubes Comparand in GR5 = 40
Mult LR 1,7 c(GR1) = N
MR 0,1 N squared
MR 0,7 N cubed
ST 1,Cube-4(2) Store in table
AHI 7,1 Increment N by 1
BXLE 2,4,Mult Count and loop
Figure 180. Creating a table of cubed integers using BXLE

In this example, the index runs from 4 to 40 in steps of 4, rather than from 0 to 36 as in
Figure 179. There is no significant difference between the methods illustrated in Figures 179 and
180, except that the second can be simpler: since the integer N runs from 1 to 10 in steps of 1, the
multiplication by 4 to account for the length of the fullword result makes it natural to have the
index run from 4 to 40 in steps of 4. In Section 23 we will examine cases where such consider-
ations are important, when we access tables of data stored in array form.

Another variation of this example is given in Figure 181, where the index and comparand quanti-
ties are addresses.

NCubes Equ 10 Number of cubes

LA 4,Cube+0*4 Index set to initial table address
LA 2,4 Increment = 4 for fullwords
LA 3,Cube+(NCubes-1)*4 Comparand = final table address
LA 7,1 Initial value of N = 1
Mult LR 11,7 N
MR 10,11 N * N
MR 10,7 N * N * N
ST 11,0(,4) Store in table
AHI 7,1 Increment N by 1
BXLE 4,2,Mult Increment address by 4 and loop
Figure 181. Creating a table of cubed integers with addresses as controls

344 Assembler Language Programming for IBM System z™ Servers Version 2.00
Exercises
22.7.1.(3) + Examine these two instructions, and determine (1) whether the branch to XX will be
taken, and (2) what will be the contents of GR3 after both instructions have been executed.
LA 3,1
BXLE 3,3,XX
Then, answer the same two questions, assuming that the second instruction is BXH instead.

22.7.2.(3) + Suppose we execute the following two instructions:

LA 3,3
BXLE 3,3,*
Next - - -
What will be in GR3 when the next instruction is executed? Make the same determination for
BXH.

22.7.3.(3) A positive 64-bit dividend in registers GR6 and GR7 is divided by a positive divisor,
using the D instruction. What will happen if the instruction following the divide is
BXLE 6,7,WhatNext ?

22.7.4.(2) In Figure 178 on page 343, combine the first two instructions into a single LM that
uses a literal with an A-type constant. Then, initialize registers GR0 through GR5 using imme-
diate operands. Including space required for the constants, which code sequence is shorter?

22.7.5.(4) Suppose registers GRx and GRy (where GRy is an odd-numbered register) contain
nonnegative integers. A student claimed that we can leave in register GRx the sum of their con-
tents modulo (2 31 − 1) with the following instruction pair:
BXLE x,y,*+8 Form c(GRx)+c(GRy)
SL x,=F'2147483647' (231−1)
Verify or disprove his claim.

22.7.6.(2) The following code sequence tries to find the leftmost 1-bit of the positive nonzero
number in GR1, and put its bit number into GR0.
SR 0,0 Initialize bit position to 0
LA 2,1 Initialize BXLE increment
LA 3,32 Initialize BXLE comparand
X SLA 1,1 Shift test word left once
JM Y Check for minus sign
JXLE 0,2,X Count up by 1 and loop
Y - - - Rest of code
The program segment does not work correctly. Explain why not, and then correct it without
increasing the number of instructions.

22.7.7.(3) + By starting with a negative index value, it is possible to use a single register to hold
the increment and comparand of a BXLE instruction. Rewrite the examples in Figures 179
through 181 to use this technique.

22.7.8.(2) Repeat Exercise 22.7.1, but replace the first instruction with the following:
L 3,=F'1073741824' (230)
Now, do the same again, replacing the LA by
L 3,=F'-2147483647' (-231+1)

22.7.9.(3) + If you execute this BXLE instruction:

LM 1,3,=F'7,17,77'
BXLE 1,2,*

Chapter VI: Addressing, Immediate Operands, and Loops 345

 How many times will the BXLE instruction be executed? How many times will it branch?
What will be the sequence of values in GR1?

22.7.10.(2) + Suppose A, B, and C are three positive integers used to initialize the index, incre-
ment, and comparand registers of a BXLE instruction that controls the iterations of a loop.
How many times will the body of the loop be executed?

22.8. Examples Using BXH

To illustrate the use of the BXH instruction, Figures 179 and 181 will be rewritten so that the
indexing runs in the opposite direction. First, we calculate the table of cubes using “normal”
indexing.

LA 7,10 Initial value of N

LHI 8,-1 c(GR8) = -1 for incrementing N
LA 4,40 Initial index = 40
LHI 2,-4 Increment = -4
SR 3,3 Comparand = 0
Mult LR 1,7 N
MR 0,7 N * N
MR 0,7 N * N * N
ST 1,Cube-4(4) Store in table
AR 7,8 Add -1 to N
BXH 4,2,Mult Count and loop
Figure 182. Creating a table of cubed integers using BXH

When the instruction following the BXH is reached, the index in GR4 will be zero.

We can use the value − 4 for both the increment and the comparand and carry them in the same
register, as in Figure 183.

LA 7,10 Initial value of N is 10

LA 4,36 Initial index = 36
LHI 5,-4 Increment and comparand are -4
Mult LR 1,7 N
MR 0,7 N squared
MR 0,7 N cubed
ST 1,Cube(4) Store in table
BCTR 7,0 Decrease N by 1
BXH 4,5,Mult Count down and loop
Figure 183. Creating a table of cubed integers, using BXH in a special way

In this case the R3 digit 5 is odd, so R3 |1 is the same as R3; the BXH will increment the index in
GR4 by − 4, compare it to − 4 (the comparand, also in GR5), and branch until the resulting sum
becomes equal to − 4, when control will pass to the following instruction.

Exercises
22.8.1.(3) Suppose we execute the instructions
SRL 1,1
BXH 1,1,*-4
Describe the behavior of this code segment as it depends on the initial contents of GR1. Then
do the same, but with BXLE instead of BXH.

346 Assembler Language Programming for IBM System z™ Servers Version 2.00
22.9. Specialized Uses of BXH and BXLE (*)
Some specialized uses of BXH and BXLE involve unusual combinations of register specification
digits.
1. Suppose the contents of an odd-numbered register such as GR9 is zero. Then the instruction
XR 9,9 Set GR9 to zero
BXLE 4,9,XXX Branch to XXX if c(GR4) is <= 0
will branch to XXX only if the contents of GR4 is less than or equal to zero. Similarly,
BXH 4,9,YYY Branch to YYY if c(GR4) is > 0
would branch to YYY only if the contents of GR4 is greater than zero.
Since BXH and BXLE neither set nor test the condition code, this technique can be used in
situations where a condition code reflecting the state of the contents of GR4 is not available,
the current CC setting must be undisturbed, or if we want to avoid using instructions such as
LTR followed by a conditional branch.
2. Suppose we want to perform the inverse of the BCT instruction: that is, we want to incre-
ment the positive contents of a register by + 1, and then branch. If we set c(GR7) to + 1, and
c(GR2) is greater than zero, then
LHI 7,1 Initialize GR7 to +1
BXH 2,7,XXX Increment c(GR2), branch to XXX
will branch to XXX after incrementing c(GR2) by 1, unless the sum overflows. (There will be
no indication of the overflow in the CC setting!) Similarly, if there is a negative integer in
GR2,
BXLE 2,7,YYY Branch to YYY if c(GR2) not > +1
will increment c(GR2) and branch to YYY so long as the resulting sum does not exceed + 1.
3. If c(GR4) is + 1, then the instruction
BXH 5,4,ZZZ
will increment c(GR5) by 1 and then branch if the sum does not overflow. The index and
comparand are in the same register: if the comparison was made after the sum was placed in
GR5, equality would always be indicated, and the BXH would never branch.

Such special uses of the Branch on Index instructions are rare; they are used mostly in applica-
tions such as table searching and loop control. Try these exercises and the Programming Prob-
lems; you'll more fully appreciate the power of the branch on index instructions.

Exercises
22.9.1.(3) Suppose c(GR2)=5 and c(GR3)=73. What will be left in GR2 after executing these
two instructions?
BXLE 2,2,*
SRL 2,1
More generally, if GR2 contains a small positive integer and GR3 contains a larger positive
integer, what will be in GR2? Are there limits on the value of c(GR3)?

22.9.2.(3) + What will be left in GR5 after executing these instructions?

LHI 5,1 Initialize GR5 to +1
BXLE 5,5,* Do something interesting
Now, answer the same question for BXH.

22.9.3.(4) As in Exercise 22.7.6, the following code sequence tries to place in GR0 the number
of the leftmost bit in the positive nonzero number in GR1. Prove that it works correctly.
(Hint: consider the possible values of the two leftmost bits in GR1.)

Chapter VI: Addressing, Immediate Operands, and Loops 347

 LA 0,1 Initialize bit counter
LR 2,0 ... and bit count increment
SR 3,3 Zero comparand
Loop BXH 1,1,ZBit Skip if zero bit
B Done Exit with bit number in GR0
ZBit BXH 0,2,Loop Increment bit count and try again
Done - - - Bit number now in GR0

22.9.4.(4) What values in GR1 will cause the instruction

BXH 1,1,Yes
to branch to the location named Yes?

22.9.5.(4) Repeat Exercise 22.9.4, but with a BXLE instruction.

22.9.6.(4) What values in GR0 and GR1 will cause the instruction
BXH 0,1,Yes
to branch to the location named Yes?

22.9.7.(4) Repeat Exercise 22.9.6, but with a BXLE instruction.

22.9.8.(2) + The operation of the Branch On Index instructions has often been described as
follows:

1. The increment is added to the index, and the sum replaces the index.
2. The new index is compared to the comparand to determine the branch condition.

How is this description different from ours, and when and why is this description incorrect?
Give an example showing how it would affect the actual operation of the Branch On Index
instructions.

22.9.9.(4) + This instruction sequence evaluates X**N (X N ) for 32-bit integer values of X and
N. The base value X is in GR3, and the exponent value N is in GR0. Determine the algorithm
used to evaluate the exponential; assume that no overflows occur.
XR 1,1 Clear GR1 to zero
SRDL 0,1 Shift low-order exponent bit to GR1
BXH 1,1,OneBit Branch if it was a 1-bit
ZeroBit MR 2,3 Was a 0-bit, square work value
SRDL 0,1 Shift another low-order bit for test
BXLE 1,1,ZeroBit Branch if it's zero to square again
OneBit BXLE 0,1,Finished Br if remaining exponent bits all 0
LR 5,3 More bits to do. Copy work value
Square MR 4,5 Square work value
SRDL 0,1 Move another bit for testing
BXLE 1,1,TestMore Branch if it's zero
MR 2,5 Otherwise multiply work into answer
TestMore BXH 0,1,Square Branch if any 1-bits remaining
Finished - - - Result is in GR3
You will find it very instructive to follow this instruction sequence for several values of the
exponent such as 1, 5, 8, 11, and 15.

348 Assembler Language Programming for IBM System z™ Servers Version 2.00
22.10. Summary
The relative branch instructions discussed in this section are summarized in Table 126.

Relative-Immediate Operand Length

Operation
16 bits 32 bits
Branch on Condition (Relative) BCR BCRL
Table 126. Branch relative on condition instructions

The loop-control instructions discussed in this section are summarized in Table 127.

Register Length
Operation
32 bits 64 bits
Branch on Count (Register) BCTR BCTGR
Branch on Count (Indexed) BCT BCTG
Branch on Count (Relative) BRCT BRCTG
BXH BXHG
Branch on Index
BXLE BXLEG
BRXH BRXHG
Branch on Index (Relative)
BRXLE BRXLG
Table 127. Branch instructions for loop control

Instructions Discussed in this Section

The instruction mnemonics and opcodes are shown in the following table:

Mnemonic Opcode Mnemonic Opcode Mnemonic Opcode

BCT 46 BRCT A76 BXH 86
BCTG E346 BRCTG A77 BXHG EB44
BCTGR B946 BRXH 84 BXLE 87
BCTR 06 BRXHG EC44 BXLEG EB45
BRC A74 BRXLE 85
BRCL C04 BRXLG EC45

The instruction opcodes and mnemonics are shown in the following table:

Opcode Mnemonic Opcode Mnemonic Opcode Mnemonic

06 BCTR A74 BRC EB44 BXHG
46 BCT A76 BRCT EB45 BXLEG
84 BRXH A77 BRCTG EC44 BRXHG
85 BRXLE B946 BCTGR EC45 BRXLG
86 BXH C04 BRCL
87 BXLE E346 BCTG

Chapter VI: Addressing, Immediate Operands, and Loops 349

 Terms and Definitions
comparand
A quantity to which an incremented index is compared to determine whether a loop should
be repeated.
increment
A (normally) constant value used to update the value of an index for each iteration of a loop.
index
A varying quantity used to control each iteration of a loop.
R3 |1
A notation referring to the general register containing the comparand of a branch on index
instruction. If the R3 operand is even, R3 |1 is the next higher odd-numbered register; and if
the R 3 operand is odd, R 3 |1 is that odd-numbered register.

Programming Problems
Problem 22.1. Write a program to print a formatted hexadecimal multiplication table.

Problem 22.2. Each section of this text starts with large “block numbers” showing the section
number. The blocks are 12 characters wide and 12 characters high.
Write a program that reads a single record containing up to 72 numeric digits, and print up to
10 “block number” digits at a time across the page, each separated from the preceding by 2
spaces. If more than 10 digits are provided on the input record, print 2 blank lines before each
succeeding group. If a space appears in the input record, leave that 12-character position blank
in the printed output. (Remember that the 12 blanks are separated from any preceding char-
acter by 2 spaces.)
Thus, if your input record contained only the three characters '1 2' (with a space between the
two digits), your printed output would look like this; the bottom line is shown here only to
help you understand the spacing.

11 2222222222
111 222222222222
1111 22 22
11 22
11 22
11 22
11 22
11 22
11 22
11 22
1111111111 222222222222
1111111111 222222222222
....+....1....+....2....+....3....+....4....+....5....+....6.... etc.

Some other sections are headed with “block letters”. You will enjoy extending your program
to handle letters as well as digits.*

* Such block-lettered pages were called “banner pages”, and were often used to separate fan-folded printer outputs for
one job from another.

350 Assembler Language Programming for IBM System z™ Servers Version 2.00
Chapter VII: Bit and Character Data

VV VV IIIIIIIIII IIIIIIIIII
VV VV IIIIIIIIII IIIIIIIIII
VV VV II II
VV VV II II
VV VV II II
VV VV II II
VV VV II II
VV VV II II
VV VV II II
VV VV II II
VVVV IIIIIIIIII IIIIIIIIII
VV IIIIIIIIII IIIIIIIIII

In previous chapters we discussed instructions that manipulated data in byte, halfword, word, and
doubleword formats. The four sections of this chapter examine more basic System z instructions
that work with individual bits and bytes, and with varying-length character strings.
• Section 23 shows how we can manipulate data consisting of single bytes and individual bits
within a byte.
• Section 24 first introduces important concepts in using SS-type instructions. It then describes
frequently-used instructions used to process data involving large or variable numbers of bytes,
and introduces the powerful “Execute” instructions.
• Section 25 examines instructions that process very long byte strings, and strings containing a
special character.
• Section 26 discusses other character representations such as ASCII, Unicode and other
multiple-byte characters, and instructions to handle them.

Chapter VII: Bit and Character Data 351

23. Bit and Byte Data and Instructions

2222222222 3333333333
222222222222 333333333333
22 22 33 33
22 33
22 33
22 3333
22 3333
22 33
22 33
22 33 33
222222222222 333333333333
222222222222 3333333333

Instructions having an operand in the instruction itself are called immediate instructions: the
operand is immediately available from the Instruction Register, rather than from another register
or (more slowly) from memory. We saw examples of register-immediate operands in Section 21.
Here, the target operand of an SI-type instruction is in memory, whereas the RI-type and
RIL-type instructions in Section 21 refer to target operands in the general registers.

23.1. SI- and SIY-Type Instructions

SI- and SIY-type instructions let you manipulate byte and bit data. They use an 8-bit immediate
operand contained in the second (I2) byte of the instruction, in the two formats shown in Tables
128 and 129.

opcode I2 B1 D1
Table 128. SI-type instruction format

opcode I2 B1 DL DH opcode
Table 129. SIY-type instruction format

The actions of the corresponding SI-type and SIY-type instructions are the same, so we'll describe
only the SI forms. (Remember: the SIY-type instructions support a signed 20-bit displacement,
while the SI-type instructions use an unsigned 12-bit displacement.)

The operand field is written as either

D1(B1),I2 or S1,I2
showing the explicit and implied forms of address for the first operand.

The first operand of SI-type machine instruction statements typically refers to the name of a byte
in memory. The second operand must be a nonnegative absolute expression of value less than
256, so that it will fit into the I2 byte of the instruction.

Table 130 on page 353 describes the behavior of the instructions; the first operand is the single
byte at the Effective Address.

352 Assembler Language Programming for IBM System z™ Servers Version 2.00
 Operation Mnemonic Action CC set?
Move MVI, MVIY Operand 1 ── I2 No
AND NI, NIY Operand 1 ── Operand 1 AND I2 Yes
OR OI, OIY Operand 1 ── Operand 1 OR I2 Yes
XOR XI, XIY Operand 1 ── Operand 1 XOR I2 Yes
Compare CLI, CLIY Operand 1 Compared to I 2 Yes
Test Under Mask TM, TMY Test Selected Bits of Operand 1 Yes
Table 130. SI-type instruction actions

23.2. MVI Instructions

Table 131 lists the two Move Immediate instructions:

Op Mnem Type Instruction Op Mnem Type Instruction

92 MVI SI Move Immediate EB52 MVIY SIY Move Immediate
Table 131. Move Immediate instructions

MVI stores its I2 operand into the byte at the Effective Address.

MVI X,0 Set the byte at X to zero

MVI X,255 Set the byte at X to all 1-bits
MVI X,C'Y' Store EBCDIC character 'Y' at X
MVI X,C' ' Store EBCDIC blank at X
Figure 184. Examples of the MVI instruction

MVI is often used to initialize a byte whose bits will be used as bit flags, or to store a character.
For example:
MVI FlagByte,0 Set all flag bits to zero
MVI CrrgCtrl,C'1' Printer carriage control for new page

Exercises
23.2.1.(1) What do you expect will happen if you write these instructions?
MVI 0(4),B'000000000010101010'
MVI 0(4),B'000000000101010101'
MVI 0(4),-1

23.3. NI, OI, and XI Instructions

Table 132 summarizes these six Storage-Immediate instructions:

Op Mnem Type Instruction Op Mnem Type Instruction

94 NI SI AND Immediate EB54 NIY SIY AND Immediate
96 OI SI O R Immediate EB56 OIY SIY O R Immediate
97 XI SI X O R Immediate EB57 XIY SIY X O R Immediate
Table 132. Logical Storage-Immediate instructions

The CC settings after NI, OI, and XI are shown in Table 133 on page 354:

Chapter VII: Bit and Character Data 353

 Operation CC setting
AND
0: all result bits are zero
OR
1: result bits are not all zero
XOR
Table 133. CC settings by SI-type logical instructions

The logical operations of the NI, OI, and XI instructions are between corresponding bits of the
first and second operands, as we saw in Section 19. (You might want to review Figure 138 on
page 289.)

(1) NI X,0 Same as 'MVI X,0' except CC set to 0

(2) NI X,253 Sets bit 6 at X to 0 (see below)
Figure 185. Examples of the NI instruction

Sometimes it is better to use other types of self-defining term for the second operand; example (2)
could be written
NI X,B'11111101'
which more clearly shows that bit 6 will be zeroed.

(3) OI X,255 Same as 'MVI X,255' except CC set to 1

(4) OI X,B'00000010' Sets bit 6 at X to 1

(5) OI LowerA,C' ' c(LowerA) now is C'A'

LowerA DC C'a' Lower case letter 'a'
Figure 186. Examples of the OI instruction

XI X,B'0000010' Inverts bit 6 at X

Figure 187. Example of the XI instruction

Exercises
23.3.1.(1) Example (5) in Figure 186 claims that the OI instruction changes C'a' to C'A'. Is
this true? Why or why not?

23.3.2.(1) Write one instruction that will set the high-order and low-order bits of the byte at
Flags to zero without affecting any of the other six bits.

23.3.3.(1) Write one instruction that will set the high-order and low-order bits of the byte at
Flags to one without affecting any of the other six bits.

23.4. CLI Instructions

Table 134 shows the two Compare Immediate instructions:

Op Mnem Type Instruction Op Mnem Type Instruction

95 CLI SI Compare Immediate EB55 CLIY SIY Compare Immediate
Table 134. Compare Immediate instructions

The CLI instruction logically compares the byte in memory to the eight-bit I2 operand as
unsigned integers. The result is indicated by the CC setting, shown in Table 135 on page 355.

354 Assembler Language Programming for IBM System z™ Servers Version 2.00
 CC Indication
0 Operand 1 = I 2
1 Operand 1 < I 2
2 Operand 1 > I 2
Table 135. CC settings after CLI instruction

You'll remember that the same settings are generated by the CL and CLR instructions, in
Table 74 on page 232.

The following statements would result in the indicated CC settings. We use literals for the first
operand so that both operand values are immediately visible.
CLI =C'A',X'C1' CC = 0: c(Operand 1) = I2
CLI =X'00',0 CC = 0: c(Operand 1) = I2
CLI =C' ',B'01000000' CC = 0: c(Operand 1) = I2
CLI =X'1',X'2' CC = 1: c(Operand 1) < I2
CLI =C'A',250 CC = 1: c(Operand 1) < I2
CLI =C'X',C'X'-1 CC = 2: c(Operand 1) > I2
CLI =X'1',X'0' CC = 2: c(Operand 1) > I2

Remember:
The first operand in a CLI comparison is always the byte in memory at
the Effective Address.

We can rewrite the example in Figure 167 on page 332 (and its variations) to blank out the
special characters in the string at Str, now using CLI and MVI instructions. We'll start at the
right (high-addressed) end and scan from right to left.

LA 1,L'Str Initialize loop count to string len

Next LA 2,Str-1(1) Form character's indexed address
CLI 0(2),C'a' Compare addressed character with 'a'
JNL AlfaNum Skip blanking if not less than 'a'
MVI 0(2),C' ' Blank out if not alphanumeric
AlfaNum JCT 1,Next Count down and loop
- - -
Str DC CL80'String ...'
Figure 188. A simpler loop to scan and replace characters

Because SI-type instructions cannot be indexed, the LA instruction named Next generates the
memory address for the character to be tested. The CLI instruction then compares the byte in
memory at that address to the immediate operand C'a'. If the byte in memory contains a bit
pattern with value greater than or equal to C'a', the following JNL instruction will branch around
the MVI instruction. If the branching condition is not met, the MVI stores an EBCDIC blank
character into the character string. These two SI-type instructions have simplified the previous
examples of the same process.

Exercises
23.4.1.(1) + Suppose the length of a string of bytes starting at Data is not known, but we know
that the end of the string is marked with a byte of all 1-bits. Write a code sequence which will
leave the length of the string in GR1.

23.4.2.(1) + In solving Exercise 23.4.1, a student wrote these instructions:

SR 1,1 Initialize index
Loop LA 1,1(,1) Increment by one
CLI Data-1(1),X'FF' Test the byte
BNE Loop Branch if not all 1-bits

Chapter VII: Bit and Character Data 355

 Will this work?

23.4.3.(2) + An 80-byte record starts at Record. Using CLI, find the address of the last non-
blank character; store its address at LastChAd and store the length of the “initial” character
string (from the first character to the last nonblank) at DataLen.

23.4.4.(2) Write an instruction that will set the Condition Code to 1 without changing any data
or referencing any register, and without referencing any constants in storage.

23.4.5.(2) Write an instruction that will set the Condition Code to 2 without changing any data
or referencing any register, and without referencing any constants in storage.

23.4.6.(1) + A programmer tested a byte at Char for the lower case letter f, and wrote
CLI Char,f
He wasn't satisfied with the result; find two ways to help him.

23.4.7.(2) Write an instruction that will set the Condition Code to 0 without changing any data
or referencing any register, and without referencing any constants in storage.

23.5. Test Under Mask Instructions

Table 136 shows the two Test Under Mask instructions:

Op Mnem Type Instruction Op Mnem Type Instruction

91 TM SI Test Under Mask EB51 TMY SIY Test Under Mask
Table 136. Storage-Immediate instructions

The Test Under Mask instruction is very useful in applications that examine bits. Because the
CPU cannot directly address individual bits, data in bit form must be treated differently from data
in byte or word form.

The I 2 (immediate) operand of a TM instruction is a mask indicating which bits of the addressed
byte are examined: wherever a 1-bit appears in the mask, the corresponding bit position in the
first operand is examined, and wherever a 0-bit appears in the mask, the corresponding bit of the
memory operand is ignored. The result of the examination is indicated in the Condition Code, as
shown in Table 137.

CC Indication
0 Bits examined are all zero, or mask is zero
1 Bits examined are mixed zero and one
3 Bits examined are all one
Table 137. CC settings after T M instruction

If the I2 mask is zero (meaning that no bits are tested), the CC is set to zero. The following
examples illustrate uses of the TM instruction.
1. Branch to Minus if the fullword integer at Num is negative. (This technique can be used to
avoid loading anything into a register.)
TM Num,X'80' Test leftmost bit at Num
JO Minus Branch if a 1-bit
2. Branch to Even if the fullword integer at Num is even.
TM Num+L'Num-1,1 Test rightmost bit of the word
JZ Even Branch if bit is zero
3. Branch to Mixed if the bits of the byte at BB are not all zeros or all ones.

356 Assembler Language Programming for IBM System z™ Servers Version 2.00
 TM BB,255 Test all eight bits
JM Mixed Branch if mixed zero and one
4. Branch to Small if the value of the halfword integer at HNum is between − 512 and + 511: that
is, if the leftmost seven bits of the integer are all 0's or all 1's.
TM HNum,X'FE' Test leftmost seven bits
BC 9,Small Branch if bits all zero or all one

The NI, OI, XI, and TM instructions let you set and test “on-off” and “yes-no” indicators in a
program. For example, as in Figure 169 on page 333, suppose we wish to add the three fullword
integers stored beginning at Q, and after all additions are done, branch to NoErr if no overflows
occurred and to Error if one or more overflows occurred.

NI Flag,X'FE' Set indicator bit for no overflows

L 0,Q Get first integer
A 0,Q+4 Add second integer
JNO NextA Branch if no overflow
OI Flag,1 Set overflow bit to 1 ('on')
NextA A 0,Q+8 Add third integer
JO Error Branch if overflow
TM Flag,1 Otherwise examine overflow bit
JZ NoErr If bit was zero, no overflows
JO Error If one, overflow occurred
- - -
Flag DS X Overflow flag byte
Q DS 3F Integers to be added
Figure 189. Setting an overflow-indication flag bit

The OI instruction ORs a 1-bit into the rightmost bit position of the byte named Flag, setting it
to a 1. Only the rightmost bit of the byte is modified, so the remaining seven bits could be used
to indicate other conditions in the same program.

As another example of these instructions, suppose we have a list of N halfword integers stored at
List, where the positive nonzero fullword integer N is stored at NN. We must add the elements of
the list, except that alternate elements of the list are added twice. Whether the even-numbered or
the odd-numbered elements are added twice is determined by the setting of the rightmost bit of
the byte named Switch: if the bit is 1, the odd-numbered elements (beginning with the first) are
added twice.

LA 4,List Initial list address in GR4

L 3,NN Number of elements in GR3
SR 6,6 Initialize sum to zero
Load LH 5,0(,4) Get a halfword list element in GR5
AR 6,5 Add to sum once
TM Switch,1 Test switch bit
JZ Once Branch if zero, add only once
AR 6,5 Add a second time
Once LA 4,2(,4) Increment list address by 2
XI Switch,1 Invert switch bit
JCT 3,Load Get next list element
- - -
NN DS H Number of halfwords in the list
Switch DC B'0' Byte with the 'switch' bit
Figure 190. Adding alternate list elements twice

Since the XOR of a 1-bit and any other bit inverts its value, the XI instruction alternately sets the
switch bit to one and zero. The TM instruction examines only the rightmost bit of Switch, and
the branching condition is met if the bit is zero.

Chapter VII: Bit and Character Data 357

 Exercises
23.5.1.(2) In example 4 following Table 137 on page 356, show that if the leftmost seven bits
of a halfword integer are all zeros or all ones, then the value of the integer lies between − 512
and + 511.

23.5.2.(3) + Show that the operation of the TM instruction can be correctly described as
follows:

1. Form internally the logical AND of the first operand and I2. If the result is zero, set the
CC to zero and go to the next instruction.
2. If the result of step 1 is nonzero, form internally the logical XOR of the result byte from
step (1) and I2. If the new result is zero, set the CC to 3 and go to the next instruction.
3. Otherwise set the CC to 1, and go to the next instruction.

23.5.3.(2) Write an instruction that will set the Condition Code to 3 without changing any data,
and without referencing any register.

23.5.4.(2) + A programmer needed to test the sign of a 4-byte binary integer stored at BIN
without using any registers, and then branch to POS if the number was not negative. He wrote:
TUM BIN,80 Test Under Mask for sign bit
BP POS Branch if nonnegative
Why didn't this work? Repair his instructions to work correctly.

23.5.5.(1) Use a TM instruction to set the Condition Code to zero without referencing any reg-
isters and without referencing any constants in storage.

23.5.6.(1) + In example 3 of Section 23.5, can the extended mnemonic BNM be used to mean
“Branch if Not Mixed”? Why?

23.6. Bit Data

The above examples illustrated SI-type instructions used mainly for control purposes. Another
important application is to manipulate data in bit form, data that takes only two values. For
example, suppose that the record of a person carrying automobile insurance requires the following
“yes-no” information: (1) age less than 25? (2) male? (3) driver-training course completed? (4)
married? (5) any previous claims? (6) assigned risk? Let the “yes” answers be represented by
1-bits in the byte named Status. Here are ways we could perform the given tasks.
1. The policy-holder has passed his 25th birthday.
Under25 Equ B'10000000' Define the young-person bit
NI Status,X'FF'-Under25 He's getting older now
2. The policy-holder has just married.
Married Equ B'00010000' Define the married-person bit
TM Status,Married Did he say he was already married?
JO Bigamy (You never know!)
OI Status,Married Indicate he's married now
3. The policy-holder has submitted a claim. If it is the first, branch to Tsk; otherwise, branch to
TskTsk.
HasClaim Equ B'00001000' Define the made-a-claim bit
TM Status,HasClaim Test if he claimed previously
JO TskTsk Yes, must be accident-prone
J Tsk Accidents can happen to anyone
4. If the policy-holder is single, male, under age 25, and has not completed a driver-training
course, branch to HighCost. As this example shows, you can test more than one bit with a
single instruction:

358 Assembler Language Programming for IBM System z™ Servers Version 2.00
 Trained Equ B'00100000' Define the driver-trained bit
Male Equ B'01000000' Define the male-driver bit
TM Status,Married+Trained Test 'Married' and 'Trained'
JNZ Next Branch if both not zero
TM Status,Male+Under25 Test age and sex
JO HighCost If young untrained male, branch
Next - - - Rest of program
5. If the policy-holder is an assigned risk, indicate that he has previous claims if he also has no
driver training.
Assigned Equ B'00000100' Define the assigned-risk bit
TM Status,Assigned Check assignment status
JZ Next Branch if not assigned
TM Status,Trained Check driver training
JO Next Branch if completed
OI Status,HasClaim Otherwise set claim bit on
Next - - - Rest of program
6. If the policy-holder is married, or has completed driver training, branch to LowRisk.
TM Status,Married+Trained Check status
JM LowRisk Branch if either but not both

These examples use EQU statements to assign symbolic names to values representing bits. Unfor-
tunately, this is not the same as assigning a name to a bit itself; languages like PL/I have a BIT
data type, but Assembler Language does not.142

Exercises
23.6.1.(2) Write instructions to format the bits in the byte at BitData as eight EBCDIC 0 and 1
characters starting at BitChars.

23.6.2.(1) + In Example 6 of Section 23.6, can the extended mnemonic BNZ be used?

23.6.3.(1) + Suppose we defined a bit with the statement

Over25 EQU X'80'
How would you modify the statement in Example 1 of Section 23.6 to use this new definition?

23.7. Avoiding Bit-Naming Problems (*)

To illustrate a common problem using bit data, suppose we have defined two bytes containing
flag bits, as follows:
Flag1 DS X Define a byte containing flag bits
Bit0 Equ X'80' Name the value of bit 0 (leftmost)
Flag2 DS X Another flag byte
Bit1 Equ X'40' And a value for bit 1 (next)

Under normal circumstances, we would refer to the bits with a code sequence like
TM Flag1,Bit0 Test a bit in flag byte
JZ SomeCode Go do something if zero

The result of executing this TM instruction could easily be confused with

142 You can use macro instructions to implement a bit-defining and bit-handling language that names bits and protects
against referring to them accidentally.

Chapter VII: Bit and Character Data 359

 TM Flag1,Bit1 Test bit 1 (in the wrong byte!)
JZ MoreCode Branch if zero
or
TM Flag2,Bit0 Test bit 0 (in the wrong byte!)
JZ WhatCode Branch if zero
If there is no way to force the “definitions” of Bit0 and Bit1 to be associated with their
“owning” bytes, then if we use the wrong byte name we will test or manipulate the wrong bits. If
we execute the instruction
OI Flag2,Bit0
we will set a bit in the wrong byte. Mistakes like this are not uncommon.

Here is a simple technique that avoids this naming problem: define MyBit and HisBit with the
following statements:

MyBit DS 0XL(X'80') Define location and length attribute

DS X Reserve actual storage
HisBit DS 0XL(X'40') Define location, new length attribute
DS X Reserve actual storage
Figure 191. Defining bit names safely

The zero duplication factors mean that no storage will be reserved by the two bit-definition state-
ments. The symbols MyBit and HisBit have the value attributes of the following byte, and their
length attributes can be used to indicate which bit within each byte is desired. We then test the bit
with an instruction sequence like

TM MyBit,L'MyBit Test desired bit in correct byte

JZ YourCode Branch if MyBit is zero
Figure 192. Using safely-defined bit names

and no reference will be made to (now nonexistent) symbols naming the bytes containing the
MyBit and HisBit bits. Referring to MyBit only by its name and length attribute greatly reduces
the chances of incorrectly referencing bit data.

Some IBM macros define bit names by their position in a byte:

Bit0 Equ B'10000000' Bit 0
Bit1 Equ B'01000000' Bit 1
Bit2 Equ B'00100000' Bit 2
Bit3 Equ B'00010000' Bit 3
Bit4 Equ B'00001000' Bit 4
Bit5 Equ B'00000100' Bit 5
Bit6 Equ B'00000010' Bit 6
Bit7 Equ B'00000001' Bit 7

If you use definitions like these to set a specific bit at a known position in a byte, the bit name
indicates the bit's position. If, however, the bit is intended to have a meaning like “Initialization
Complete” or “End of Input”, it is much better practice give the bit a meaningful name:
InitDone Equ B'00000001' If 1, initialization completed
EndInput Equ B'00000010' If 1, no further input exists

Exercises
23.7.1.(2) Suppose the definition of MyBit in Figure 191 had been written
DS B
MyBit Equ *-1,X'80'
Would the instructions in Figure 192 work correctly? Why or why not?

360 Assembler Language Programming for IBM System z™ Servers Version 2.00
 23.7.2.(2) + Using the bit-naming technique illustrated in Figure 191, define two bits named
BitA and BitB in a single unnamed byte. Then, write code sequences to do the following:

1. Set BitA and BitB to zero.

2. Invert the value of BitB.
3. Branch to Both if BitA and BitB are both one.
4. Leave in GR0 the value of BitA+BitB (that is, a number which is 0, 1, or 2 depending on
whether neither, either, or both bits are 1).

23.8. A Data Conversion Example

As a final example using SI-type instructions, suppose there is a fullword integer stored at NN
that we want to convert to a character string of printable decimal digits. The sign of the number
must precede the first digit; if the number is zero, the characters +0 should be placed at the right-
hand end of the character string. Because a fullword integer can contain a value at most ten digits
long in its decimal representation, we will reserve eleven bytes at CharVal for the result. We use
the conversion method described in “ 2.3. Converting Integers from One Base to Another (*)”
on page 19.

The method shown here works, but is clumsy and complex. We will see when we examine
packed decimal data in Section 30 that other instructions greatly simplify this task.

D EQU 10 Max number of digits

LA 2,D First, blank out result area
Blank LA 3,CharVal-1(2) Construct byte address
MVI 0(3),C' ' Store blanks in first 'D' bytes
JCT 2,Blank Branch back (D-1) times
LA 3,CharVal+D Set up address of rightmost digit
L 1,NN Get number to be converted
LPR 1,1 Take its magnitude
CnvtLoop SR 0,0 Clear high-order register
D 0,=F'10' Generate a digit by division
STC 0,0(,3) Store the remainder digit
OI 0(3),X'F0' Form correct EBCDIC representation
BCTR 3,0 Move character pointer left by 1
LTR 1,1 If quotient is zero, finished
JP CnvtLoop If nonzero, generate more digits
MVI 0(3),C'-' Assume value was -, put sign
TM NN,X'80' Check actual sign of argument
JO AllDone Branch if it was indeed -
MVI 0(3),C'+' Sign is +, store character
AllDone - - - Rest of program
CharVal DS CL(D+1) Output character string, with sign
NN DS F Number to be converted
Figure 193. Converting a binary integer to characters

23.9. Instruction Modification (*)

In olden days, it was sometimes thought to be useful (or clever) to change the mask field of a
conditional branch instruction, so that it alternately contained B'1111' and B'0000', causing an
unconditional branch to alternate with a no-operation. The example in Figure 190 on page 357
might be rewritten as in Figure 194 on page 362 to use this technique.

Chapter VII: Bit and Character Data 361

 L 1,NN Get number of elements to be added
LA 0,2 Set up increment of 2 in GR0
AR 1,1 2 * N
SR 1,0 2 * (N-1) = comparand for BXLE
SR 2,2 Initialize index in GR2 to zero
SR 3,3 Same for sum, in GR3
OI Brnch+1,X'F0' Set for single add on first pass
TM Switch,1 Check to see if setup is correct
JZ Add Jump if branch setup is correct
NI Brnch+1,X'0F' Otherwise set up to add twice
Add AH 3,List(2) Add a term from the list
Brnch BC 0,FlipMask Mask field alternated by XI inst'n
AH 3,List(2) Add again if required
FlipMask XI Brnch+1,X'F0' Invert branch mask bits again
BXLE 2,0,Add Count and loop
ST 3,Result Store answer
Figure 194. Adding alternate list elements twice, with program modification

The mask field of the BC instruction is addressed as Brnch+1, because Brnch is the name of the
byte containing the operation code. Then, the instructions that manipulate the mask bits are
written to leave unchanged the index register specification digit of the second byte of the instruc-
tion at Brnch, because we do not want to modify the index digit.

Modifying an instruction in memory is now considered a terrible programming practice, for these
reasons:
1. The coding tends to be more difficult to understand, because you won't know with any cer-
tainty what is done by a given instruction if it could be modified by other parts of the
program.
2. Debugging the program is more difficult, since it is usually easier to keep track of data (such
as at Switch in Figure 190 on page 357) than parts of instructions. What you see in
memory might not match your program listing. (It's no longer the program you wrote!)
3. If you must rewrite part of a program, it may be difficult to find all the instructions that
modify or are modified by others.
4. If, as many programs are, the program must be reenterable (a property requiring no self-
modification), such techniques are forbidden.
5. Modern processors assume that any instruction modifying memory is referring to data, so
they prefetch large groups of instructions for faster decoding. If the CPU discovers that you
have stored into the part of the program it prefetched, it must discard its initial analysis and
re-fetch again. This can slow your program considerably.

Important Advice
Avoid self-modifying programs.

Most instruction modification needs are best handled by the Execute instruction, which we'll see
in Section 24.11.
To show that the example in Figure 194 need not rely on program modification, the code
segment in Figure 195 on page 363 does the same calculation more rapidly and safely.
Study the actions of the JXH and JXLE instructions carefully!

362 Assembler Language Programming for IBM System z™ Servers Version 2.00
 L 1,NN Set up JXLE comparand N in GR1
BCTR 1,0 N-1
ALR 1,1 2 * (N-1) = 2N-2 in GR1
LA 0,2 Increment in GR0
SR 3,3 Initialize sum to zero
SR 2,2 Same for index
TM Switch,1 Test for first term adding twice
JO Twice Branch if bit is 1, meaning yes
Once AH 3,LIST(2) Add a term once
JXH 2,0,Done Increment index, branch if done
Twice AH 3,LIST(2) Add a term
AH 3,LIST(2) ...twice
JXLE 2,0,Once Increment index and loop
Done - - - Continuation of program
Figure 195. Adding alternate list elements twice, without program modification

Exercises
23.9.1.(3) The following fragment of code was discovered in a trash can. By examining the
sequence of values contained in R4, determine what the code does.
LA 6,2
LA 4,5 Test number
VA AR 4,6
SLL 6,1
XI *-4,X'01' Flip-flop
- - - Some undecipherable material
B VA

23.9.2.(2) Show that the SI-type OI, NI, and XI instructions in Figure 194 on page 362 do not
modify the index register specification digit of the instruction named Brnch.

23.9.3.(2) A widely used program (HASP) contained an instruction sequence like the following:
OI Flag+1,1 Set a flag bit
- - -
Flag TM Flag+1,0 Test the flag byte
BNZ FlagSet Branch if not zero
Elsewhere in the program, other instructions modified the byte at Flag+1. Why would anyone
write a program this way?

23.10. Summary
The instructions we've discussed in this section are summarized in Table 138.

Operand 1
Function Operand 2
12-bit displacement 20-bit displacement
Move Immediate MVI MVIY I2
AND Immediate NI NIY I2
O R Immediate OI OIY I2
X O R Immediate XI XIY I2
Compare Immediate CLI CLIY I2
Test Under Mask TM TMY I2
Table 138. Storage-Immediate instructions

Chapter VII: Bit and Character Data 363

 Instructions Discussed in this Section
The instruction mnemonics and opcodes are shown in the following table:

Mnemonic Opcode Mnemonic Opcode Mnemonic Opcode

CLI 95 NI 94 TM 91
CLIY EB55 NIY EB54 TMY EB51
MVI 92 OI 96 XI 97
MVIY EB52 OIY EB56 XIY EB57

The instruction opcodes and mnemonics are shown in the following table:

Opcode Mnemonic Opcode Mnemonic Opcode Mnemonic

91 TM 96 OI EB54 NIY
92 MVI 97 XI EB55 CLIY
94 NI EB51 TMY EB56 OIY
95 CLI EB52 MVIY EB57 XIY

Terms and Definitions

reenterable
A program is reenterable if
• Its execution can be suspended, then executed by other processes, and then resumed by
the original process with correct behavior for all processes.
• It can be executed simultaneously by multiple processes, with correct behavior for all
processes.
self-modification
A program modifies its instructions or constants. Considered a very poor programming prac-
tice with severe execution-time performance penalties, and forbidden if the program must be
reenterable.143

143 Technically, a self-modifying program can be reenterable if every execution instance makes exactly the same modifi-
cations. This is considered an even poorer practice.

364 Assembler Language Programming for IBM System z™ Servers Version 2.00
24. Character Data and Basic Instructions

2222222222 44
222222222222 444
22 22 4444
22 44 44
22 44 44
22 44 44
22 44444444444
22 444444444444
22 44
22 44
222222222222 44
222222222222 44

The instructions we've seen thus far have involved at most one memory operand; now we'll inves-
tigate basic SS-type instructions that work with two operands in memory having variable lengths.
We will also describe “Execute” instructions that help you handle varying-length data.

24.1. Basic SS-Type Instructions

We'll introduce some basic concepts using the instructions in Table 139.

Op Mnem Type Instruction Op Mnem Type Instruction

D2 MVC SS Move [Characters] E8 MVCIN SS Move [Characters] Inverse
D4 NC SS AND [Characters] D6 OC SS O R [Characters]
D7 XC SS X O R [Characters] D5 CLC SS Compare Logical [Characters]
DC TR SS Translate DD TRT SS Translate and Test
D0 TRTR SS Translate and Test Reverse
Table 139. Basic character-handling instructions

The word “Characters” is enclosed in square brackets because the z/Architecture Principles of
Operation description of those instructions omits that word from the name of the instruction, even
though it's implied by the instruction mnemonics. While often used to manipulate character data,
they simply process strings of bytes, whether or not they represent characters.

Because the lengths of the operands are not implied by the instruction (as we saw for instructions
like L and LH), the number of bytes to be processed must be specified somehow. The
instructions in Table 139 have the format illustrated in Table 140:

opcode L B1 D1 B2 D2
Table 140. Format of single-length SS-type instructions

Chapter VII: Bit and Character Data 365

 These instructions are all 6 bytes long, have two Addressing Halfwords, and their second byte
(“L”) specifies the machine length or Encoded Length144 of the operand or operands; we'll explain
“Encoded Length” shortly.

The Assembler Language syntax of these instructions is shown in Figure 196:

mnemonic D1(N,B1),D2(B2)
Figure 196. Assembler Language syntax of basic SS-type instructions

where N, the Length Expression (LE) (also known as the program length) is the number of bytes
the instruction will process. (For some of these instructions, “at most” N bytes.)

The important difference between N and L is explained in Section 24.5 on page 370.

Except for TRT and TRTR, the only reference to or use of the general registers by the
instructions in Table 139 on page 365 is for operand addressing.

The result of each operation is found in the first operand location, except for TRT, TRTR, and
CLC, which modify no data in memory.

24.2. Operand Specifications and Explicit Lengths

As illustrated on page 114 in Section 9.9, you could write a typical SS-type instruction as
MVC Field(5),Area

The operand field specifies three quantities: the implied addresses of the operands named Field
and Area, and the number of bytes to be moved, 5.

Because the symbols Field and Area must be resolved into addressing halfwords, we must derive
five operand-dependent quantities: the Encoded Length L and the base and displacement of the
two addressing halfwords. The base and displacement of each addressing halfword is assigned by
the Assembler from an implied address.

The number L in the Encoded Length byte generated by the Assembler is derived from the
Length Expression (N) in your machine instruction statement. The Length Expression may also
be explicit or implied; we'll discuss implied Length Expressions in Section 24.4.

You will remember from Section 8.5 on page 102 that machine instruction statement operands
can take any of these three forms:

expr expr(expr) expr(expr,expr)

where the third format can sometimes be written expr(,expr).

For most of the instructions we've seen so far, these formats are used for the first four instruction
types shown in Table 141 on page 367, where S is our notation for an implied address, an abso-
lute or relocatable expression. In the last row, we see that SS-type instructions introduce new
possibilities:

144 The Encoded Length byte is sometimes called the “machine length” or “Length Specification Byte”.

366 Assembler Language Programming for IBM System z™ Servers Version 2.00
 Instruction
Operand Format
Type
expr expr(expr) expr(expr,expr) expr(,expr)
RR register invalid invalid invalid
RX S S(X) D(X,B) D(,B)
RS S D(B) invalid invalid
SI S or immediate D(B) invalid invalid
SS S S(N) D(N,B) D(,B)
Table 141. Instruction types and operand formats

In particular, notice that for SS-type instructions, the third operand format does not resolve to
D(X,B)!

Suppose we want to move 23 bytes from the area of memory beginning at AA to the area begin-
ning at BB. We could write
MVC BB(23),AA Move 23 bytes from AA to BB
where the addresses of the two operands are implied. For SS-type instructions, the number in
parentheses is not an index register specification, but an explicit Length Expression. Its value, 23,
is the number N of bytes to be moved.

There are several ways to specify the Length Expression, as shown in Table 142. (Remember
that “S 1” and “S 2” are our notations for the implied addresses of the first and second operands.)

Explicit Length
S1(N),S 2
D 1(N,B 1),S2
S1(N),D 2(B 2)
D 1(N,B 1),D 2(B 2)
Table 142. SS-type instructions with explicit length

An explicit Length Expression is simply an expression you write in your machine instruction
statement. Suppose we again want to move 23 bytes from AA to BB and that if GR9 is used as a
base register, the displacements for AA to BB will be X'125' and X'47D' respectively. Then,
Figure 197 shows how we could use any of the following four instructions, corresponding to the
four operand formats in Table 142:

MVC BB(23),AA S1(N),S2

MVC X'47D'(23,9),AA D1(N,B1),S2
MVC BB(23),X'125'(9) S1(N),D2(B2)
MVC 1149(23,9),293(9) D1(N,B1),D2(B2)
Figure 197. Examples of SS-type instruction operands

Equivalent decimal and hexadecimal self-defining terms are used for the displacements D1 and D 2.

Exercises
24.2.1.(1) What is the difference between an implied address and an implicit address?

Chapter VII: Bit and Character Data 367

24.3. Symbol Length Attribute References
A Symbol Length Attribute Reference is written as the letter L followed by an apostrophe fol-
lowed by a symbol, as in L'BB. It is an absolute term with value equal to the length attribute of
the symbol. Because symbols can be defined in several ways, the following rules may be helpful:
1. If the symbol was defined in an EQU statement with * or a self-defining term in the operand
field, its length attribute is one. However, as noted in Section 8.4 on page 100, if you specify
a second operand in the EQU statement, that value will be used as the Length Attribute of
the symbol. For example, if you define the symbol XXX in this EQU statement,
XXX Equ *,13
then XXX will have the value of the current Location Counter, and length attribute 13.
2. The length attribute of a literal is defined; thus
MVC BB(L'=C'RAY'),=C'RAY'
(while clumsy) is valid; it's better to define a constant named by a symbol, and then use the
length attribute of the symbol:
MVC BB(L'RAY),RAY
- - -
RAY DC C'RAY'
3. The length attribute of a Location Counter Reference (*) is the length of the machine
instruction in which it appears. Thus MVC BB(L'*),AA assigns length attribute six, the length
of the MVC instruction.
• The length attribute of a symbol naming a macro instruction depends on the code it gen-
erates.

Exercises
24.3.1.(2) Can you find a way to specify an implied Length Expression whose value is zero?

24.3.2.(2) Is it possible to specify the length attribute of an expression using the L' notation?

24.4. Implied Lengths

If you don't specify an explicit length N, the assembler will derive an implied length from the first
term in the first operand.

Implied Length
S1,S2
D 1(,B1),S2
S1,D 2(B 2)
D 1(,B1),D 2(B 2)
Table 143. SS-type instructions with implied length

Note that if the address of the first operand is specified explicitly and the Length Expression is
implied, the comma following the left parenthesis is very important.

As a reminder, the words “explicit” and “implied” that we saw in Section 11.4 were used define
constants with explicit and implied lengths:
IMPLIED DC F'8' Implied length = 4 bytes
EXPLICIT DC FL5'8' Explicit length = 5 bytes

and the same words describe addresses:

368 Assembler Language Programming for IBM System z™ Servers Version 2.00
ImplAddr L 0,=F'6' Implied address, resolved by Assembler
ExplAddr L 0,X'D4'(0,7) Explicit address, specified by you

In this section, we use the same words to describe Length Expressions: you can provide an explicit
Length Expression, or you can let the Assembler derive the value of an implied Length
Expression.

We usually don't want to have to specify an explicit Length Expression, particularly when the
number of bytes should be apparent from the operands. For example, suppose the symbol BB is
defined in a DS statement like this:
MVC BB,=120C' ' Set field at BB to blanks
- - -
BB DS CL23 Field of length 23 bytes

Even though the second operand is 120 bytes long, if more than 23 bytes are moved by the MVC
instruction, then the data or instructions following the byte at BB+22 could be overwritten! Thus
the length of the string of bytes to be moved should be determined from the first, or receiving,
operand, rather than the second.

This is what the Assembler does. If no explicit Length Expression is given, the Length Attribute
of the first operand is used as the value of the Length Expression: it is implied by the operand. In
this example, the length attribute of the symbol BB is 23.

If the first operand is an expression rather than a single term, the length attribute is that of the
leftmost term in the expression. Thus, with BB defined as above, if we write
MVC BB-4+X'5'-1,=120C' '
then the length attribute of the first operand is 23, but if we write
MVC X'5'+BB-5,=120C' '
the length attribute of the first operand is 1 because the length attribute of a self-defining term is
always 1 (see Section 7.6).

Now, suppose we want to use an implied length, but with an explicit first operand address. The
value of the Length Expression cannot be immediately associated with a symbol that names an
area of the program using its length attribute. Unlike the examples in Figure 197 on page 367,
knowing the base and displacement of the symbol BB (9 and X'47D') does not necessarily give the
correct Length Expression when an implied length must be found. If an explicit base and displace-
ment are given, the value of the Length Expression is the length attribute of the displacement
expression. Thus
MVC X'47D'(,9),AA
specifies an implied length of 1 rather than 23, because X'47D' is a self-defining term. Using an
explicit address and an implied length is very rare; it's much better to use a Length Attribute Ref-
erence.

You can specify an explicit base and displacement, and still use an implied length. We could have
written
MVC BB-BB+X'47D'(,9),AA
and the length attribute of the displacement expression is the length attribute of BB, but this is
cumbersome and confusing. We can rewrite this example to use an explicit base and displace-
ment, in the improved form

MVC X'47D'(L'BB,9),AA Length Expression = L'BB

Figure 198. SS-type instruction using a Length Attribute reference

It is almost always better to use a Symbol Length Attribute Reference, which is one of the terms
we described when examining expressions in Section 8.1.

These rules are summarized in Table 144 on page 370. The last column shows how the Length
Expression is determined for the four possible forms of the first operand.

Chapter VII: Bit and Character Data 369

 First operand form Address specification Length Expression Length used
S1 implied implied L'S 1
S1(N) implied explicit N
D 1(,B1) explicit implied L'D 1
D 1(N,B 1) explicit explicit N
Table 144. Determining the Length Specification Byte

Advice: Use Implied Lengths

Wherever possible, use implied lengths and let the Assembler derive the
Length Expression for you. If the length of a data field changes, the
Assembler will recalculate the Length Expression; this is safer and much
more convenient than updating explicit Length Expressions manually.

Exercises
24.4.1.(1) How many bytes will be moved by these instructions? What values will you find in
the first operand fields?
(1) MVC A,=X'01020304050'
A DS H

(2) MVC B,=CL6'ABCDEF'

B DS BL4

(3) MVC C(3),=F'2'

24.4.2.(2) + What are the formats of each of these possible operands when used as (a) the first
operand, and (b) the second operand of an MVC instruction?

(1) 7(4) (2) 24(6,12) (3) A(B) (4) 5(,1)

24.4.3.(2) + The paragraph following Table 141 on page 367 says that the comma following the
left parenthesis is very important in some situations. Why?

24.5. The Encoded Length “L” and Program Length “N”

Now that we know how to write SS-type instruction statements with any Length Expression we
need, we will review what actually goes into the machine language instruction. As we noted in
Section 24.2, the value of the Encoded Length isn't necessarily the same as the value of the
Length Expression. Here's why.

Why do we use L in the object code format, but N in the machine instruction statement format?
They are different: L is one less than N (unless N is zero, in which case L is also zero). This is
important!

There are good reasons for this difference:

• programmers want to specify N, the true number of bytes involved;
• the CPU must sometimes know the address of the rightmost byte of an operand; that address
is the operand's Effective Address (its starting address) plus L;
• it makes no sense to operate on zero bytes (that's what NOP instructions are for!).
• the Execute instructions in Section 24.11 will show why instructions with zero length bytes are
very useful.
When you code a value N in a machine instruction statement, the Assembler converts it to the
correct value of L in the generated object code.

370 Assembler Language Programming for IBM System z™ Servers Version 2.00
Because the Length Specification Byte is a single byte, it can have any value between 0 and 255;
these actually specify operand lengths between 1 and 256. This is due to two factors:
• Every SS-type instruction always operates on at least one byte.
• All the instructions in Table 139 on page 365 except MVCIN and TRTR process data from
left to right in order of increasing addresses.
− For left-to-right instructions, the CPU must calculate the address of the last byte of each
operand to check for possible memory-access violations.
− Similarly, MVCIN, TRTR, and some other instructions process data from right to left, in
order of decreasing addresses, starting at the rightmost byte.
In both cases, the CPU must compute the addresses of the leftmost and rightmost bytes of the
operand. It is simplest to locate the rightmost byte by adding the Encoded Length L to the
effective address of the operand; if there are N bytes in a string starting at address A, its right-
most byte is at address A+N− 1 = A+L.

That's why the Encoded Length has the value of the Length Expression minus 1.

Important Notation Difference!

The z/Architecture Principles of Operation illustrates SS-type instructions
like MVC this way, where the two uses of L can be very confusing:
CLC D1(L,B1),D2(B2) [SS]
┌────────┬────────┬────┬────────────┬────┬────────────┐
│ D5 │ L │ B1 │ D1 │ B2 │ D2 │
└────────┴────────┴────┴────────────┴────┴────────────┘
Both the Assembler Language syntax with operands D1(L,B 1),D 2(B 2)
and the format of the assembled instruction use the same letter “L” to
indicate the operand length! But the two numbers are not the same: the
first “L” in the Assembler Language statement is the Length Expression
(that we call N, the true number of bytes to process), while the second
“L” in the assembled instruction is the Encoded Length, one less than the
true length!

When you refer to the z/Architecture Principles of Operation, be very

careful to distinguish the two uses of L.

We usually don't care about this distinction because we let the Assembler determine the needed
quantities from the operands of the instruction statement. However, at execution time we may
need to calculate the number of bytes to be manipulated, so it's important to understand this
relationship between the Encoded Length and the actual number of bytes involved. An illus-
tration (showing a bad way to do this) is given in Example 4 of Section 24.6; the right way to do
this is discussed in Section 24.11.
Thus, the Encoded Length is a number one less than the value of the Length Expression, unless
an explicit length of zero is given, in which case the Encoded Length is also zero.

Encoded Length
The Encoded Length is one less than the Length Expression, unless the
Length Expression is zero.

The instructions in Figure 199 on page 372 would be assembled as indicated, assuming the same
displacements for the symbols AA and BB relative to the base address in GR9, as in Section 24.2.

Chapter VII: Bit and Character Data 371

 * Instruction Assembled form
*
MVC BB(23),AA D216 947D 9125 LE=23
MVC BB(1),AA D200 947D 9125 LE=1
MVC BB(0),AA D200 947D 9125 LE=0
MVC 0(L'*,0),29(12) D205 0000 C01D LE=6 (MVC's length!)
MVC 15(L'BB-4,3),BB D212 300F 947D LE=19
MVC BB,AA D216 947D 9125 LE=23
MVC H(L'H,H),H D200 8008 0008 LE=1
MVC H(H,H),H(H) D207 8008 8008 LE=8
MVC H+BB-AA(,9),AA D200 9360 9125 LE=1
MVC T,BB-4 D216 947D 9479 LE=23
MVC BB-AA+4(9),AA D208 035C 9125 LE=9
- - -
BB DS CL23
T EQU BB Length attribute of T = 23
H EQU 8 Self-defining term, Len Attr = 1
Figure 199. Examples of Length Specification Bytes

Possible Confusion?
Sometimes people call “the value of the Length Expression” simply “the
length”. This can be confusing if “the length” is understood to mean the
contents of the Encoded Length, which is sometimes called the “machine
length”. That is:
• You provide implicitly or explicitly a Length Expression (a “symbolic
length” or “program length”).
• The Assembler generates the Encoded Length (the “machine length”).

24.6. The MVC and MVCIN Instructions

24.6.1. MVC: Move Characters
MVC moves the specified number of bytes starting at the second operand address to an area
starting at the first operand address. There are no restrictions on overlapping areas, so you can do
things like propagate a character through an area, or shift the bytes in an area. We need only
remember that almost all SS-type instructions are executed in such a way that each byte is stored
before the next source byte is accessed.

Figure 200 shows how MVC can be “emulated” by other instructions. Remember that the length
expression LE is not the Length Specification Byte of a “real” MVC.

*Emulate MVC BB(LE),AA Moves LE bytes from AA to BB

LA 1,BB Address of first operand
LA 2,AA Address of second operand
LA 0,LE Length Expression (N)
LTR 0,0 Check for zero
JNZ MoveByte Nonzero, OK to move
LA 0,1 LE=0 means move one byte
MoveByte IC 3,0(,2) Get a second-operand byte
STC 3,0(,1) Store at first operand
AHI 1,1 Increment first operand address
AHI 2,1 Increment second operand address
JCT 0,MoveByte Repeat until LE bytes moved
Figure 200. Emulated operation of MVC instruction

372 Assembler Language Programming for IBM System z™ Servers Version 2.00
Because MVC has no restrictions on operand overlap, the “byte at a time” emulation in
Figure 200 is “faithful” to the execution of MVC. Of course, the MVC instruction doesn't
modify any registers this way.

Here are some examples using MVC instructions.

1. Set the 120-byte area beginning at Line to blanks.
MVI Line,C' ' Store EBCDIC blank at 'Line'
MVC Line+1(119),Line Propagate through rest of area
This is sometimes called a “ripple” move. It requires less storage space than
MVC Line(120),=120C' '
because extra space is required for the literal string of 120 blanks.
Another way to set the 120-byte area at Line to blanks:
MVC Line,Line-1 Requires carefully-ordered DC's
- - -
Blank DC C' ' Single blank
Line DS CL120 Immediately follows the blank
2. Shift the 80-byte character string beginning at Str to the left by two character positions,
leaving blanks in the vacated positions.
MVC Str(78),Str+2 Move left by 2 bytes
MVC Str+78(2),=C' ' Two blanks at end
3. Exchange the contents of the halfword integers at A and B.
MVC Temp,A Move A to temporary location
MVC A,B Move B to A
MVC B,Temp Move old c(A) from Temp to B
- - -
Temp DS XL2
A DS H
B DS H
4. GR8 and GR9 contain respectively the address and length of a message whose length is posi-
tive and less than 120 characters. Move the message to the area named Line.
BCTR 9,0 Decrease length by 1
STC 9,MVC+1 Store in length byte of MVC (??)
MVC MVC Line(0),0(8) Move correct number of bytes
The BCTR reduces the character count in GR9 from its “true” value to the “machine
length” value required by the MVC: one less than the actual number of bytes to be moved.
This is a terrible way to do this, because it requires instruction modification (discussed in
Section 23.9). A a better way to do this uses the Execute instruction, which we'll see in
Section 24.11.

24.6.2. MVCIN: Move Characters Inverse

MVCIN was implemented to support languages written from right to left. It moves characters
the same way as MVC, but in reverse order. That is, the bytes of the second operand are fetched
in right-to-left order and are stored at the first operand in left-to-right order. The second operand
of the machine instruction statement must address the rightmost byte of the string to be moved.
For example:

MVCIN CRev,Chars+L'Chars-1 Move reversed Chars to CRev

- - -
Chars DC C'12345' Data to be moved
CRev DS CL(L'Chars) Moved data = C'54321'
Figure 201. Example of Move Inverse instruction

Chapter VII: Bit and Character Data 373

 As Figure 200 on page 372 does for MVC, Figure 202 shows an emulation of MVCIN. The
emulation uses GR3 both as an index and as a count of the number of bytes to move.

*Emulate MVCIN BB(LE),AA+L'AA-1 Move inverse: LE bytes from AA to BB

LA 3,LE Number of characters to move in GR3
LTR 3,3 Check for LE = 0
JNZ LENotZro Skip if greater than zero
LA 3,1 LE = 1 moves one byte
LENotZro LA 1,BB Address of first operand
LA 2,AA-1 A(2nd operand's leftmost byte)-1
Insert IC 0,0(3,2) Insert a byte from right end of AA
STC 0,0(,1) Store at left end of BB
AHI 1,1 Increment first operand address
JCT 3,Insert Reduce byte count by one and loop
Figure 202. Emulated operation of MVCIN instruction

The emulated addressing seems to reference the byte preceding the leftmost byte of the second
operand. However, the indexed IC instruction will start by inserting the rightmost byte and will
end with the byte at AA, because GR3 actually contains the Length Expression, not the Length
Specification Byte.

Unlike MVC, the z/Architecture Principles of Operation does not guarantee “byte-by-byte” opera-
tion for MVCIN, so if the operands overlap by more than one byte, the results may be unpredict-
able.

24.6.3. MVCOS: Move Characters With Optional Specifications (*)

The specialized MVCOS instruction can simplify character moves.

Op Mnem Type Instruction

C80 MVCOS SSF Move [Characters] with Optional Specifications
Table 145. MVCOS instruction

The SSF instruction format illustrated in Table 146 is used for relatively few instructions.

opcode R3 op B1 D1 B2 D2
Table 146. SSF instruction format used for the MVCOS instruction

Unlike the previous SS-type instructions, you specify the true length to be moved in a register, set
GR0 to zero, 145 and the instruction will move up to 4096 bytes at a time. Its syntax is
MVCOS D1(B1),D2(B2),R3
where data is moved from the second operand to the first, and the number of bytes to move is
placed in the R3 operand register (which of course must not be GR0!). The number of bytes
actually moved is the number in the R3 register or 4096, whichever is less. The CC is set to 0 if
all bytes have been moved, or to 3 if more than 4096 bytes were specified.

For example, suppose we want to move 10000 bytes from Here to There:

145 If nonzero bits appear in GR0, your program may cause a privileged-operation exception.

374 Assembler Language Programming for IBM System z™ Servers Version 2.00
 LA 7,There Target address
LA 4,Here Source address
LHI 12,10000 Number of bytes to move
XGR 0,0 Set GR0 to zero (important!)
Mover MVCOS 0(7),0(4),12 Move up to 4096 bytes
JZ Done Branch if all bytes moved
AHI 7,4096 Update target address
AHI 4,4096 Update source address
AHI 12,-4096 Reduce remaining count
J Mover Repeat for more bytes
Done - - -
Figure 203. Example of MVCOS instruction

This example illustrates these important points:

• The source and target addresses, and the remaining byte count, are not updated by MVCOS:
you must do that.
• Setting GR0 to zero is very important: MVCOS is a semi-privileged instruction, and any
nonzero bits in GR0 may cause a program interruption (unless your program is executing in
Supervisor State).

The convenience of MVCOS compared to MVC or MVCL may be outweighed by its slightly
slower performance.

Exercises
24.6.1.(2) Suppose MVCIN used predictable “byte-by-byte” steps for any degree of operand
overlap. What result would appear in Figure 201 on page 373 if the instruction was
MVCIN Chars,Chars+L'Chars-1 ?

24.6.2.(2) The character string at Message has three segments, as defined by these statements:
Message DS 0C
Prefix DS CL43
Insert DS CL29
Suffix DS CL67
Write instructions that will move the strings at PText, IText, and SText into these fields, but
the string at IText must be moved to Insert in reverse order.

24.6.3.(1) What will be in the character string at Result after executing these instructions?
MVC Result,Data
- - -
Data DC C'Data'
Result DS CL8

24.6.4.(1) What is in both operands after executing this MVC?

MVC Result2(8),Data2
- - -
Result2 DS C'ABCD'
Data2 DC C'PQRSTUVW'

24.6.5.(2) In example 4 of Section 24.6.1, is there any reason (other than very poor style) not to
write the last two instruction statements as
STC 9,*+5
MVC LINE(0),0(8) ?

24.6.6.(3) Consider these two examples of an MVCIN instruction with overlapping operands:

Chapter VII: Bit and Character Data 375

 (1) MVCIN X,Y+L'Y-1
- - -
X DS CL7
ORG *-1
Y DC CL7'ABCDEFG'

(2) MVCIN Q,P+L'P-1

- - -
P DC CL5'12345'
ORG *-1
Q DS CL5
In each case, the target and source operands overlap by one byte. After executing the
instructions, what data is at X and Q? Why is this one-byte overlap not a problem?

24.6.7.(2) + Suppose three character strings are defined by the statements

A DC C'123456'
B DC C'PQRSTUVW'
C DS CL(L'A+L'B)
Write instructions to concatenate the strings at A and B into a single string at C.

24.6.8.(2) + Suppose three character strings are defined by

D DC C'987654ABCDE'
E DS CL4
F DS CL(L'D-L'E)
Write instructions to split the string at D into two substrings at E and F.

24.6.9.(3) + You are given a string of characters starting at Str whose length is stored at N, and
are required to extract a substring of characters whose length is at K, starting at a character
whose offset from N is stored at P. The extracted substring should be stored at Sub, and its
length should be stored in the word at L. (N, K, P, and L are words in your program.)
In case the substring is not fully contained in Str, the values at K and L will differ; and if no
valid substring can be extracted (for example, P exceeds N), store zero at L.

24.6.10.(2) A programmer needed to move a group of N records from Source to Target, where
he assumed that the length of the record is defined by L'Rec. He wrote
MVC Target(N*L'Rec),Source
Under what circumstances will this work correctly, or not?

24.6.11.(2) What will happen in the instructions in Figure 200 on page 372 if the value of the
Length Expression exceeds 256?

24.7. The NC, OC, and XC Instructions

The logical instructions NC, OC, and XC perform the AND, OR, and XOR operations described
in Section 19 on two strings, byte by byte, leaving the result in the first operand string. The CC
is set as in Table 93 on page 289. These examples illustrate the three instructions.
1. Clear the 120-byte area at Line to binary zeros.
XC Line(120),Line Set 120 bytes to zero
We could have used the same technique here as in example 1 of Section 24.6 (by moving a
string of 120 zeroed bytes).
2. Branch to Yes if the fullword integer at Lump is zero.

376 Assembler Language Programming for IBM System z™ Servers Version 2.00
 OC Lump(4),Lump OR 4 bytes to each other
JZ Yes Branch if all bytes are zero
or
NC Lump(4),Lump AND 4 bytes to each other
JZ Yes Branch if all bytes are zero
The first and second operands are identical, so only only the CC is set; no data is changed.
This technique can sometimes be used when a register is not free.
Don't test a string of bytes for zero this way if the operand is memory-protected, because
both instructions store into the first operand.
3. Suppose there are two words named XX and ZZ that each contain four positive integers,
packed as illustrated in Figure 115 on page 249, shown here:

9 bits 4 bits 13 bits 6 bits

┌───────────┬──────┬───────────────┬────────┐
│ aaaaaaaaa │ bbbb │ ccccccccccccc │ dddddd │
└───────────┴──────┴───────────────┴────────┘
────A──── ──B─ ──────C────── ──D───

Replace the second integer in the word at XX by the corresponding value from the word at
ZZ.

MVC Temp,ZZ Move new value to temporary location

NC Temp,Mask Eliminate all but second integer
OC XX,Mask Set bits in 2d integer position to 1
XC XX,Mask Now set them to zeros
OC XX,Temp Insert new value into word at XX
- - -
Temp DS XL4 Temporary workspace
Mask DC XL4'00780000' Mask bits for 2nd integer position
Figure 204. Inserting bits in a word using logical SS-type instructions

4. Exchange the contents of the halfword integers at A and B. (Compare example 3 on page
373.)
XC B,A XOR A to B
XC A,B XOR B to A
XC B,A XOR A to B
- - -
A DS H
B DS H
This technique was used to exchange register contents in Exercise 19.5.1.*

Exercises
24.7.1.(2) Revise the instructions in Figure 204 to use two masks, two NC instructions, and
one OC instruction.

24.7.2.(2) A student suggested the following code sequence as a solution to the problem of
replacing data items embedded in a larger field:

* Which you solved correctly, of course.

Chapter VII: Bit and Character Data 377

 XC Old,New Make a mess of Old field
NC Old,Mask Zero space for New item
XC Old,New Now clean it all up
- - -
Old DC C'DOWNWITH'
New DC C'PINKNUDITY'
Mask DC 2X'FF',4X'0',2X'FF'
Verify that his method works, and discover the identity of the student.

24.7.3.(2) The bits in the byte at BitData are to be converted to a string of eight EBCDIC 0
and 1 characters starting at BitChars. A student suggested using these instructions:
LHI 1,8 Count 8 bits in GR0
IC 0,BitData Get the source byte
Repeat STC 0,BitChars-1(1) Store a byte at BitChars
SRL 0,1 Shift right by one bit
JCT 1,Repeat Iterate for all 8 bits
NC BitChars,=8X'1' AND off all but low-order bit
OC BitChars,=8C'0' OR makes EBCDIC 0 or 1 characters
- - -
BitData DC B'10010001' Sample source byte
BitChars DS CL8 Converted characters
Does this work? What will be found at BitChars? Explain your answer.

24.8. The CLC Instruction

CLC compares the first operand to the second operand one byte at a time, until either an ine-
quality is detected or the required number of bytes has been compared. As with CLI, each step
of the comparison is between unsigned 8-bit logical integers, and the CC settings are as shown in
Table 135 on page 355.
1. If the 120 bytes at Line contain blanks, branch to AllBlank.
CLC Line(120),=CL120' ' Compare to 120 blanks
JE AllBlank Branch if equal
or
CLC =CL120' ',Line Compare to 120 blanks
JE AllBlank Branch if equal
Because compare instructions modify neither operand, a literal can be used as the first
operand; this second method uses the Length Attribute of the literal as the Length
Expression.
2. Two non-negative word integers are stored at SS and TT. Branch to TBig if the number at
TT is larger than the number at SS. (The restriction to non-negative integers means that a
logical comparison gives the same result as an algebraic comparison.)
CLC TT(4),SS Compare c(TT) to c(SS)
JH TBig Branch to TBig if TT is greater
3. Two negative word integers are stored at SS and TT. Branch to TBig if the number at TT is
algebraically larger than the number at SS. (Because both integers are algebraically negative,
a logical comparison is the same as an algebraic comparison; see Exercise 24.8.1.)
CLC TT(4),SS Compare logically, and...
JH TBig Branch if c(TT) > c(SS)
4. A list of 100 names and occupations, each contained in a block of 60 bytes, is stored begin-
ning at List. Branch to Found if any of the blocks matches the name and occupation in the
block at WhoIsIt.

378 Assembler Language Programming for IBM System z™ Servers Version 2.00
 LA 1,List Initialize GR1 to A(first block)
LA 2,100 Set GR2 count to number of blocks
Test CLC 0(60,1),WhoIsIt Compare blocks
JE Found Branch if blocks are equal
LA 1,60(,1) Increment address by block length
JCT 2,Test Count down and branch
J NotFound No matching block was found

Exercises
24.8.1.(2) Example 3 above claims that a logical comparison of two negative integers gives the
same result as an algebraic comparison. Show that this is or is not true.

24.8.2.(3) + Write instructions using CLC to correctly compare arithmetically two signed word
integers in memory having arbitrary signs. For example, CLC should show that + 10 > − 10.
(It can be done!)

24.8.3.(2) Suppose we wish to test the string of 220 bytes at R to see if they all contain zero. It
is claimed that each of the following instructions will set the CC to zero if and only if the string
contains all zero bytes. For which of these instructions is the claim true?
(1) OC R(220),R
(2) NC R(220),R
(3) CLC R+1(219),R
(4) CLC R(220),=220X'0'

24.8.4.(2) + A programmer described the operation of the CLC instruction with the phrase “the
shorter operand is padded with blanks”. Give two reasons why this is incorrect.

24.8.5.(2) Write instructions to test a string of 72 bytes at Chars and branch to AllBlank if
every character is blank, without using a constant string of 72 blank characters. Use a CLC
instruction.

24.8.6.(2) + In Example 1 above, what would happen if you had written

CLC =120C' ',Line
instead?

24.8.7.(1) + What does this instruction do? Is it at all useful? If so, why?
CLC 1(7,4),0(4)

24.9. The TR (translate) Instruction

The Translate instruction replaces each byte in a string with any of another 256 possible values.
Like MVC, the TR instruction moves bytes from the second operand location to the first operand
location, but in a very different and possibly disorderly way. It actually performs a sort of
“pseudo-indexing”:
1. An “argument” byte is obtained from the first operand address.
2. The value of that byte (as an eight-bit unsigned integer) is added internally to the second
operand address, to access a “function byte” from the second operand.
3. The accessed function byte replaces the argument byte at the first operand address.146

146 In mathematical terminology, the TR operation can be thought of as replacing the argument bytes x1, x2, ..., xn by
the function bytes f(x1), f(x2), ..., f(xn). (Terminology aside, it's a simple operation.)

Chapter VII: Bit and Character Data 379

 4. The first operand address is incremented by one, and the process repeats until all first
operand bytes have been translated.
5. The Condition Code is unchanged.

For example, suppose the string of five argument bytes at PP contains X'0201040503', and the
character string at GG contains the character constant C'ABCDEF'. If we execute the instruction
TR PP(5),GG
then the final contents of the five bytes at PP will be C'CBEFD'. The first argument byte taken
from the first operand is X'02'; the function byte at GG+X'02' is C'C', and this replaces the first
byte at PP. Similarly, the fifth and last argument byte at PP is X'03'; the function byte at
GG+X'03' is C'D', which replaces the final byte in the string at PP.

Unlike the SS-type instructions we've seen thus far, the TR instruction can access bytes as far as
255 bytes away from the second operand address, whereas the other instructions accessed only
those bytes within the area whose length is determined by the Length Specification Byte.

A sequence of RX-type instructions simulating the TR instruction helps clarify its operation. In
Figure 205, the symbols L, B1, D1, B2, and D2 have the values from the TR instruction being
simulated. For this example, assume that B1 and B2 are not 1 or 2, because we will use those
registers in the simulation.

*Emulate TR D1(L,B1),D2(B2) Translate L bytes

LHI 0,L Set counter in GR0 to number of bytes
AHI 0,1 Get L; create program length N
SR 1,1 Set first operand index to zero
SR 2,2 GR2 Indexes table at 2nd operand
GetArg IC 2,D1(1,B1) Get argument byte from 1st operand
IC 2,D2(2,B2) Use as index to get function byte
STC 2,D1(1,B1) Store in string at 1st operand
AHI 1,1 Increment first operand index by 1
JCT 0,GetArg Loop until N argument bytes done
Figure 205. Emulating the T R instruction

You can appreciate the power of TR if you consider the example in Figure 167 on page 332 and
its variations. We wanted to replace all special characters with blanks. If we create an appropriate
translation or translate table, the entire process can be done with one TR instruction, as in
Figure 206.

TR Str(80),TRTable Translate all specials to blanks

- - -
TRTable DC (C'a')C' ' Anything less than C'a' is blanked
DC C'abcdefghi' Letters are unchanged
DC 7C' ' Non-printing characters are blanked
DC C'jklmnopqr' Print letters as is
DC CL8' ' More non-printing characters
DC C'stuvwxyz' Last of the lower-case letters
DC 23C' ' Blank anything between 'z' and 'A'
DC C'ABCDEFGHI' Letters are unchanged
DC 7C' ' Non-printing characters are blanked
DC C'JKLMNOPQR' Print letters as is
DC CL8' ' More non-printing characters
DC C'STUVWXYZ' Last of the upper-case letters
DC 6C' ' Blank anything between 'Z' and '0'
DC C'0123456789' Digits print okay
DC 6C' ' Tail-enders are blanked too
Figure 206. TR instruction to change special characters to blanks

380 Assembler Language Programming for IBM System z™ Servers Version 2.00
As a second example of the TR instruction, suppose we will need to print the contents of the
word at HexWord as eight hexadecimal digits, and we must place the eight EBCDIC characters
representing the hex digits in a string starting at Spred.

L 1,HexWord Get fullword to be converted

LA 2,Spred Address of character being stored
LA 3,8 Digit counter in GR3
Clear SR 0,0 Clear GR0 for shifting
SLDL 0,4 Shift a hex digit into GR0
STC 0,0(,2) Store in string at 'Spred'
LA 2,1(,2) Increment character address by 1
JCT 3,Clear Loop until 8 digits are stored
TR Spred,=C'0123456789ABCDEF' Translate to EBCDIC
- - -
Spred DS CL8 Converted result goes here
Figure 207. Translating hex digits to EBCDIC characters (1)

We can also index in the opposite direction, as in Figure 208.

L 0,HexWord Get fullword to be converted

LA 2,8 Counter and index in GR2
Shift SRDL 0,4 Shift a digit into GR1
SRL 1,28 Position for storing
STC 1,Spred-1(2) Store in character string
JCT 2,Shift Decrease index and shift again
TR Spred,=C'0123456789ABCDEF' Translate to EBCDIC
- - -
Spred DS CL8 Converted result goes here
Figure 208. Translating hex digits to EBCDIC characters (2)

This result is sometimes called “spread hex”; the UNPK instruction (in Section 27) does this
operation much more easily.

Exercises
24.9.1.(1) Assemble the translation table in Figure 206 on page 380 and verify that all non-
blank characters are in positions corresponding to their EBCDIC encodings, and that the trans-
late table is 256 bytes long.

24.9.2.(2) + Suppose the bits within each byte of a string of bytes are to be rotated to the right
by one bit position, so that B'10110001' becomes B'11011000'. Write a code sequence,
including a TR instruction and the necessary translate table, to do the rotations.

24.9.3.(2) The translation table in Figure 206 on page 380 uses hand-counted values for the
duplication factors on DC statements that generate blanks. Rewrite the table to use duplication
factors calculated by the Assembler based on the hexadecimal representations of the characters.

24.9.4.(4) A certain program needed to place each of the 80 characters in the string at InputRec
into an array of 80 words at A1Format in such a way that each successive word contains one
character from the string in its leftmost byte, followed by three blank characters. (This format
was used by some early Fortran compilers to read character data into a program.) Write a
program segment (in Assembler Language, of course!) to do this using TR instructions.

24.9.5.(2) + Write a short program segment which will use a TR instruction and an appropriate
table to interchange the positions of the two hex digits in a byte. How long must the table be?

24.9.6.(2) + Rewrite Exercise 22.5.1. to use a TR instruction and an appropriate translate table.
Are there any limitations on the length of the list? Explain your conclusion.

Chapter VII: Bit and Character Data 381

 24.9.7.(2) + Rewrite Exercise 17.4.6 to use a Translate instruction and an appropriate translate
table.

24.9.8.(4) Write a program segment to do the reverse of the action performed by your solution
to Exercise 24.9.4: the high-order bytes of each of the fullwords in the array at A1Format should
be collected into an 80-character string at OutRec.

24.9.9.(3) Assuming that only the valid EBCDIC characters shown in Table 13 on page 87 will
appear in the string, write statements to generate a translation table that will set all other char-
acters to blanks. Verify that your translate table is 256 bytes long.

24.9.10.(4) Write a sequence of instructions including TR that will cause the hex digits in a
string of bytes at Old to be “shifted right” by one digit position at New. That is, if we start with
X'123456' at Old, we should find X'012345' at New.
Then do the same for a left shift of one digit position; the result (starting with the same data)
would then be X'234560'.

24.9.11.(2) Suppose you must translate a very long record to contain all upper-case letters.
Assuming the record starts at Record and its length is found in the word at Reclen, write a
translate table and instructions that will do the translation.

24.9.12.(2) Suppose you must convert the 8 hex digits of c(GR9) to 8 EBCDIC characters
representing those digits, starting at GR9Hex. Will these instructions work? Explain why or why
not, and describe the intended function of the instructions named Q1, Q2, and Q3.
LHI 0,8
LA 1,GR9Hex
Repeat XR 8,8
SLDL 8,4
Q1 AHI 8,240
Q2 CHI 8,250
JL Store
Q3 AHI 8,-57
Store STC 8,0(,1)
AHI 1,1
JCT 0,Repeat
- - -
GR9Hex DS CL8

24.9.13.(2) + The string of characters at Text contains a mixture of lower-case and upper-case
letters, and its length in the halfword at TextLen is less than 256. Write instructions including
TR that will change the lower-case letters to their upper-case equivalents.

24.9.14.(2) Suppose the two bytes stored at Zone contain arbitrary bit patterns, represented as
X'wxyz'. Write a code sequence with one or more TR instructions which will convert the given
pair of bytes to the form X'Fxzy'. That is, interchange the two low-order digits, and replace the
high-order digit by X'F', no matter what its original value might have been. (This is similar to
the action performed by the UNPK instruction discussed in Section 27.)

24.9.15.(2) + If you execute the following TR instruction, what will you find in the operand
named OddTable when the instruction completes?
TR OddTable,OddTable Identical first and second operands
- - -
OddTable DC X'01000302050405'

24.9.16.(3) A student suggested the following instructions as a way to convert a string of bytes
at InString to pairs of EBCDIC characters at OutStrng representing the hex values of the
source data. That is, if the first source byte contains X'9F', the first two output characters will
be 9F.

382 Assembler Language Programming for IBM System z™ Servers Version 2.00
 XR 0,0 Clear a work register
XR 2,2 Input-byte index
XR 3,3 Output string index
LHI 4,L'InString Number of bytes to convert
Convert IC 0,InString(2) Get a source byte
SRDL 0,4 Shift right 4 bits
STC 0,OutStrng(3) Store leftmost hex digit
SRL 1,28 Move rightmost hex digit to end
STC 1,OutStrng+1(3) Store rightmost hex digit
AHI 2,1 Increment input index
AHI 3,2 Increment output index
JCT 4,Convert Repeat for all input bytes
TR OutStrng,=C'0123456789ABCDEF' Translate to EBCDIC
Does this work? What precautions should the student's program take?

24.9.17.(5) + In Exercise 17.3.16 you reversed the bits in a 32-bit word, using shift instructions.
Now, write a DC statement to create a translate table that will reverse the bits in each byte of a
string.

24.9.18.(5) Using your solutions to Exercises 24.9.3 and 24.9.17, write a sequence of
instructions using two TR instructions that will reverse both the bytes and the bits of the word
at DataWord and store the result at RevData. For example, if c(DataWord)=X'12345678', the
resulting c(RevWord) will be X'1E6A2C48'. (We'll see in Section 26 that there are easier ways
to reverse bytes.)

24.9.19.(3) Suppose you define this translate table:

X DC 256AL1(X'FF'-(*-X))
and the you execute this instruction:
TR X(256),X
What happens? If you repeat the instruction N times, will you ever get the original table at X?
If so, how many times?

24.9.20.(3) Repeat Exercise 24.9.19 with this translate table:

X DC 256AL1(*-X)
What happens? If you repeat the instruction N times, will you ever get the original table at X?
If so, how many times?

24.10. The TRT and TRTR Instructions

Whereas TR converts a sequence of byte values into new values, TRT and TRTR are used to
search a string of bytes for one or more specified values. These instructions are especially useful
in scanning for punctuation, delimiters, and erroneous characters.

As we saw for MVC and MVCIN, the first operand of TRT refers to the leftmost byte of the first
storage operand, while the first operand of TRTR refers to the rightmost byte of the first storage
operand.

The operation of TRT and TRTR is identical to TR through steps 1 and 2 on page 379, and
quite different thereafter.
3. The first operand is not modified; the accessed byte from the table addressed by the second
operand (the function byte) does not replace the argument byte from the first operand string.
Instead, the function byte is examined: if it is zero, we continue with step 4 of the description
of TR, incrementing (or decrementing) the first operand address and decrementing the count.
If the function byte is not zero,
• It is placed in the rightmost byte of GR2 (the rest of the register is unchanged);

Chapter VII: Bit and Character Data 383

 • The address of the argument byte which caused a nonzero function byte to be accessed is
placed in GR1 or GG1, depending on the addressing mode:
− in 24-bit mode, into the rightmost 24 bits of GR1, and the remaining bits of GR1 are
unchanged
− in 31-bit mode, into the rightmost 31 bits of GR1, and the leftmost bit of GR1 is set to
zero
− in 64-bit mode, into all the bits of GG1.
• The operation terminates, and the CC indicates the result of the operation, as shown in
Table 147.

CC Meaning
0 All accessed function bytes were zero.
1 A nonzero function byte was accessed before the
last argument byte was reached.
2 The nonzero function byte accessed corresponds to
the last argument byte.
Table 147. Condition Code settings for T R T and T R T R instructions

24.10.1. TRT
To illustrate the basic operation of TRT, suppose we must scan a string of characters to find the
address of the first numeric character. First, we create a translate table with zero function bytes in
all positions except for those corresponding to the EBCDIC representation of decimal digits,
where the function bytes are nonzero.
NumChar DC (X'F0')X'00',10X'01',6X'00'
Then, suppose we test the following strings using TRT:
String1 DC C'abc123def' Decimal digit before end of string
String2 DC C'*abcdef*' No decimal digits
String3 DC C'AB7' Decimal digit in final position
Then, after executing the following instructions, the contents of GR1, GR2, and the CC are as
shown:

Instruction c(GR1) c(GR2) CC

TR String1,NumChar A(String1+3) X'xxxxxx01' 1
TR String2,NumChar unchanged unchanged 0
TR String3,NumChar A(String3+2) X'xxxxxx01' 2

The xxxxxx characters mean that those portions of GR2 are unchanged when the X'01' function
byte is inserted.

As another example, suppose we must scan a string of 80 characters beginning at Record for the
punctuation characters period, comma, and apostrophe. When one of them is found, a branch
should be made to Period, Comma, or Apost respectively, with the address of that punctuation
character in GR1. If none is found, branch to NoPunct. First, we will write an example using
CLI instructions, but not TRT.

384 Assembler Language Programming for IBM System z™ Servers Version 2.00
 LA 1,Record Initialize character address
LA 2,80 Number of characters to examine
TestPunc CLI 0(1),C'.' Compare to period
BE Period Branch if found
CLI 0(1),C',' Compare to comma
BE Comma Branch if found
CLI 0(1),C'''' Compare to apostrophe
BE Apost Branch if found
AHI 1,1 Otherwise increment address by 1
JCT 2,TestPunc Count and loop
B NoPunct Branch if none were found
Figure 209. Searching for punctuation characters using CLI

The TRT instruction does the same processing much more rapidly, but at the cost of memory
space for the translate table.

SR 2,2 Clear GR2, to be used as an index

TRT Record(80),PuncTbl Scan for punctuation
JZ NoPunct Branch if none found
B *(2) Function byte is index for branch
J Period Period
J Comma Comma
J Apost Apostrophe
PuncTbl DC (C'.')X'00',X'04' Function byte 4 for period
DC (C','-C'.'-1)X'00',X'08' 8 for comma
DC (C''''-C','-1)X'00',X'0C' 12 for apostrophe
DC (255-C'''')X'00' Remainder of table
Figure 210. Searching for punctuation characters using T R T

The three nonzero function bytes are at positions in the table corresponding to the values of the
EBCDIC representations of the characters being sought. The function values are multiples of
four so they can be used to index the branch instruction B *(2). If the conditional branch to
NoPunct had been omitted, GR2 might contain zero and the program could have gone into an
infinite loop at the B instruction.

This translate table was constructed by observing that we need not know the values of the
EBCDIC representations of the period, comma, and apostrophe, only that their representations
are in ascending order. This means that (for example) the number of characters between the
period and the comma is the positive quantity (C','-C'.'+1).

Suppose your program has received a string of decimal characters into a field named InputNum.
Before using the data, it's a good practice to validate it. (Data validation helps avoid errors and
program interruptions that may occur much later in your program.) Figure 211 shows one way
to do this.

TRT InputNum,ValidDec Test for all numeric data

JZ Valid Branch to process valid data
JNZ ReEnter Something invalid, ask for re-entry
- - -
ValidDec DC (C'0')X'01' Values < X'F0' are invalid
DC 10X'00',6X'01' Values > X'F9' are invalid
InputNum DS CL12 Numeric characters?
Figure 211. Using T R T to validate numeric characters

As another example of the TRT instruction, suppose we are required to scan the quoted character
string starting at Sentence for the occurrence of an embedded character string containing either
apostrophes (as in ″She said, 'Never!'″), or quotation marks (as in 'I said, ″I won't″'). As
these examples indicate, the other delimiter may appear freely inside the outer string.

Chapter VII: Bit and Character Data 385

 If such an embedded string exists, we must store its starting address (excluding the preceding
delimiter) at StrAddr and its length in bytes (again excluding the delimiters) at StrLen. (For the
first string, the result would be the 10 characters She•said,•). If no string exists, branch to None,
and if the apostrophe or quotation mark which would terminate the string is missing, branch to
Unfin. Assume the length of the data string to be scanned is stored at SentLen, and is 256 or less.
The program segment in Figure 212 scans first for the starting delimiter; when it is found, the
proper table is chosen to search for the ending delimiter.

LA 1,Sentence Starting data address in GR1

L 2,SentLen Fetch length to scan, and...
BCTR 2,0 Decrement by 1 for length byte,
STC 2,TRT1+1 Store in TRT1 instruction.
LA 3,0(2,1) C(GR3) = A(last data byte)
SR 2,2 Clear GR2 for function byte
ST 2,StrLen And set result length to 0
TRT1 TRT 0(*-*,1),T Scan for first delimiter
JZ None Exit if nothing useful found
LA 4,1(,1) Step over starting delimiter,
ST 4,StrAddr And store string start address.
LastCh JC 2,Unfin Exit if that's all there was
LA 1,1(,3) C(GR1) = A(last data byte)+1
SR 3,4 (length-1) of rest of data
STC 3,TRT2+1 Store in length byte of TRT2
L 3,TAdd-4(2) Address of correct table in GR3
SR 2,2 Reset GR2 for function byte
TRT2 TRT 0(*-*,4),0(3) Scan rest of data with new table
SetLen S 1,StrAddr Subtract start address of string
ST 1,StrLen And store result string length
LTR 2,2 Test for closing delimiter found,
JZ Unfin Branch if not found.
- - -
StrLen DS F Length of final string
StrAddr DS A Address of final string
TAdd DC A(T2,T3) Table addresses
T DC 125X'0',X'040008',128X'0' Initial TRT table
* Function byte = 4 for apostrophe, 8 for quotation mark
T2 DC 125X'0',X'4',130X'0' Stop on apostrophe
T3 DC 127X'0',X'4',128X'0' Stop on quotation mark
Figure 212. Using T R T to scan for embedded quotations

Several items in Figure 212 deserve comment.

• The two STC instructions modify the TRT instructions at TRT1 and TRT2. The Execute
instruction in the next section shows a much better way to do this.
• The expression *-* in the instructions named TRT1 and TRT2 is the Location Counter value
subtracted from itself, which is always zero. This notation is often used to indicate that the
contents of the field will be provided by the program at execution time.
• By storing zero at StrLen before scanning the string (just preceding TRT1), we have taken care
of the possibility that the initial delimiter may have been the last character in the data string;
this condition is detected by the conditional branch instruction named LastCh.
• The function byte in the table named T is used by the Load instruction just preceding the
second TRT as an index to load into GR3 the address at TAdd of the desired secondary table.
• By presetting GR1 to the address of the byte immediately following the data string, we can
complete the scan with the second TRT as follows. If a closing delimiter exists, GR1 will
eventually point to it, and the instruction named SetLen will calculate the number of bytes
between the delimiters; GR2 will then contain the nonzero function byte X'04'. However, if
no closing delimiter is found, GR1 and GR2 are unchanged, and we can still compute a useful
string length before exiting to Unfin.

386 Assembler Language Programming for IBM System z™ Servers Version 2.00
As a final example using TRT to scan variable-length data, suppose a string of characters at Names
contains names separated by commas and terminated by a period. We will construct at List a
table of fullword addresses of the first character of each name, followed by a word containing the
number of characters in that name, which is known to be less than 256. When the table is com-
plete, the number of names is stored in the word at NbrNms. To protect against omitted punctu-
ation or other errors, we will branch to LongName if no comma or period is found within 256
characters of the start of a name. No tests are made for repeated names.

MaxNames Equ 50 Assume at most 50 names found

SR 3,3 GR3 contains index for list
SR 2,2 Clear function-byte switch in GR2
LA 1,Names Initialize scan address
Scan LR 4,1 Save initial character address
TRT 0(256,1),TRTB Scan for period or comma
JZ LongName Branch if no punctuation found
ST 4,List(3) Store address of name in list
SR 1,4 Compute name length
ST 1,List+4(3) Store length of name, too
LA 3,8(,3) Increment list index
LA 1,1(4,1) Move GR1 to start of next name
JCT 2,Scan Branch if comma was encountered
SRL 3,3 If period, compute and store ..
ST 3,NbrNms ...the number of names found
- - -
TRTB DC (C'.')X'00',X'01' Function = 1 for period
DC (C','-C'.'-1)X'00',X'02' Function = 2 for comma
DC (255-C',')X'00' Zero otherwise
- - -
Names DC C'Brown,Green,Wonka,Ofstrand,Jones,Smedley,Doe,'
DC C'Apple,Doe,Smithwich,Softnard,Smith,Doelful,'
DC C'Lostkind,Jones,Lurp,VonHimmelsBergenSchneider,Doe.'
NbrNms DS F Number of names found
List DS (2*MaxNames)A Table for addresses and counts
Figure 213. Using T R T to scan a string of names and build an occurrence list

The only unusual feature of Figure 213 is using the function byte as a branching switch: if a
period is encountered, GR2 will contain + 1, and the JCT instruction will not branch.

24.10.2. TRTR
The test in Figure 211 on page 385 can be done with TRTR and the same translate table:

TRTR InputNum+L'InputNum-1,ValidDec Test for numeric data

JZ Valid Branch to process valid data
JNZ ReEnter Something invalid, ask for re-entry
- - -
Figure 214. Using T R T R to validate numeric characters

Programs often must analyze character strings, finding “tokens” to be processed individually. But
how do you know when there is no more data in the string, and the rest of the string is blanks? A
common technique is to scan backwards from the end of the string, searching for the last non-
blank character in the string. This is sometimes done with a CLI instruction:

Chapter VII: Bit and Character Data 387

 LA 1,String+L'String-1 Address of end of string
Check CLI 0(1),C' ' Check for a blank
JNE Done Exit loop if nonblank
BCTR 1,0 Reduce address by 1 byte
J Check And check again
Done - - - GR1 points to last nonblank
Figure 215. Scanning a string backward using CLI

This scan can also be done (perhaps more quickly) using a TRTR instruction:

TRTR String+L'String-1,BlankTbl Scan backward

JZ AllBlank Problem: string is all blanks
- - - GR1 points to last nonblank
BlankTbl DC (C' ')X'1',X'0',(256-C' '-1)X'1'
Figure 216. Scanning a string backward using T R T R

While this may appear to use more memory than a CLI loop, translate tables like this are often
used in many different places, so a single table can be referenced by many instructions.

Exercises
24.10.1.(1) Verify that the translate table in Figure 210 on page 385 generates exactly 256
bytes, and that the nonzero entries are at offsets corresponding to the EBCDIC representations
of the punctuation characters.

24.10.2.(2) Show that the ORG instruction can be used to build the Translate and Test table of
Figure 213 on page 387 as follows:
TRTB DC XL256'0' Define table, length 256
ORG TRTB+C'.'
DC X'1' Function byte for period
ORG TRTB+C','
DC X'2' Function byte for comma
ORG TRTB+256 Reset LC to end of table
Use this technique to construct the table in Figure 210 on page 385. Why is this method
superior to the one used in Figures 210 and 213? Can the first DC be replaced by DS?

24.10.3.(2) In Figure 212 on page 386, the length byte in the second TRT is calculated by the
“SR 3,4” just preceding it. Is there any reason why the result of the subtraction cannot be
negative? What would happen if it was?

24.10.4.(2) In Figure 212 on page 386, three distinct translate tables were used: one to scan for
an initial apostrophe or quotation mark, and the other two to scan for the matching delimiter
at the end of the quoted string. Rewrite the example to use a single translate table, which is
suitably initialized for each use by instructions such as
XC T(256),T Set entire table to zero
MVI T+C'''',4 Set to stop on apostrophe

24.10.5.(4) + In Figure 212 on page 386, there are three translate tables. Show how these tables
can be overlapped in a way that requires only about one-half as much space.

24.10.6.(2) Write instructions to scan the string of 120 characters at CharData and leave in GR1
the address of the first character that is neither alphabetic nor numeric.

24.10.7.(2) In Exercise 23.4.3 you scanned a character string at Record to locate the last non-
blank character. Do the same exercise, but this time use MVCIN and TRT instructions instead
of CLI.

24.10.8.(2) In Figure 212 on page 386, why is it necessary to reset GR2 to zero before exe-
cuting the second TRT?

388 Assembler Language Programming for IBM System z™ Servers Version 2.00
 24.10.9.(2) The translate table in Figure 216 on page 388 is defined with a single DC state-
ment. Verify that it generates the desired data.

24.10.10.(3) Modify the coding in Figure 213 on page 387 to store each name only once, and
add a word to each name's entry in the list giving the number of occurrences of that word.

24.10.11.(2) + Show the contents of GR2 and the Condition Code setting after executing the
following instructions:
SR 2,2
TRT XX,=XL5'20100'
- - -
XX DC X'0004010203'

24.10.12.(3) + Some experiments have shown that trailing blanks can be removed more effi-
ciently than in Figures 215 and 216 by starting at the end of the string and comparing to a
doubleword of blanks until a mismatch occurs, and then using a backward CLI scan. Write an
instruction sequence to implement this technique to truncate the string starting at String
having length L, and store the truncated length of the string in the halfword at TruncLen.

24.10.13.(2) Revise Exercises 24.7.3 and 24.10.7 to use a TRTR instruction.

24.10.14.(2) + In Figure 215 on page 388, what will happen if the content of String is all
blanks?

24.11. The Execute Instructions

While the Execute instructions are not SS-type, they are often used with SS-type instructions to
help process character data.

Op Mnem Type Instruction Op Mnem Type Instruction

44 EX RX Execute C60 EXRL RIL Execute Relative Long
Table 148. Execute instructions

The two Execute instructions in Table 148 are unusual, because they specify the execution of
another instruction at a different address! We will use some concepts of the basic instruction cycle
described in Section 4 and illustrated in Figure 13 on page 50.

These instructions are executed using these steps:

1. The Effective Address is computed, and the R1 digit of the Execute instruction is saved.
2. The instruction at the Effective Address, the target (or subject) instruction, is placed into the
Instruction Register (IR), replacing the EX or EXRL. The Instruction Address in the PSW is
unchanged, and still contains the address of the instruction following the Execute.
3. If the new instruction in the IR is another execute instruction, a program interruption occurs,
and the Interruption Code in the old PSW is set to 3. (There is a good reason for this inter-
ruption, as we'll see shortly.)
4. If the R 1 digit of the Execute instruction was zero, proceed to step 5. Otherwise, the right-
most byte of general register R1 is ORed into the second byte of the IR. Both GR R 1 and
the target instruction in memory remain unchanged.
5. The (possibly modified) target instruction in the IR is now decoded and executed as though
it was the original instruction fetched from memory.

If the target instruction in the IR does not change the IA in the PSW (it is not a successful
branch instruction), execution continues with the instruction following the Execute. If the target
instruction does change the IA in the PSW (it is a successful branch), execution will continue
with the instruction at the branch address. The CC is changed only if the target instruction sets
the CC.

Chapter VII: Bit and Character Data 389

 24.11.1. Execute Instruction Without Target-Instruction Modification
To illustrate uses of EX and EXRL, we first consider examples where the R1 digit is zero, so that
no ORing occurs in the IR.
1. Store at CCC the quantity 2*C(A)-C(B), where A and B are the names of words in memory.

SR 1,1 Clear index to zero

LA 2,4 Increment = 4, instruction length
LA 3,12 Comparand = 12
Execute EX 0,Inst(1) Execute an instruction
JXLE 1,2,Execute Increment by 4 and loop
- - -
Inst L 0,A Load GR0 from A (4-byte instruction)
AR 0,0 Double c(GR0) (2-byte instruction)
NOPR 0 2 bytes spacing
S 0,B Subtract c(B) (4-byte instruction)
ST 0,CCC Store result (4-byte instruction)
Figure 217. Executing a list of instructions

This program segment does four simple instructions the hard way, and merely illustrates a
way to execute instructions which are “out-of-line”, and not directly in the normal stream of
program execution. The list of instructions at Inst could be executed independently of the
first five instructions by branching to Inst, giving the same result much more rapidly.
2. Suppose we wish to add the three word integers stored beginning at Q. Depending on the
number of overflows: if no overflows occur, multiply the result by 10; if one overflow occurs,
do nothing; and if two overflows occur, set the result to 1.

SR 1,1 Clear overflow counter in GR1

L 0,Q Get first integer
A 0,Q+4 Add second integer
JNO NoOfloA Branch if no overflow
AHI 1,4 Indicate one overflow
NoOfloA A 0,Q+8 Add third integer
JNO NoOfloB Branch if no overflow
AHI 1,4 Indicate another overflow
NoOfloB EX 0,FixIt(1) Execute correct operation
ST 0,Result And store result
- - -
FixIt MH 0,=H'10' Multiply by 10
NOP 0 Do nothing
LA 0,1 Set result to +1
Figure 218. Executing a list of instructions

3. Suppose we must place in GR6 the address of some byte in memory, and that the desired
address is known only to be the Effective Address of some other RX-type instruction. To
make matters more complicated, suppose also that the addressing calculation needed by the
RX instruction could make use of any registers but R14 and R15; that is, the base and index
digits can be anything from 0 to 13. We assume that GR15 is currently being used for a base
register, and that GR14 contains the address of the RX instruction in question.
We will construct a LA instruction in a work area with the same index, base, and displace-
ment fields as the RX instruction, and then execute that LA instruction.

390 Assembler Language Programming for IBM System z™ Servers Version 2.00
 MVC MakeLA(4),0(14) Move original RX inst'n to work area
NI MakeLA+1,X'0F' Clear old R1 digit position
OI MakeLA+1,X'60' Set new R1 digit to 6
MVI MakeLA,X'41' Set 'LA' opcode into instruction
* Contents of MakeLA is now 416xbddd
EXRL 0,MakeLA Execute the constructed 'LA'
- - - GR6 now has the desired address
MKLA DS 2H 4 bytes on halfword boundary
Figure 219. Constructing an executed instruction

This instruction sequence changes no registers other than GR6, even though R0 could have
been used in the instruction sequence without affecting the operation of the EX, because
GR0 or GG0 could not have been used by the LA as a base or index register. This illustrates
a technique you can use when all other register contents must remain unchanged.

24.11.2. Execute Instruction with Target-Instruction Modification

The Execute instructions are most useful when the R1 digit is not zero, implying modification of
the target instruction in the IR.
1. Suppose we wish to move to Line a message whose address and length are in GR8 and GR9
respectively, as in example 4 on page 373.
BCTR 9,0 Decrease Length Expression by 1
EX 9,Move Execute the MVC instruction
- - -
Move MVC Line(*-*),0(8) Executed instruction, length = 0
The Length Specification Byte in GR9 is ORed into the proper position in the (target) MVC
instruction in the IR. In the assembled MVC instruction, the length byte was preset to zero
by a zero explicit Length Expression. A major advantage of this method is that the instruc-
tion in storage is unmodified, an important consideration in writing re-enterable code.
This is a very typical use of an Execute instruction.
2. Suppose we must branch to Yes if the rightmost byte of GR3 contains B'00011111'.
EX 3,CLI Execute the comparison
BE Yes Branch if equality is found
- - -
CLI CLI ChkBits,0 Executed instruction
ChkBits DC B'00011111' Comparison quantity
The same problem could be solved without using EX, but extra storage accesses would be
required:
STC 3,Temp Store the byte to be tested
CLI Temp,B'00011111' Compare to desired pattern
JE Yes Branch if equal
- - -
Temp DS X Byte from GR3 to be tested
3. Store at RegTotal the sum of the contents of registers GR0 through GR10.
LA 12,10 Count in GR12
Loop EX 12,Adder Execute add instruction, sum in GR0
JCT 12,Loop Decrease counter and register digit
ST 0,RegTotal Store sum at RegTotal
- - -
Adder AR 0,0 R2 digit modified by EX
The R 2 digit of the AR instruction is modified in the IR to contain values from 10 to 1. It is
rare to use Execute instructions to modify register specification or mask digits of executed
instructions.
4. The fullword at Mask contains an integer whose value lies between 0 and 15, to be used as the
mask digit of a BC instruction branching to CondMet.

Chapter VII: Bit and Character Data 391

 L 1,Mask Get mask value
SLL 1,4 Position correctly as M1
EX 1,BCInst Execute the BC
NotMet - - - Fall through if condition not met
- - -
BCInst BC 0,CondMet BC with mask of 0
To complete execution of the EX instruction, the mask digit in the rightmost byte of GR1 is
ORed into the BC instruction in the IR. The branch condition is now determined in the
usual way; if it is met, the branch address of CondMet will be placed into the IA in the PSW.
The execution of a successful branch instruction causes control to be “taken away” from the
EX instruction.
5. Branch to OddVal if the rightmost bit of GR9 is a 1-bit (that is, the number in GR9 is odd).
EX 9,TMInst Execute a TM instruction
JNZ OddVal Branch if a 1-bit
- - -
TMInst TM OneBit,0 Test all 8 bits of next byte
OneBit DC B'00000001' Only rightmost bit = 1
In the IR, the rightmost byte of GR9 becomes the mask byte (the immediate operand, I2) of
the TM instruction. This mask then tests whatever bits of the byte at OneBit correspond to
1-bits in the mask. If the rightmost bit of GR9 is a 1-bit, the tested bits will not be all zero,
and the branch to OddReg will occur. (There are much easier ways to do this test!)
6. As a final (and more practical) example, suppose GR5 contains an integer specifying the
number of bytes to be moved from a string beginning at AA to an area whose address is con-
tained in GR7. The number of bytes may be greater than 256.

LTR 5,5 Test number of bytes to be moved

BNP Finis Exit if not greater than zero
LA 1,AA GR1 contains 'from' address
Test CHI 5,256 See if byte count exceeds 256
JL Last If not, do last part of move
MVC 0(256,7),0(1) Move 256 bytes
AHI 1,256 Increment 'from' address
AHI 7,256 Increment 'to' address
AHI 5,-256 Decrease byte count by 256
JNZ Test If not zero, go try again
J Finis If count is zero, all done
LMVC MVC 0(0,7),0(1) Move last part of byte string
Last BCTR 5,0 Decrease byte count by 1 for ex
EX 5,LMVC Move last part of string
Finis - - - Rest of program goes here
Figure 220. Moving a string of bytes of unknown length

In Section 25, we will see how the MVCL and MVCLE instructions can handle such “long”
moves more simply.

Using an EX instruction to supply the length byte for an SS-type instruction is its most common
application.

24.11.3. Comments on the Execute Instructions (*)

1. The reason that an Execute instruction may not be the target of an Execute instruction (as
stated in step 3 on page 389) is that the CPU could remain in a Fetch-Decode loop (com-
prising steps 1 through 4 of the Execute-instruction description) if the Execute instruction
tried to execute itself, or if a chain of Execute instructions was circular. That is, consider what
could happen if the instruction
EX 0,* What are we doing, and why???

392 Assembler Language Programming for IBM System z™ Servers Version 2.00
 is allowed. This loop is very awkward for a CPU to stop, and is avoided simply by not
allowing Executes of Execute instructions.147
2. When possible, place the target of an Execute instruction close to the EX.148
3. Be very careful when executing instructions with 12-bit opcodes, such as AHI. The low-order
digit of the R1 register should be zero, to avoid changing the opcode of the target.
4. Instructions that form Effective Addresses relative to an executed instruction use the address
of the target, not the address of the Execute instruction itself. For example, suppose GR9
contains a branch mask value in the next-to-rightmost hex digit, and we execute a Branch
Relative instruction:
EX 9,GoToXYZ Execute the relative branch
- - -
GoToXYZ BRC *-*,XYZ Branch if CC matches the mask bits
The CPU determines the Effective Address of the BRC instruction relative to its address, not
the address of the EX.
5. The Execute instruction was sometimes described as a special branch instruction! It is said
that EX causes an unconditional branch to the target instruction, followed by an uncondi-
tional branch back to the instruction following the EX, unless the target instruction is itself a
successful branch.
This incorrectly describes the contents of the Instruction Address, which remains at the
address of the instruction following the EX, and obscures the modification of the second byte
of the target instruction. This is sometimes described by saying “the instruction is modified,
but remains unchanged in memory”.
Both descriptions are misleading.

While this discussion of the IR may not be exactly what's done in System z processors, it does
describe the effect of the instruction, and gives a better feel for the way the CPU executes its
instructions. You need not believe in the “magic” of an instruction being simultaneously modi-
fied and remaining unmodified.

24.11.4. Modifiable Parts of Instructions

The highlighted parts of the operands in the instructions listed in Table 149 on page 394 indicate
the modifiable portions of typical instruction types as targets of the Execute instructions.

147 This is a fact of computing life that was learned the hard way: on some early processors, the only “fix” was to turn
off power and restart the machine. I knew a graveyard-shift computer operator on an older machine who discovered
how to create an Execute loop. Then, he would file a “Computer Trouble Report” for the engineers, and go home
early.
148 Some programmers use an “idiom” like this:
LA 1,N Number of bytes to move
BCTR 1,0 Make it a machine length
MVC A(*-*),B Move only 1 byte from B to A
EX 1,*-6 Move all N bytes from B to A
This is not generally recommended, because the CPU must process the MVC instruction twice.

Chapter VII: Bit and Character Data 393

 Type Operands Modifiable
RR R1,R2 R 1,R 2
RX, RXY R1,D 2(X 2,B 2) R 1,X 2
R1,R3,D 2(B 2) R 1,R 3
RS, RSY R1,M 3,D 2(B 2) R 1,M 3
R1,D 2(B 2) R1
SI, SIY D 1(B 1),I2 I2
D 1(L,B 1),D 2(B 2) L
SS D 1(L1,B 1),D 2(L2,B 2) L 1,L 2
D 1(L1,B 1),D 2(B 2),I3 L 1,I 3
SSF R3,D 1(B 1),D 2(B 2) R3
R1,I 2 R1
RI
M 1,I 2 M1
Table 149. Modifiable portions of typical EX target instructions

Because the second byte of some instructions contains part of the operation code, there is usually
little reason to execute those instructions with a nonzero R1 digit.

Exercises
24.11.1.(2) What is the relationship between the USING statements in effect when an EX
instruction is assembled, and those in effect when the target instruction is assembled?

24.11.2.(2) + A programmer believed that EX “branches to the target instruction, and then
branches back to the instruction following the EX if the target instruction was not a successful
branch”. Consider the following code sequence:
EX 0,BASR1
Here - - -
- - -
BASR1 BASR 1,0
There - - -
What would he claim to be in GR1 after the EX is executed? What will be in GR1?

24.11.3.(2) + Suppose control passes to the following sequence of instructions:

LA 1,BStar
EX 0,BASR1 Execute the BASR instruction
LR 0,0 Do nothing in particular
BStar B * Wait here for answer
BASR1 BASR 1,0 Do something, maybe
AR 0,0 Also do nothing in particular
B BStar Branch to waste some cycles
When control arrives at BStar, the address of some instruction should be in GR1. What is it?
What will be the value of the Instruction Length Code immediately after the EX instruction
has completed execution?

24.11.4.(2) + Rewrite Exercise 17.2.9 to use an EX instruction and eight TM instructions to test
the proper bit of the selected byte.

24.11.5.(3) We must move a number of bytes from a string whose starting address is contained
in GR1, to a string whose starting address is contained in GR2. The number of bytes to be
moved (which can be greater than 256) is in GR3. Write a code sequence to perform the
move.

24.11.6.(3) + Suppose you must scan a string of length L (where L ≤ 200) bytes starting at
DCData that may contain paired ampersands and apostrophes (as in a C-type character con-

394 Assembler Language Programming for IBM System z™ Servers Version 2.00
stant). Write instructions to scan the string and move it to DCGen with each paired occurrence
replaced by a single occurrence. Store the length of the resulting string at DCGenL.

24.11.7.(2) In Exercise 24.9.13 on page 382, the string at Text was assumed to be shorter than
256 characters. Repeat the exercise, now assuming that the string's length may be up to 14000
characters.

24.11.8.(3) + A string of M characters at Data is to be moved to an N-byte area named DataPad

and extended or “padded” with blanks if N > M. Assume that both M and N are ≤ 256, and
have been defined in EQU statements. If N < M, move only N bytes. (Don't use MVCL or
MVCLE!)

24.11.9.(3) In Exercise 24.8.4 on page 379, you explained why CLC does not pad the shorter
operand with blanks. Write an instruction sequence that simulates the operation of a “CLC”
instruction that does pad the shorter operand with blanks. Your instructions must set the Con-
dition Code correctly.

24.11.10.(3) Parentheses are used in many programming languages to enclose expressions,

denote groupings, and so forth. These parentheses must be balanced: that is, they must
“match up” so that (1) each left parenthesis has a matching right parenthesis that follows it
somewhere, (2) the leftmost parenthesis must be a left parenthesis, and (3) it must be matched
by the rightmost parenthesis. More formally, if L(n) and R(n) are the number of left and right
parentheses encountered after scanning n characters, and if there are N characters in the string,
then a balanced string must have L(n)≥ R(n) for 0 < n < N, and L(N)=R(N).
Using appropriate TRT and EX instructions, write a program segment which will test a string
of characters for balanced parentheses. Assume initially that GR7 contains the address of the
string, and its length in bytes is a 32-bit binary integer in GR8. Branch to Balanced and
Unbalncd for successful and unsuccessful scans, respectively.

24.11.11.(2) + Modify the illustration of the fetch-decode-execute cycle in Figure 16 on page 55

to show how the Execute instruction and its target instruction are fetched and decoded. Indicate
explicitly where the test for an Execute exception is made.

24.11.12.(2) Suppose the bits within the byte stored at Rotator are to be rotated to the right N
bit positions, where N is defined by the three low-order bits in GR1. Write a code sequence,
including the necessary translate table or tables, to do the shift.
Can you devise a table which will accomplish the shift by executing only a single TR instruc-
tion?

24.11.13.(2) + In example 5 on page 392 in Section 24.11.2, we want to test for the presence of
a 1-bit in GR9. What will happen if the branch instruction is JO instead of JNZ?

24.11.14.(2) How can the code sequence in example 5 of Section 24.11.2 be modified to test if
the contents of some register is a multiple of a given power N of 2? What are the limitations on
this technique?

24.11.15.(2) + A programmer used an EX instruction to load the constant 137 into a general
register whose number was determined at execution time. He knew that the number of the
target register would be in the rightmost 4 bits of GR1, and wrote
EX 1,LHIOp Load the constant into a GPR
- - -
LHIOp LHI 0,137 Executed: load into the target GPR
This won't do what he wants. Explain why not, and show what he should have written.

24.11.16.(2) Write a code fragment using an Execute instruction that will convert the byte at
Byte to 8 EBCDIC characters starting at Char that represent the value of its 8 bits.

24.11.17.(2) Modify the coding in Figure 212 on page 386 to use EX instructions where appro-
priate.

Chapter VII: Bit and Character Data 395

 24.11.18.(3) + Suppose your CPU has no MVCIN instruction, and you want to move the string
of L characters starting at Source to the string of L characters starting at Target in reverse
order. Assuming that 0 < L < 256 is a number in GR0, create an appropriate translate table
and instructions that will move the characters as required.

24.11.19.(2) + If c(GR1) = X'FEDCBA98', and you then execute this instruction:

EX 1,Sub
- - -
Sub SR 5,2
what SR instruction will the CPU actually execute?

24.11.20.(2) How can an EX instruction choose one of multiple possible target instructions in a
single execution?

24.12. Summary
Remember:
The length you code in an SS-type assembler instruction statement (N)
specifies how many bytes are involved (unless you code zero, in which
case one byte always participates in the operation). The length you
specify as the R1 operand of an EX instruction (L) is one less than the
number of bytes involved.

For most instructions, operand overlap is not a problem.

• If neither operand is changed (for example, by CLC and TRT), operand overlap doesn't
matter.
• Most instructions operate as though the bytes of the source operand are fetched one at a time,
and the result byte is stored at the target operand before the next source byte is fetched.149
• For other instructions, operand overlap can lead to unpredictable results.
We'll note special cases as they arise.
Table 150 summarizes Table 142 on page 367 and Table 143 on page 368 about explicit and
implied length specification in single-length SS-type instructions:

Explicit Length Implied Length

S1(N),S 2 S1,S2
D 1(N,B 1),S2 D 1(,B1),S2
S1(N),D 2(B 2) S1,D 2(B 2)
D 1(N,B 1),D 2(B 2) D 1(,B1),D 2(B 2)
Table 150. Operands of single-length SS-type instructions

The instructions discussed in this section are shown in Table 151 on page 397.

149 Modern processors may fetch, process, and store groups of several bytes, but the result still appears to be byte-at-a-
time operation.

396 Assembler Language Programming for IBM System z™ Servers Version 2.00
 Function Instruction Data is Processed CC Set?
MVC Left to right
Move No
MVCIN Right to left
Move MVCOS Left to right Yes
AND NC Left to right Yes
OR OC Left to right Yes
XOR OC Left to right Yes
Compare CLC Left to right Yes
Translate TR Left to right No
Translate and Test TRT Left to right Yes
Translate and Test TRTR
Right to left Yes
Reverse
EX
Execute — Depends on target
EXRL
Table 151. Basic instructions for data in storage

Instructions Discussed in this Section

The instruction mnemonics and opcodes are shown in the following table:

Mnemonic Opcode Mnemonic Opcode Mnemonic Opcode

CLC D5 MVCIN E8 TR DC
EX 44 MVCOS C80 TRT DD
EXRL C60 NC D4 XC D7
MVC D2 OC D6

The instruction opcodes and mnemonics are shown in the following table:

Opcode Mnemonic Opcode Mnemonic Opcode Mnemonic

44 EX D4 NC DC TR
C60 EXRL D5 CLC DD TRT
C80 MVCOS D6 OC E8 MVCIN
D2 MVC D7 XC

Terms and Definitions

IR
Instruction Register; an internal register holding a target instruction so its second byte may
be modified by an Execute instruction prior to decoding.
Length Expression
A value (N or LE) coded implicitly or explicitly in a machine instruction statement for an
SS-type instruction, from which the Assembler derives the Length Specification Byte L.
Length Specification Byte
The second byte (L) of an SS-type instruction, one less than the length of its operand or
operands.

Chapter VII: Bit and Character Data 397

 target instruction
An instruction addressed by an Execute instruction.

Programming Problems
Problem 24.1.(2) Using the definitions in Exercise 24.11.10, write a program which will read
character strings from records and test for balanced parentheses. Print each string and a message
which indicates whether or not it is balanced. Assume that the first blank character ends the
character string.

Problem 24.2.(3) A “perfect shuffle” of a deck of 52 playing cards interleaves each card of the
top 26 cards with each card of the bottom 26, in exactly the same way for each shuffle.150 Thus,
after a single shuffle the order of the cards is 1, 27, 2, 28, ... 25, 51, 26, 52.
It is claimed that after a small number (less than 10) of perfect shuffles, the original order of the
cards is restored. Test this claim by writing a program using a TR instruction to perfectly
shuffle the numbers from 1 to 52. The results may be displayed in hexadecimal.
Just for fun, try your program for different (even!) numbers of “cards” to see how many shuf-
fles are needed to recover the original order.

Problem 24.3.(3) Write a program to read 80-character records that should contain only
EBDCIC decimal digits or blanks. If any invalid character is found, display the record and the
column number where the invalid character was found.

Problem 24.4.(4) In storing data containing large numbers of characters, it is often useful to find
some way to “compress” the data. For example, if the data consists of 80-byte records that
rarely contain 80 nonblank characters, space might be saved if we discard the trailing blanks
(following the last nonblank character on the record, and place a control byte at the beginning
that gives the length of the remaining string. Thus, a record containing only an asterisk in
column 1 would be stored as the two bytes X'015C', a saving of 78 bytes.
Many such compression schemes exist, and they can be simple or elaborate depending on the
needs of a particular situation. One packing method applicable to strings containing many
repeated characters is the following:151

1. Copy the first character of the record in its exact form.

2. Replace each subsequent character by the binary value (or difference) that when added to
the preceding character's value (ignoring carries) will produce the desired character.
3. When the difference is zero, indicating a redundant (repeated) character, that zero difference
is used as a flag, and the next character contains a count of the number of remaining repe-
titions.
4. Preceding each string of compressed text is a record length byte containing the number of
bytes in the string, including itself.
5. A record length byte containing zero indicates the end of the compressed text for that
record.

These examples may help:

Input String Compressed Line Record

AAAAAAAAAA 04 C1 00 08
AAAAABBBBB 07 C1 00 03 01 00 03
BBAA 06 C2 00 00 FF 00 (no extra 00!)
ABCDDDDDEFFGH 0D C1 01 01 01 00 03 01 01 00 00 01 01

150 This is also known as an “out-shuffle”.

151 Due to J. E. Hunter, IBM Technical Disclosure Bulletin, Volume 15, Number 6, November 1972.

398 Assembler Language Programming for IBM System z™ Servers Version 2.00
(This compression scheme will require more space than the original text if the longest string of
repeated characters is of length 2, as in the third example.)
Write a program that will read 80-byte records and produce a block of compressed text records
in memory. For example, if there were only a single compressed text record (a single “line” of
text), as in the fourth example above, then the block in memory would contain 14 bytes:
0D C1 01 01 01 00 03 01 01 00 00 01 01 00
Then, “de-compress” the block of text, and print it. If you can, write your compressed text
onto records and give them to someone else to expand. Compare the expanded results to the
original records.

Problem 24.5.(4) + A common requirement in scanning character strings is that some character
positions must match a “pattern” exactly, while other positions may match any character. For
example, suppose a pattern is defined by C'AB%CD', meaning that when scanning a test string,
AB must match the first two characters of the test string, the % means that any character in the
third position of the test string is acceptable, and CD must match the fourth and fifth charac-
ters of the test string. For example, this pattern would match the test string C'AB?CD'. but not
the test string C'ABCDEF'.
Write a program that will accept a pattern string (perhaps on a record with initial characters
'Pattern') followed by records containing test strings. Print the pattern, the test string, and an
indication of whether the pattern matches the test string or not.

Problem 24.6.(5) + This problem is an extension of Problem 24.5. In addition to a pattern char-
acter like % that will match an arbitrary character in a test string, it is often useful to match
some characters while some number of others need not be matched. For example, if a pattern
uses the character * to mean “match any number of characters, including none”, then the
pattern C'A*B' would match test strings like C'AB' and C'A123B'. Similarly, a pattern like C'A*'
would match test strings like C'A' and C'ABCDEFG'.
As in Problem 24.5, write a program that will accept various patterns followed by test strings,
and print the pattern, the test string, and an indication of whether the pattern matches the test
string or not.

Problem 24.7.(5) + Combine the two pattern types of Problems 24.5 and 24.6, so that a pattern
might look like C'A%B*C', which would match test strings like C'A.BC' and C'AJBRSTUVWC'.

Problem 24.8.(2) A programmer claimed that he can convert the hex digits of a word stored at
Word to eight EBCDIC characters stored at HexWord representing the hex digits with these
instructions:
L 2,Word
L 4,=4X'0F'
LR 3,2
SRL 3,4
NR 3,4
NR 4,2
STM 3,4,Temp
TR Temp,=C'0123456789ABCDEF'
MVC HexWord,=X'0004010502060307'
TR HexWord,Temp
- - -
Temp DS D
HexWord DS CL8
Word DC X'1F2E3D4C' (For example)
Write a program to test his claim with a variety of values at Word.

Problem 24.9.(2) Write a program to simulate the execution of the TR instruction.

Problem 24.10.(3) Write a program to simulate the execution of the TRT instruction, without
considering final Condition Code settings

Chapter VII: Bit and Character Data 399

 Problem 24.11.(4) Write a program to simulate the execution of the TRT instruction, with
correct settings of the Condition Code when execution completes.

Problem 24.12.(3) + Write a program to display on three lines the 80-byte records of any short
program you wrote: on the first line, the original record (with double-spacing carriage control;
and on the second and third lines, each byte of the original line is shown in “vertical hex”,
where the first hex digit of the EBCDIC character is shown on the upper line, and the second
hex digit on the lower line. For example, the characters This is a TEST (or
X'E38889A24088A2408140E3A5E2E3') would be arranged on 3 output records like this:
0This is a TEST
E88A48A484EAEE
38920820103523
The key to the solution is the translate table.
This technique can be very useful for displaying the contents of records (like object modules)
that contain a mixture of EBCDIC and binary values.

Problem 24.13.(3) Write a program to read the records shown below. The first record is a title
line, the next is blank, and the remaining records contain the name of a student and four exam
grades in columns 31-40, 41-50, 51-60, and 61-70.
Write a program to read the data and produce a report with the average grade for each student
in columns 71-80, and after the last student's grades and average, skip a line and print the
average grade for each exam. For example, the output might be formatted like this:

Name Exam 1 Exam 2 Exam 3 Exam 4 Average

Student 1 nn nn nn nn nn
- - -
Student n nn nn nn nn nn

Exam Averages nn nn nn nn nn

This is some sample data:

Name Exam 1 Exam 2 Exam 3 Exam 4 Final

Doaks, Joe 79 83 88 91 93
Queue, Susie 44 91 67 97 89
Shakes IV, Pete 97 89 80 100 73
Burley, Hurley 61 71 85 88 97
Throckmorton, Chauncey 90 90 88 74 92
Doaks, Jonathan 79 83 87 95 47

Problem 24.14.(3) Write a program to read the records shown below, that contain the text of
Lincoln's “Gettysburg Address” as a string of characters in fixed-format 80-byte records. You
will need a work area of about 2000 bytes.
Count and print the number of words.
These are the records for you to read:

400 Assembler Language Programming for IBM System z™ Servers Version 2.00
Four score and seven years ago our fathers brought forth on this continent a ne
w nation, conceived in liberty, and dedicated to the proposition that all men a
re created equal. Now we are engaged in a great civil war, testing whether that
nation, or any nation, so conceived and so dedicated, can long endure. We are
met on a great battle-field of that war. We have come to dedicate a portion of
that field, as a final resting place for those who here gave their lives that t
hat nation might live. It is altogether fitting and proper that we should do th
is.

But, in a larger sense, we can not dedicate, we can not consecrate, we can not
hallow this ground. The brave men, living and dead, who struggled here, have co
nsecrated it, far above our poor power to add or detract. The world will little
note, nor long remember what we say here, but it can never forget what they di
d here. It is for us the living, rather, to be dedicated here to the unfinished
work which they who fought here have thus far so nobly advanced. It is rather
for us to be here dedicated to the great task remaining before us -- that from
these honored dead we take increased devotion to that cause for which they gave
the last full measure of devotion -- that we here highly resolve that these de
ad shall not have died in vain -- that this nation, under God, shall have a new
birth of freedom -- and that government of the people, by the people, for the
people, shall not perish from the earth.

Problem 24.15.(4) Write a program to read the same records as in Problem 24.14. Now, create a
table of distinct words, ignoring differences between lower and upper case forms of the same
word. Sort the words into alphabetical order, and print the words and the number of occur-
rences of each.

Problem 24.16. Write a program to read the same records in Problem 24.14.
Your program should then create a readable version of the text on lines of 60 characters, with
words correctly joined where they were split across the original records. No characters may go
past the end of the 60-character output line. For example, if two input records contain some-
thing like this:

────────────────────────────────── 80 characters ─────────────────────────────

word1 word2 word3 word4 word5 word6 word7 word8 word9 wordiness wordA wordB word
C wordD wordE ...

then your formatted line would contain something like this:

──────────────────────── 60 characters ───────────────────

word1 word2 word3 word4 word5 word6 word7 word8 word9
wordiness wordA wordB wordC wordD wordE ...

If you encounter a completely blank line in the input, leave a blank line in the formatted
output.
You might enjoy making the width of the output line depend only on a symbol defined by an
EQU statement; try values such as 60, 80, and 100.

Problem 24.17.(4) Write a program to read the data in Problem 24.14. Create an output area of
the same size as your input area. Now, you will encrypt the records from the input to the
output areas. Create a “key” by defining a suitably random binary fullword from a 9-digit
decimal value. Then, encrypt the input message as follows:

1. XOR your key with the first word of the input message, and store the result in the output
buffer.
2. XOR that result with the second word of the input message, and store the result in the
second word of the output buffer.
3. Continue in this way until the entire message has been encrypted.

Chapter VII: Bit and Character Data 401

 Then, create a third buffer of the same length as the input buffer. Using your key, decrypt the
message in the output into this third buffer, using the same technique. Then, compare your
decrypted result with the original. (They should be identical!)

Problem 24.18.(3) Write a program to read records with blank-terminated strings of octal (base
8) digits. Assuming the octal digits represent a right-adjusted binary number, convert the digits
to binary represented as a string of hexadecimal digits. Then, display the original octal digit
string followed by the converted hex string.
Remember that the rightmost octal digit contains the three low-order bits of the binary
number, so that octal 76543 (O'76543'? What's its value in decimal?) is the same as X'7D63'.

402 Assembler Language Programming for IBM System z™ Servers Version 2.00
25. Character Data and Extended Instructions

2222222222 55555555555
222222222222 555555555555
22 22 55
22 55
22 555555555
22 5555555555
22 555
22 55
22 55
22 555
222222222222 55555555555
222222222222 555555555

All the instructions discussed thus far complete their task before the next instruction is processed.
In this section, we'll look at some instructions that may take much longer to complete. This
means that if the CPU is interrupted by a high-priority request, something must be done about
the current instruction. The CPU handles this in one of two ways:
• Method A: Save enough information in the general registers about the intermediate state of the
instruction, reset the Instruction Address back to the address of the interrupted instruction,
and then process the interrupt. When execution of your program resumes, the interrupted
instruction continues from its intermediate state as though it had not been interrupted.
• Method B: Process a portion of the operands, update registers appropriately, and set the Con-
dition Code to 3 to indicate that the operation was only partially completed. Any pending
interruptions can then occur. The Instruction Address is not reset, so the following instruction
should test for CC=3 and branch back to the interrupted instruction so it can complete the
operation.

We'll see each “method” in the instructions in this section.

The processed portion of the operands can vary greatly from instruction to instruction, and for
repeated executions of the same instruction.

25.1. Move Long and Compare Logical Long

These instructions also use a special “padding” character, or an “end” (or “stop”, “test”, “search”,
“special”, “terminating”) character.152 All the instructions in Table 152 on page 404 use a padding
character.

152 The appropriate name for the “end” character depends on how it's used; some names are more descriptive than
others for a given instruction.

Chapter VII: Bit and Character Data 403

Op Mnem Type Instruction Op Mnem Type Instruction
0E MVCL RR Move Long A8 MVCLE RS Move Long Extended
0F CLCL RR Compare Logical Long A9 CLCLE RS Compare Logical Long
Extended
Table 152. Basic character-handling instructions using padding characters

We begin by examining the Move Long (MVCL) and Compare Logical Long (CLCL)
instructions in a general way. Both are RR-type instructions with the usual format, and they
both use four general registers! The instruction formats are
MVCL R1,R2
CLCL R1,R2
where both R 1 and R 2 designate an even-odd pair of registers. (A specification exception occurs if
either R 1 or R 2 is odd.) The even-numbered registers contain the operand addresses, and the next-
higher odd-numbered registers contain the operand lengths; each length is treated as a 24-bit
unsigned number. The high-order byte of R 2 + 1 contains the padding byte, as sketched in
Figure 221. (Register lengths and addressing modes are ignored for a moment.)

┌──────────────────────────────────────────────────────────────────┐
│ Operand 1 address │ GPR R1
├───────────────────────────────┬────────┬─────────────────────────┤
│////////////////////////////////////////│ Operand 1 Length │ GPR R1 +1
└───────────────────────────────┴────────┴─────────────────────────┘
┌──────────────────────────────────────────────────────────────────┐
│ Operand 2 address │ GPR R2
├───────────────────────────────┬────────┬─────────────────────────┤
│///////////////////////////////│pad byte│ Operand 2 length │ GPR R2 +1
└───────────────────────────────┴────────┴─────────────────────────┘
0 31 32 40 41 63
Figure 221. Register use by CLCL and MVCL

MVCL and CLCL simplify moving and comparing long strings of bytes, which would otherwise
require lengthy loops.

These instructions are unlike MVC and CLC in several respects.

• Two lengths are specified; the operands may have different lengths, and the instructions depend
on both lengths.
• Much longer strings of bytes may be compared or moved in a single instruction. Instead of a
limit of 256 bytes, MVCL and CLCL can specify up to 224 − 1 bytes.153
• All four registers may be changed by the instructions. The addresses in the even-numbered
registers depend on the addressing mode.
• The lengths are true lengths rather than “machine lengths” (the true length minus 1). Only the
24 low-order bits of R1 + 1 and R 2 + 1 (containing the operand lengths) are updated, and the
remaining bits are unchanged.
• The high-order byte of R2 + 1 holds a “pad byte” used to extend certain operands, if necessary.
• The MVCL instruction sets the Condition Code, and no data movement takes place if there is
any possibility of “destructive overlap” of the operands.
• Either R 1 or R 2 may be zero, so that GR0 may contain an operand address!
• Both instructions are interruptible: if an interrupt occurs before the operation is complete,
“Method A” is used: the registers are updated appropriately, and the Instruction Address in
the PSW is “backed up” by 2 bytes from the address of the following instruction to the

153 At the time MVCL and CLCL were implemented, The operand length of 2 24 − 1 bytes seemed sufficient for many
years. But memory sizes grew rapidly, so MVCLE and CLCLE were added to handle longer compare and move
operations. We'll see them in Section 25.2.

404 Assembler Language Programming for IBM System z™ Servers Version 2.00
 address of the CLCL or MVCL instruction. When control is returned to the interrupted
program, execution of the instruction resumes with the remnants of the operands.

25.1.1. MVCL
In the absence of special conditions, MVCL operates by moving bytes from the second (source)
operand field to the first (target) operand field. As noted in our discussion of implied lengths in
Section 24.3, the number of bytes moved is controlled by the first (receiving) operand length.
Thus, if the first operand length is zero, no bytes are moved.

Unlike MVC, MVCL tests for the possibility of destructive overlap, which occurs when any part
of the first operand field is used for a source after data has been moved into it. If destructive
overlap could occur, the CPU sets the Condition Code to 3, and moves no data.

Execution of MVCL proceeds (conceptually) as follows:

1. Bytes are moved one by one from the second to the first operand field; the counts are decre-
mented by 1 and the addresses are incremented by 1 for each byte moved.
2. If both operand counts reach zero at the same time, the CC is set to 0.
3. If the first operand count reaches zero before the second operand count, the CC is set to 1.
That is, the target length in R1 + 1 less than the source length in R2 + 1.
4. If the second operand count reaches zero first, the pad character is used as a source byte until
the first operand count reaches zero; the CC is then set to 2. That is, the target length in
R 1 + 1 greater than the source length in R2 + 1.
5. On termination, the operand 1 length is zero, and the operand 1 address has been updated by
the corresponding length. The operand 2 address has been incremented by the number of
bytes moved from the second operand field whether or not padding has occurred, and the
second operand count has been decreased by the same amount.
6. On termination (even for destructive overlap),
• in 24-bit addressing mode, the leftmost byte of GR R 1 and GR R 2 are zeroed, and the
high-order half of GG R 1 and GG R 2 are unchanged;
• in 31-bit addressing mode, the leftmost bit of GR R 1 and GR R 2 is zeroed, and the high-
order half of GG R 1 and GG R 2 are unchanged;
• in 64-bit addressing mode, both GG R 1 and GG R 2 are updated.

MVCL sets the Condition Code as shown in Table 153.

CC Meaning
0 Operand 1 length = Operand 2 length
1 Operand 1 length < Operand 2 length; part of operand 2 not moved
2 Operand 1 length > Operand 2 length; operand 1 was padded
3 Destructive Overlap, no data movement
Table 153. CC settings after MVCL

Figure 222 on page 406 may help you to to visualize the operation of MVCL, assuming there is
no destructive overlap. The figure uses these notations:
A1 Address of a first-operand byte, c(R1)
c(A1) The first-operand byte at address A1
L1 Remaining length of the first operand, c(R1 + 1)
A2 Address of a second-operand byte, c(R2)
c(A2) The second-operand byte at address A2
L2 Remaining length of the second operand, c(R2 + 1)
Pad Padding byte

Chapter VII: Bit and Character Data 405

 Reader Note
In the following figure sketching the flow of the MVCL instruction, there
are many places where subscripts would be more appropriate, but the
formatter used for this text cannot then properly align other parts of the
diagram. This comment also applies to Figures 225, 229, 232, 235, 236,
and 239 in this Section 25.

START── L1=0? ───── L2=0? ───── c(A1)←Pad

 │ No No│ Yes 
│ Yes│  A1=A1+1
│ │ c(A1)←c(A2) L1=L1−1
│ │  
│ │ A1=A1+1 L1=0? ────┐
│  A2=A2+1 │ Yes 
│ ┌────────┐ L1=L1−1 No│ ┌─────┐
│ │Done; if│ L2=L2−1 │ │Done;│
│ │L2=0 CC0│ Yes  │ │ Set │
│ │else CC1│──── L1=0? │ │ CC2 │
│ └────────┘ No│──────────────┘ └─────┘
│  ┌─────────────────┐
│ Interrupt │ PSW IA = IA─2 │
└────────────── Pending? ──── │Process interrupt│
No Yes └─────────────────┘
Figure 222. Conceptual execution of the MVCL instruction

To illustrate some uses of MVCL, suppose we want to set the area at Line to blanks (as in
example 1 of Section 24.6).

LineLen Equ 120 Number of blanks to move

SR 1,1 Operand 2 length = 0
ICM 1,8,=C' ' Pad character is blank
LA 2,Line Set address of first operand in GR2
L 3,=A(LineLen) And first operand length in GR3
MVCL 2,0 Move pad characters to 'Line'
Figure 223. Using MVCL to set a field to blanks

Because the second operand length in GR1 is zero, we need not initialize GR0 with an address.
This method is a lot more work than the example in Section 24.6, because we must set up four
registers and a pad byte. However, MVCL is superior to MVC when the number of bytes to be
moved grows large: by omitting the ICM (which inserts the padding character into R1), we could
just as easily have set the area to zero, as in example 1 of Section 24.7. MVCL is often used this
way to zero large blocks of memory without having to use XC instructions, and to initialize areas
without using MVC instructions with overlapping operands.
Suppose GR8 and GR9 contain the address and length of a message which is to be moved to the
120-byte area at PrintMsg. We will pad the message with blanks if it fits, and branch to WontFit
if all of the message won't fit in the 120-byte area.

LA 2,PrintMsg First operand address

LA 3,L'PrintMsg First operand length
ICM 9,8,=C' ' Set padding character to blank
MVCL 2,8 Move the string, pad if necessary
JL WontFit Branch if something left over (CC1)
JO NotMoved Error, destructive overlap (CC3)
Figure 224. Moving a message with padding and length checking

406 Assembler Language Programming for IBM System z™ Servers Version 2.00
No Execute instruction (or STC, to store a length byte into an MVC) was needed to supply a
Length Specification Byte for the move.

25.1.2. CLCL
The two operand byte strings are compared byte by byte as unsigned binary numbers (just as for
CLC), starting at the low-addressed end and proceeding toward higher addresses. The compar-
ison stops when an inequality is detected, or when the end of the longer operand is reached (not
the shorter!). Unlike MVCL, where only the first operand might be padded, CLCL can pad either
operand! The CC is set in the usual way to indicate the result of the comparison. If both operand
lengths are zero, or if R1 and R 2 designate the same register, the CPU simply sets the CC to zero,
indicating equality.

The comparison can be considered as proceeding in the following way:

1. Bytes are compared one by one; the operand addresses are incremented by 1 and the operand
lengths are decremented by 1 for each step.
2. If an inequality is detected before either length becomes zero, the CC is set, registers R1 and
R 2 contain the addresses of the unequal bytes, and the counts in the rightmost 24 bits of the
respective odd-numbered registers contain one more than the number of bytes that remain to
be compared. (That is, the addresses have been incremented by the number of equal bytes,
and the lengths have been decremented by the same amount.) The CC setting indicates the
larger or smaller operand.
3. If one of the lengths becomes zero, the comparison continues with the padding character
being compared to bytes from the longer operand. For the shorter operand, the even register
contains the address of the first byte past the end of the operand string, and the odd register
contains zero.
4. If an inequality is detected between the padding character and a byte from the longer
operand, the address and count for that operand are set as in step 2 (the address and count
for the shorter operand were set in step 3).
5. If no inequality is detected before the longer count becomes zero, the even-numbered register
points to the first byte past the end of the longer operand string.
6. The register contents on termination are the same as shown for MVCL in step 6.

If the two operands are completely equal (including the padding character, if needed), both counts
will be zero, and the corresponding addresses will have been incremented by the original count
values.

CLCL sets the Condition Code as shown in Table 154.

CC Meaning
0 Operand 1 = Operand 2, or both lengths 0
1 First Operand low
2 First Operand high
Table 154. CC settings after CLCL

Figure 225 on page 408 may help clarify this description. The figure uses notations similar to
those preceding Figure 222 on page 406:
A1 Address of a first-operand byte, c(R1)
c(A1) The first-operand byte at address A1
L1 Remaining length of the first operand, c(R1 + 1)
A2 Address of a second-operand byte, c(R2)
c(A2) The second-operand byte at address A2
L2 Remaining length of the second operand, c(R2 + 1)
Pad Padding byte
x:y x is compared to y

Chapter VII: Bit and Character Data 407

 START ──── L1=0? ───── L2=0? ─────────── c(A1):Pad
Yes│ No │No Yes =/│ │=
   │
┌──── Pad:c(A2) ───── L2=0? c(A1):c(A2) ──── ┬────┘ │
│ /= │= │Yes │= /= │ │
     
┌─────┐ A2=A2+1 ┌─────┐ A1=A1+1 ┌─────┐ A1=A1+1
│Done;│ L2=L2−1 │Done;│ A2=A2+1 │Done;│ L1=L1−1
│ Set │ │ │ Set │ L1=L1−1 │ Set │ │
│CC1,2│ │ │ CC0 │ L2=L2−1 │CC1,2│ │
└─────┘ │ └─────┘ │ └─────┘ │
└─────────────────────────── │──────────────────────┘
 ┌─────────────────┐
START ──── Interrupt pending? ──── │ PSW IA = IA−2 │
No Yes │Process interrupt│
└─────────────────┘
Figure 225. Conceptual execution of the CLCL instruction

The greater power of CLCL compared to CLC is seen in the changes to the four registers at the
end of the operation. Not only do you know exactly how many bytes were compared, but the
precise position of the inequality is known, which is impossible with CLC unless the bytes are
compared one at a time. 154 By testing the lengths for zero, you can tell whether an inequality
occurred between bytes in memory, or between the padding character and a byte in memory.

To illustrate CLCL, suppose we want to see if all 120 bytes at Line contain blanks, and branch to
AllBlank if so.

LA 2,Line First operand address in GR2

LA 3,120 First operand length in GR3
SR 1,1 Second operand length = 0
ICM 1,8,=C' ' Pad character is blank
CLCL 2,0 Compare first operand to blank
JE AllBlank Branch if all blanks at 'Line'
- - - GR2 points to first nonblank char
Figure 226. Using CLCL to test for blanks

Because the length of the second operand in GR1 is zero, no address is needed in GR0.

Suppose we have read two records into memory, and want to determine if they are equal; let the
addresses and lengths of the records be stored in fullwords at Addr1, Len1, Addr2, and Len2
respectively.
• If the records are unequal up to the length of the shorter record, we will branch to UnEqual.
• We branch to Equal if their lengths and contents are identical.
• We branch to Equal1 or Equal2 respectively if the operands are equal up to the shorter length,
but operand 1 or operand 2 is longer.
• Neither operand may be padded.

154 For long strings of bytes, this could be painfully slow.

408 Assembler Language Programming for IBM System z™ Servers Version 2.00
 L 2,Addr1 Set first operand address
L 3,Len1 And length of first record
L 6,Addr2 Set second operand length
L 7,Len2 And length of second operand
LA 1,Equal Assume lengths are equal
CLR 3,7 Compare lengths
JE Compare Go compare if equal lengths
JH Op1Long Branch if operand 1 longer
LA 1,Equal2 Operand 2 longer, set equality exit
LR 7,3 2nd operand length = shorter value
J Compare And compare
Op1Long LA 1,Equal1 Operand 1 longer, set equality exit
LR 3,7 1st operand length = shorter value
Compare CLCL 2,6 Compare operands with equal lengths
JNE UnEqual Branch if inequality detected
BR 1 Branch to desired equality routine
Figure 227. Comparing two records without padding

The preliminary effort in this example ensures that GR3 and GR7 will both contain the shorter
operand length when the CLCL is executed. This illustrates precautions we must take if we don't
want the shorter operand to be extended with a padding character.

Exercises
25.1.1.(1) Why does using GR0 for an operand address not violate the rules given in Section 10,
where GR0 can't be used to generate an Effective Address?

25.1.2.(2) + What do you think will happen if MVCL is the target of an EX instruction, and an
interruption occurs before the MVCL operation is completed?

25.1.3.(1) Using MVCL, is there any possibility of destructive overlap if the length of the
second operand is 1?

25.1.4.(1) Suppose the operand 1 length of an MVCL instruction is zero. What will be the CC
setting?

25.1.5.(2) + A 3500-byte area at Field contains a value in its first byte that is to be propagated
through the rest of the area (all 3500 bytes are to contain that value). Write a code sequence
using MVCL to perform the task.

25.1.6.(3) + It is claimed that destructive overlap will not occur with MVCL if

• operand 1 address ≤ operand 2 address, or

• operand 1 address > operand 2 address + MINLEN − 1

where MINLEN is the smaller of the two operand lengths. Is this true? Why?

25.1.7.(2) + Suppose we execute this instruction sequence:

LA 0,STR1 Address of first operand string
LA 1,L'STR1 Length of first operand string
LA 2,STR2 Address of second string
LA 3,L'STR2 Length of second string
ICM 3,8,PAD Padding character in GR3
CLCL 0,2 Compare STR1 to STR2
For each of the following sets of definitions of the symbols STR1, STR2, and PAD, show what
will be in GR0 through GR3 and the CC setting after the CLCL is executed. (Assume that the
address of the symbol STR1 is X'074212D0' in each case.)

Chapter VII: Bit and Character Data 409

 (1) STR1 DC F'1'
STR2 DC F'2'
PAD DC X'0'

(2) STR1 DC CL120' '

STR2 DC 110C' '
PAD EQU STR2

(3) STR1 DC CL20'**'

STR2 DC C'**'
PAD DC H'40'

(4) STR1 DC 0XL5

STR2 DC C'ABCD'
PAD DC X'FF'

25.1.8.(2) Sketching MVCL operands and their lengths sometimes helps you understand when
destructive overlap may occur. For example, in this sketch,
┌─────────────┐ Source operand
┌────┴─────────┬───┘ No destructive overlap
└──────────────┘ Target operand
no destructive overlap occurs because no target operand byte is used as a source operand byte if
data is moved one byte at a time. Sketch other possibilities to determine when destructive
overlap will and will not occur.

25.1.9.(3) As in Exercise 24.11.15, use one or more MVC instructions to move a string of bytes
whose address is in GR1 to an area whose address is in GR2; the number of bytes in GR3 is
greater than zero and less than X'FFFFFF'. Perform these additional tests:

1. If the strings overlap destructively branch to Destroy with no data having been moved.
2. If the data strings overlap, but no data is destroyed, perform the move and then branch to
Overlap.

25.1.10.(3) What factors must be considered if you write instructions to emulate the behavior of
CLCL?

25.1.11.(2) Rewrite the example in Figure 226 on page 408, reversing the operands: that is,
make the first operand have zero length.

25.1.12.(1) Revise Exercise 24.8.5 to use a CLCL instruction.

25.1.13.(1) Can you do a “ripple” move with MVCL, as you can with MVC?

25.1.14.(1) + Revise Figure 223 on page 406 to initialize to zero the 8192 bytes starting at New.

25.1.15.(4) Suppose you are using a CPU that does not support the MVCL instruction. Write
instructions (not using MVCL!) to simulate MVCL, including correct Condition Code settings.

25.2. Move Long and Compare Logical Long Extended

These two instructions are only slightly more complicated than MVCL and CLCL. Both
instructions use “Method B” to allow the CPU to process interruption conditions. Table 155
gives their format:

opcode R1 R3 B2 DL 2 DH2 opcode

Table 155. Format of MVCLE and CLCLE instructions

410 Assembler Language Programming for IBM System z™ Servers Version 2.00
 There are three operands: the operands in the even-numbered registers R1 and R 3 are analogous
to the R 1 and R 2 operands of MVCL and CLCL. The second operand is not used as an address;
instead, the low-order 8 bits of its Effective Address are used as the padding byte.
┌────────────── ─ ─ ─ ──────────┬───────┐
│ ///////////// ///////// │ pad │ Second operand's Effective Address
└────────────── ─ ─ ─ ──────────┴───────┘
Note that the second operand of the machine instruction is specified as the third operand of the
assembler instruction statement.

For example, to specify a blank padding character, you could write

MVCLE 2,8,C' '(0)
CLCLE 4,14,X'40'(0)

Another difference is that the odd-numbered registers hold the 32-bit (or 64-bit) operand lengths,
which can be from 0 to 232 − 1 (or from 0 to 264 − 1 for 64-bit addressing mode).

┌───────────────────────────────┬──────┬───────────────────────┐
│ Operand 1 address │ GPR R1
├───────────────────────────────┼──────┴───────────────────────┤
│ Operand 1 length │ GPR R1 +1
└───────────────────────────────┴──────────────────────────────┘
┌───────────────────────────────┬──────┬───────────────────────┐
│ Operand 3 address │ GPR R3
├───────────────────────────────┼──────┴───────────────────────┤
│ Operand 3 length │ GPR R3 +1
└───────────────────────────────┴──────────────────────────────┘
Figure 228. Register use by MVCLE and CLCLE

If these instructions are executed in 24- or 31-bit addressing modes, the rightmost 24 or 31 bits of
the even-numbered registers contain the operand addresses. On termination, the high-order (non-
address) bits of the R1 and R 3 registers may or may not be set to zero.155

25.2.1. MVCLE
Unlike MVCL, no overlap test is done for MVCLE; the results of overlapping operands are
unpredictable. Its execution is sketched in Figure 229 on page 412, using similar notations as in
Figure 222 on page 406, except that the source operand address is A3 and the source operand
length is L3.

155 This is not just a whim on the part of the CPU; it's meant to give the CPU designers more freedom to decide how
best to implement the instructions. (Maybe it's a whim on the part of the CPU designers?)

Chapter VII: Bit and Character Data 411

 START── L1=0? ───── L3=0? ───── c(A1)←Pad
 │ No No│ Yes 
│ Yes│  A1=A1+1
│ │ c(A1)←c(A3) L1=L1−1
│ │  
│ │ A1=A1+1 L1=0? ────┐
│  A3=A3+1 │ Yes 
│ ┌────────┐ L1=L1−1 No│ ┌─────┐
│ │Done; if│ L3=L3−1 │ │Done;│
│ │L3=0 CC0│ Yes  │ │ Set │
│ │else CC1│──── L1=0? │ │ CC2 │
│ └────────┘ No│──────────────┘ └─────┘
│ 
│ Enough ┌─────────────┐
└────────────── for now? ──── │Done; Set CC3│
No Yes └─────────────┘
Figure 229. Conceptual execution of the MVCLE instruction

On termination, the register contents are:

1. If the first operand has been completed, the CC is set to 0 if the two operand lengths were
equal. Both operand addresses have been incremented by that length, and both lengths are
now zero.
2. If the first operand has been completed, the CC is set to 1 if the first operand is shorter than
the third. Both operand addresses has been incremented by the first operand length, the first
operand length is 0, and the third operand length has been decremented by the first operand's
original length.
3. If the first operand has been completed, the CC is set to 2 if the first operand is longer than
the third (meaning that the first operand was padded). Both operand lengths are zero, and
both addresses have been updated by their original lengths.
4. If the CPU has moved enough bytes and wants to pause for any pending interruptions, the
CC is set to 3. You would then branch back to the MVCLE instruction to resume the move.
Both addresses and lengths have been updated for the bytes moved.
5. Whatever the reason for termination, the registers are updated to account for the amount of
data that has been moved.
6. Some special padding byte values can be used to improve the performance of MVCLE; see
the z/Architecture Principles of Operation for details.

To summarize, MVCLE sets the Condition Code as shown in Table 156.

CC Meaning
0 All bytes moved, operand lengths are equal
1 All bytes moved, operand 1 shorter; part of operand 2 was not moved
2 All bytes moved, operand 1 longer; operand 1 was padded
3 Some bytes moved; end of operand 1 not reached
Table 156. CC settings after MVCLE

We can use MVCLE for the same task as in Figure 223 on page 406, where we again assume
that GR8 and GR9 have been initialized already:

412 Assembler Language Programming for IBM System z™ Servers Version 2.00
 LA 2,PrintMsg First operand address
LA 3,L'PrintMsg First operand length
LA 0,C' ' Set padding character to blank
Move MVCLE 2,8,0 Move the string, pad if necessary
JO Move Repeat if not finished
Figure 230. Using MVCLE to set a field to blanks

As another example, suppose we use MVCLE to initialize a large area of storage starting at Work
to zeros:

XR 0,0 Source address will be ignored,

XR 1,1 ...because source length is zero
LA 2,Work Start of area to initialize
L 3,WorkSize Length of work area
Clear MVCLE 2,0,X'00' Initialize with X'00' padding
JO Clear Repeat if necessary

BlockLen Equ 32000

NBlocks Equ 20000
WorkSize DC A(BlockLen*NBlocks) Large area
Figure 231. Using MVCLE to initialize an area to zero

It's unlikely that you'd ever need to initialize such a large an area of storage; because the value at
WorkSize is larger than 224, we can't use MVCL.

It may or may not be important to your application that MVCLE does not check for overlap.

25.2.2. CLCLE
CLCLE operates in much the same way as CLCL, as sketched in Figure 232, using the same
notations as in Figure 225 on page 408, except that the source operand address is A3 and the
source operand length is L3.

START ──── L1=0? ───── L3=0? ─────────── c(A1):Pad

Yes│ No │No Yes =/│ │=
   │
┌──── Pad:c(A3) ───── L3=0? c(A1):c(A3) ──── ┬────┘ │
│ /= │= │Yes │= /= │ │
     
┌─────┐ A3=A3+1 ┌─────┐ A1=A1+1 ┌─────┐ A1=A1+1
│Done;│ L3=L3−1 │Done;│ A3=A3+1 │Done;│ L1=L1−1
│ Set │ │ │ Set │ L1=L1−1 │ Set │ │
│CC1,2│ │ │ CC0 │ L3=L3−1 │CC1,2│ │
└─────┘ │ └─────┘ │ └─────┘ │
└─────────────────────────── │──────────────────────┘
 ┌─────────────┐
START ──── Enough for now? ──── │Done; Set CC3│
No Yes └─────────────┘
Figure 232. Conceptual execution of the CLCLE instruction

On termination, the registers are set as follows:

1. If an inequality is found, the CC is set as shown in Table 159 on page 415.
2. If the operands are equal (including the padding byte, if used), the addresses and lengths are
updated to account for the number of bytes compared.

Chapter VII: Bit and Character Data 413

 3. If the CPU has compared enough bytes without an inequality and wants to pause for any
pending interruptions, the CC is set to 3. You would then branch back to the CLCLE
instruction to resume comparing.

CLCLE sets the Condition Code as shown in Table 157.

CC Meaning
0 All bytes compared, operands equal, or both zero length
1 First operand low
2 First operand high
3 Some bytes compared without finding an inequality
Table 157. CC settings after CLCLE

To illustrate, we'll rewrite Figure 221 on page 404 to use CLCLE:

LA 2,Line First operand address in GR2

LA 3,120 First operand length in GR3
XR 0,0 Second operand address is ignored,
XR 1,1 ...because its length is zero
Compare CLCLE 2,0,C' ' Compare first operand to blanks
JE AllBlank Branch if all blanks at 'Line'
JO Compare Repeat if comparison is incomplete
- - - GR2 points to first nonblank char
Figure 233. Using CLCLE to test for all blanks

The similarities of CLCL and CLCLE are close; only the operand lengths and the source of the
padding byte are different. But, the differences between CLC and CLCL/CLCLE are more signif-
icant:
• CLC requires only one or two base registers to address the operands; CLCL/CLCLE both
require up to four registers.
• CLC is limited to 256-byte operands; CLCL/CLCLE operands can be much longer.
• CLC simply indicates an inequality; CLCL/CLCLE also set R1 and R 2 (or R 3) to the
addresses of the unequal bytes.
• CLC does no padding; CLCL/CLCLE support a padding character.

Exercises
25.2.1.(2) What do you think will happen if the B2 register of a CLCLE or MVCLE instruction
is the same as R1 or R 3 or R 1 + 1 or R 3 + 1?

25.2.2.(1) + Can both operands of CLCL or CLCLE be padded?

25.2.3.(2) In 24-bit addressing mode, the maximum valid address is X'00FFFFFF', or 224 − 1.
However, MVCLE allows you to specify operand lengths up to X'FFFFFFFF', or 232 − 1. What
do you think will happen if you execute MVCLE with a length longer than X'FFFFFF'?

25.2.4.(1) In Figure 231 on page 413, what is the hex value of the word at WorkSize?

25.2.5.(2) Let NB2M be the number of bytes to be moved to Tgt from the second operand
field at Src by MVCL. Make a table which gives the initial and final register contents, and the
value of NB2M, for each of the possible resulting CC values when all bytes have been moved.
Then, do the same for MVCLE.

414 Assembler Language Programming for IBM System z™ Servers Version 2.00
25.3. Special “C-String” Instructions
The four instructions in Table 158 arose from the need to process character strings used by the C
and C+ + programming languages, where character strings are terminated by a zero byte (X'00')
called a null byte.156 The instructions have many general uses, whatever the origins of the data,
and whether or not it contains a null terminating byte.

We will use a bold italic letter “n” to represent a null byte, as in “n”. For example,
DC C'A C-string.',X'0' Generates 'A C-string.n'

The length of a C-string does not include the terminating null character, so that the single byte
X'00' represents a C-string of length zero (a “null string”).

Op Mnem Type Instruction Op Mnem Type Instruction

B255 MVST R R E Move String B25D CLST R R E Compare Logical String
B25E SRST R R E Search String B2A5 T R E R R E Translate Extended
Table 158. Character-handling instructions for terminated strings

These instructions all have RRE format, as shown in Table 159:

opcode R1 R2
Table 159. Format of RRE-type instructions

Each instruction uses a special (end, test, or terminating) character in the rightmost byte of GR0.
All but TRE require that the remaining bits of GR0 be zero.

The operation of the MVCL, MVCLE, CLCL, and CLCLE instructions is controlled by a length
in a register; the four instructions in Table 158 are controlled by the presence of the special char-
acter in one or both operands. Only TRE uses both a length and a terminating character.

Exercises
25.3.1.(1) + Write DC statements defining C-strings of length zero, one, and ten.

25.4. Search String Instruction

The SRST instruction is the simplest of these four instructions. It scans the second operand
string addressed by register R2, looking for a byte matching the specified “test” character in GR0.
If a matching byte is found, the R1 register is set to its address. Because the second operand
string can be very long, the CPU uses “Method B” (described on page 403) to process part of the
string before checking for interruptions.

For finding a single character, SRST is simpler and faster than a Translate and Test instruction
like TRT, or a CLI loop. Unlike TRT, however, it searches for only a single character.

To use SRST, set the test character in GR0, set the R 2 register to the address of the leftmost byte
of the string to be scanned, and the R1 register to the address of the first byte after the end of the
string. The CPU uses the address in the R1 register to know when to stop the scan; otherwise, it
could keep scanning bytes in memory until it found a match somewhere, or caused an unexpected
interruption. This is summarized in Figure 234 on page 416.

156 The earliest implementations of C were done on machines with instructions that could move bytes and simultaneously
test their values, so very few instructions were needed to move null-terminated character strings.

Chapter VII: Bit and Character Data 415

 R2 R1
 
┌─────────────────────────────────┐
│ string to be searched │
└─────────────────────────────────┘
Figure 234. Registers bounding the SRST search string

Table 160 gives the Condition Code settings after SRST:

CC Meaning
1 Test character found; R1 points to it
2 Test character not found before the byte addressed by R1
3 Partial search with no match; R1 unchanged, R 2 points to next
byte to process
Table 160. CC settings for SRST instruction

On completion, either or both of the R 1 and R 2 registers may be updated:

• If the CC is 1, the R1 register is updated and the R2 register is unchanged.
• If the CC is 2, both the R1 and R 2 registers are unchanged.
• If the CC is 3, R1 is unchanged and R2 is updated to the address of the next byte to be tested.
You can then branch back to the SRST instruction to continue the search.

When a register is updated, any high-order bits not used for addressing are set to zero. Figure 235
sketches the operation of the SRST instruction. The notation used in the figure is:
A1 Address of the first byte after the end of the string being searched, in R1
A2 Address of a byte being checked during the search
Test Test character, taken from GR0

Yes ┌────────┐
START ── Save R1,R2 ───── A1≤A2? ──────── │Done: │
 │ No │Set CC2 │
│ │ └────────┘
│  Yes ┌────────┐
│ c(A2)=Test? ────── │Done: │
│ │ No │Set CC1 │
│  └────────┘
│ A2=A2+1
│ │
│ No  Yes ┌─────────────┐
└─── Enough ──────── │Done: Set CC3│
for now? │Set R2←A2 │
└─────────────┘
Figure 235. Conceptual execution of the SRST instruction

If the test character is found at the moment the CPU has “scanned enough for now” and would
otherwise set the CC to 3, it may instead set the CC to 2; the net result is the same because
branching back to the SRST instruction when CC=3 will immediately produce CC=2.

For example, suppose you want to scan the string at MyData to find the first occurrence of a blank
character:

416 Assembler Language Programming for IBM System z™ Servers Version 2.00
 LA 0,C' ' Search character is a blank
LA 1,MyData Set GR1 to start of the string
LA 5,MyData+L'MyData Set GR5 to byte past end of string
Repeat SRST 5,1 Scan the string for a blank
JO Repeat Scan was incomplete, try again
JH NotFound CC2, no blank was found
- - - GR5 points to the blank

If the Condition Code is 3, we simply branch back to the SRST to continue the search.

Exercises
25.4.1.(2) Write a sequence of instructions to find the last nonblank character in a C-string of
characters stored at CData, whose length (at most 256 bytes) is stored in the word at CDataLen.
If all blank characters are found, branch to AllBlank. If the C-string is empty, branch to
NullData.

25.4.2.(2) + The C/C++ programming languages define the strlen function to return the length
of a C-string argument. Suppose a C-string of unknown length is stored at WorkArea. Store its
length in the word at WorkLen.

25.4.3.(3) The C/C++ programming language function memchr searches the first N bytes of a
C-string argument to find the first occurrence of a given byte. Suppose a C-string of unknown
length is stored at WorkArea, and you want to find an occurrence in the string of the byte stored
at FindByte, and the maximum number of bytes to search is stored in the word at N. If the
desired character is found, put its address in GR1; if not found, set GR1 to zero.

25.4.4.(2) A single byte is stored at OddByte. Write instructions to search for its first occurrence
in the C-string stored at Clutter. If found, set GR9 to the address of the first occurrence; if
not found, set GR9 to zero.

25.4.5.(3) Suppose your program processes words and sentences, and you must alternately
search for the blank ending a word and a nonblank starting the next word. Write a sequence of
instructions that show how to scan a string at TextLine and build arrays containing (a) the
length of each word, and (b) its starting address.

25.4.6.(4) Repeat Exercise 25.4.5 but assume that the words might be followed by punctuation
characters that should not be stored as part of the word.

25.5. Move String Instruction

The MVST instruction moves bytes from the second operand to the first, testing each source byte
for the ending character in the rightmost byte of GR0. If the entire operand (including the ending
character) has been moved, the CPU sets Condition Code 1, and sets the R 1 register to the
address of the ending character. If some bytes remain to be moved, the addresses in R1 and R 2 are
updated to point to the next bytes to be processed, unused high-order addressing bits are set to
zero, and the Condition Code is set to 3. Destructive overlap is not recognized, so be careful!

CC Meaning
1 Entire second operand moved; R 1 points to end of first operand
3 Incomplete move; R 1 and R 2 point to next bytes to process
Table 161. CC settings for MVST instruction

Figure 236 on page 418 sketches the operation of the MVST instruction. The notation is the
same as in Figure 235 on page 416.

Chapter VII: Bit and Character Data 417

 ┌───────────────┐
START ─── c(A1) ←c(A2) ──── c(A2) = End Char? ──── │Done; Set CC1 │
 │No Yes │R1 →last byte │
│  └───────────────┘
│ A1=A1+1
│ A2=A2+1
│ │
│ No  Yes ┌──────────────┐
└───────────────────────── Enough ──── │Done; Set CC3 │
for now? │R1,R2,←A1,A2 │
└──────────────┘
Figure 236. Conceptual execution of the MVST instruction

The following example moves a null-terminated string from Old to New.

XR 0,0 Ending character is a null byte

LA 1,Old Address of source string
LA 2,New Address of target string
Move MVST 2,1 Move from Old to New
JO Move Repeat if CC=3
- - -
Old DC C'This is a null-terminated string',X'0'
New DS CL(L'Old+1) Reserve space for New string
Figure 237. Moving a null-terminated string

It's important to ensure that the target field is long enough to hold both the characters and the
null terminating byte.

Many programs must scan character strings containing tokens separated by commas. Using
MVST, you can move the tokens one at a time to a work area for analysis.

LHI 0,C',' Ending character is a comma

LA 1,Source Address of source string
NextTok LA 2,WorkArea Address of work area for a token
LR 3,1 Save starting address of token
Move MVST 2,1 Move from Source to WorkArea
JO Move Repeat if CC=3
SR 1,3 Subtract token's starting address
STH 1,TokenLen Save its length
- - - Process the token (preserve GR0,GR3)
LA 1,1(1,3) Point GR1 past the comma
J NextTok And go scan for the next token
- - -
Source DC C'LIST,OBJECT,XREF,ADATA,' String of tokens
WorkArea DS CL20 Reserve space for longest token
TokenLen DS H Length of current token
Figure 238. Using MVST to isolate comma-separated tokens

This example is incomplete because we would expect more tokens to follow the last one (ADATA),
and because the length of the entire string should be checked to see if the last token was not
followed by a comma.

Exercises
25.5.1.(2) + What would happen in Figure 237 if you used an MVC instruction to move the
string from Old to New? (Assume the string is less than 250 bytes long.)

418 Assembler Language Programming for IBM System z™ Servers Version 2.00
 25.5.2.(2) In Figure 238 on page 418, how would you know that you had correctly processed
the last token in the source string?

25.5.3.(2) In Figure 238 on page 418, is the length stored at TokenLen the length of the token,
or the length of the token and its terminating comma?

25.5.4.(3) Suppose a C-string is stored at From and you want to move it to Target but with the
additional limitation that at most N bytes are moved, where N is stored at NBytes. If the null
character terminating the string at From is moved, set GR1 to the address of the byte following
the null character; if the null character is not moved, set GR1 to zero.

25.5.5.(2) + Write instructions to concatenate the C-string stored at Suffix at the end of the
C-string stored at Prefix. Make sure that the resulting C-string is terminated correctly.
Assume that the string at Suffix is at most 8000 bytes long.

25.5.6.(3) Repeat Exercise 25.5.5, but assume that the amount of space available for the concat-
enated string is only 150 bytes. If the result will not fit in the space available, branch to
TooLong.

25.5.7.(2) + Write instructions to copy a C-string from Here to There.

25.5.8.(3) Modify the instructions in Figure 238 on page 418 to scan and process all the tokens
in the character string, given that the total length of the token string is in a word at StrLen and
that the string might contain only a single token without a trailing comma.

25.6. Compare Logical String Instruction

As we saw for CLCL and CLCLE, the two operands being compared can have different lengths,
and either operand may be padded. CLST, however, requires that the operands have the same
terminating character; and neither is padded during comparison.

The operands are compared byte by byte from left to right, until unequal bytes are found or the
end of an operand is reached. Unlike SRST, there is no stop address or operand length for either
operand, so be sure the strings are properly terminated.

If the end character is found in either operand before being found in the other, the shorter
operand is low; if they are found at the same time, the operands are equal.

The Condition Code settings after CLST are the same as those for other compare instructions,
except that CC3 indicates an incomplete operation. As with SRST and MVST, if the Condition
Code is 3, you can just branch back to repeat the CLST.

CC Meaning
0 Entire operands are equal; R1 and R 2 unchanged
1 First operand low; R 1 and R 2 point to last bytes processed
2 First operand high; R 1 and R 2 point to last bytes processed
3 Operands equal so far; R1 and R 2 point to next bytes to process
Table 162. CC settings for CLST instruction

Figure 239 on page 420 sketches the operation of the CLST instruction. The notation used in the
figure is:
A1 Address of a first-operand byte, c(R1)
c(A1) The first-operand byte at address A1
A2 Address of a second-operand byte, c(R2)
c(A2) The second-operand byte at address A2
End End character in GR0
x:y x is compared to y

Chapter VII: Bit and Character Data 419

 Yes Yes ┌───────────┐
START ── Save R1,R2 ──── c(A1)=End? ─── c(A2)=End? ─────── │Done: │
 │ No │ No │R1,R2←A1,A2│
│ │  │Set CC0 │
│ │ Set CC1 ─────┐ └───────────┘
│  Yes 
│ c(A2)=End? ──── Set CC2 ─────── •────────────┐
│ │ No │
│  
│ c(A1):c(A2) ──── c(A1)<c(A2)? ─── Set CC2 ─ •
│ │ = /= │ Yes No │
│  │ 
│ A1=A1+1  ┌───────────┐
│ A2=A2+1 Set CC1 ─────────────── │Done: │
│ │ │R1,R2←A1,A2│
│ No  Yes ┌─────────────┐ └───────────┘
└─── Enough ───── │Done: Set CC3│
for now? │R1,R2←A1,A2 │
└─────────────┘
Figure 239. Conceptual execution of the CLST instruction

At termination, the contents of the registers are:

1. If the comparison ends at the End character for both operands, they are equal: the CC is set
to 0 and GR R 1 and GR R 2 are unchanged.
2. If the comparison ends at unequal bytes, the CC is set to 1 or 2 depending on whether the
first operand byte is less than or greater than the second operand byte. GR R 1 and GR R 2
contain the addresses of the unequal bytes.
3. If the comparison reaches the End character of one operand before the other, that operand is
considered the smaller and the CC is set accordingly. GR R 1 and GR R 2 point to the bytes
where the comparison stopped. (Note that no padding occurs!).
4. If the comparison is not complete when the CPU needs to allow for possible interrupts, the
CC is set to 3 and GR R 1 and GR R 2 have the addresses of the next bytes to be compared.
You can then branch back to the CLST instruction to continue comparing.

To illustrate, suppose you want to compare the two C-strings at A and B.

XR 0,0 Set null ending byte in GR0
LA 7,A Set GR7 to start of first operand
LA 5,B Set GR5 to start of second operand
Comp CLST 7,5 Compare the two strings
JO Comp Incomplete comparison, repeat
JE Equal Strings are equal
JH A_High String A compares higher than string B
J A_Low String A compares lower than string B

When an inequality is found, the ending characters of the operands are not part of the compar-
ison. However, when R 1 and R 2 are updated when the Condition Code is 3, they could contain
the addresses of either or both ending characters.

Exercises
25.6.1.(2) Write an instruction sequence that will compare the C-string stored at StringA to the
C-string stored at StringB. Set GR0 to + 1 if StringA is greater than StringB, to zero if they
are equal, and to −1 if c(StringA) is less than c(StringB).

25.6.2.(3) Write an instruction sequence that will compare the first N bytes of the C-strings
stored at StringA and StringB respectively, where the number of bytes N is stored in the word
at NBytes. Set GR0 to + 1 if StringA is greater than StringB, to zero if they are equal, and to

420 Assembler Language Programming for IBM System z™ Servers Version 2.00
 −1 if StringA is less than StringB. Be sure to handle cases where either or both strings are
shorter than N bytes.

25.6.3.(2) + Suppose these instructions are used to compare two C-strings:

XR 0,0 Ending character is a null byte
LA 1,X First operand is at X
LA 2,Y Second operand is at Y
CLST 1,2 Compare first and second operands
For each of the following, assume that the string named X is at address X'26F943'. Give the
Condition Code setting and the addresses in GR1 and GR2 after comparing each pair of
strings.
(1) X DC C'ABCD',X'0'
Y DC C'ABJE',X'0'

(2) X DC X'0'
Y DC X'0'

(3) X DC C'ABCD',X'0'
Y DC C'ABCDEFGH',X'0'

(4) X DC C'BCDEFGH',X'0'
X DC C'ABCD',X'0'

25.6.4.(4) Two strings of bytes begin at A and B and their lengths are stored in the halfwords at
LA and LB respectively. Compare the two strings up to the length of the shorter; however, if a
mismatch occurs and one of the unmatched bytes is X'FF', continue comparing. (Thus X'FF' is
a “don't care” character which can match any other character.) Branch to AB_Equal, A_High, or
B_High accordingly.

25.7. Translate Extended Instruction

The TRE instruction is similar in function to TR. In both cases, the first operand is the string of
bytes to be translated, scanning from left to right, and the second operand is the translate table.
There are several differences:
• Addresses: specified in base-displacement form for TR, but in R1 (which must be even) and
R 2 for TRE.
• Lengths: for TR, encoded in the instruction itself, but in R1 + 1 for TRE.
• Stop condition: for TR, all first operand bytes are translated; for TRE, either all first operand
bytes are translated, or a first operand byte matches the “stop” character in GR0.
• Condition Code: unchanged by TR, but updated by TRE.
• Operand overlap: TR operates byte-by-byte so that operand overlap has no effect; for TRE
the results are unpredictable.

One important result of having a stop character is that it can't be translated, unless you add extra
instructions to do your own “translation” after TRE completes.

Table 163 gives the Condition Code settings following execution of a TRE instruction:

CC Meaning
0 All bytes translated; R1 incremented by length, R1 + 1 set to 0
1 R 1 points to the byte matching the stop character; R1 + 1 decremented by the
number of bytes processed before the match
3 R 1 incremented and R 1 + 1 decremented by the number of bytes processed
Table 163. CC settings for T R E instruction

Chapter VII: Bit and Character Data 421

 To illustrate, suppose a sentence of text starting at Sentence is known to be at most 800 bytes
long. We want to translate all alphabetic characters to upper case, and stop on the first period.

LHI 0,C'.' Stop character in GR0

LA 1,UpperTbl Address of translate table
LA 2,Sentence String to be translated
LHI 3,800 Maximum length
UpChars TRE 2,1 Translate characters to upper case
JO UpChars Repeat if not finished
JZ NoPeriod All characters translated, but ...
* ... no stop character was found.
- - - GR2 has address of the stop character
Figure 240. Translating characters to upper case with T R E

If we need to translate additional text, we can simply increment GR2, reset the length in GR3,
and continue.

The translate table referenced in Figure 240 could be defined with statements like these:
UpperTbl DC 256AL1(*-UpperTbl) Initialize table to identities
Org UpperTbl+C'a' Position at C'a'
DC C'ABCDEFGHI' Upper-case equivalents
Org UpperTbl+C'j' Position at C'j'
DC C'JKLMNOPQR' Upper-case equivalents
Org UpperTbl+C's' Position at C's'
DC C'STUVWXYZ' Upper-case equivalents
Org , Reposition Location Counter

Exercises
25.7.1.(2) What do you think will happen to a TRE instruction if R1 = 0 or R 2 = 0?
If R 1 = R 2?

25.7.2.(2) + Suppose you execute these instructions:

LA 0,C'?'
LHI 3,N
LA 2,X
LA 9,Table
TRE 2,9
Assuming an appropriate translate table has been defined at Table, show the contents of GR2,
GR3, and the Condition Code for each of the following values of N and byte strings starting at
X which is at address X'7F290C'.
(1) N Equ 7
X DC C'Who? What?'

(2) N Equ 7
X DC C'Unknown?'

(3) N Equ 50
X DC 10C'Possibly? '

422 Assembler Language Programming for IBM System z™ Servers Version 2.00
25.8. Compare Until Substring Equal Instruction (*)
CUSE is a very complex instruction. 157 It is unusual in another way: it is both interruptible
(“Method A”) and stops and sets Condition Code 3 to allow interruption processing (“Method
B”). 158 Though not widely used, it may be applicable in certain applications.

Op Mnem Type Instruction

B257 CUSE R R E Compare Until Substring Equal
Table 164. Compare Until Substring Equal instruction

In general, there are two types of matching substring, depending on whether the equal substrings
are at the same or different offsets:
• In 'XBCY' and 'ABCD', the equal substrings 'B' and 'BC' (with lengths 1 and 2 respectively) are
at offset 1.
• In 'XYBC' and 'ABCD', the equal substrings 'B' and 'BC' are at different offsets.

The CUSE instruction searches only for equal substrings at the same offset, and having the length
specified in GR0. It requires six general registers, two of which are fixed: GR0 and GR1. The
rightmost byte of GR0 contains the length of the desired matching substrings, and the rightmost
byte of GR1 contains a padding byte. The remaining bits of both registers are ignored.

The addresses of the two operands are specified by the even-numbered registers R1 and R 2, and
their lengths are in R1 + 1 and R 2 + 1, respectively. And unlike instructions like MVCL and
CLCLE, the lengths are signed, and a negative length is treated as zero.159

It's important to remember that the substrings must occur at the same offset in both operands.
Thus, in the two strings
ABCDEFG and QRSDEFT
the substring DEF occurs at offset 3, so CUSE can identify matching substrings for lengths 1, 2,
and 3. However, in the two strings
ABCDEFG and BCDEFGH
the string BCDEFG appears at different offsets, so they will not be considered as equal substrings by
CUSE.

The padding character in GR1 is used to extend the shorter string if necessary. For example, if the
padding byte is C'*' and the two operand strings are
ABC and BCD**
with lengths 3 and 5 respectively, and the substring length is 2, then the matching substring will
be the characters **.

The Condition Code and registers are set as indicated in Table 165 on page 424.

157 Other complex instructions include EDIT and EDMK; we'll see them in Section 30 when we describe packed
decimal arithmetic.
158 At the time of this writing, I know of no other instruction that supports both types of interruption management.
159 A signed length seems strange, as it's hard to think of uses for strings with negative lengths. Other instructions like
MVCL and MVCLE use unsigned lengths. (See Exercise 25.8.7.)

Chapter VII: Bit and Character Data 423

 CC Meaning
0 Equal substrings found; R1, R 2, and lengths updated; or,
the substring length is 0, and R 1, R 2 are unchanged
1 Ended at longer operand, last bytes were equal
(allows continuing search for further matches if required)
2 Ended at longer operand, last bytes were unequal; or,
both operand lengths = 0 and the substring length is > 0
3 Search operation incomplete, last compared bytes unequal;
R 1 and R 2 and lengths are updated
Table 165. Condition Code settings by CUSE

Here are some examples of CUSE: suppose we execute the code sequence in Figure 241 for
various values of String1 and String2 and their lengths, with different pad characters, searching
for matching 3-byte substrings in each case:

LA 0,Substr_Len Desired substring length in R0

LA 1,Pad_Char Pad Character in R1
LM 2,5,=A(String1,L'String1,String2,L'String2)
CUSE 2,4
Figure 241. Examples using the CUSE instruction

The results are shown in Table 166; matching substrings are underlined.

Substr Pad L1 L2
String1 L1 String2 L2 Len Char CC after after Result
CABCEFDEFEAB 12 ACBABBCEFEAB 12 3 C' ' 0 5 5 Match
ABCDEF 6 BCDEFA 6 3 C' ' 2 0 0 No match
ABCBACAC 9 BCBABCAC 9 3 C' ' 0 3 3 Match at end
ABC 3 CABAAA 6 3 C'A' 0 0 3 Match with pad
ABC 3 CABCAB 6 3 C'A' 2 0 0 No match
ABCBA 5 BCBAA 5 3 C'A' 1 1 1 No match, last bytes equal
Table 166. Results of examples using the CUSE instruction

Searching for matching substrings can be a complex and tedious process, especially if different
offsets are allowed. (See Exercise 25.8.1 and Programming Problem 25.1.)

Exercises
25.8.1.(4) Write a sequence of instructions using CLCLE instructions to emulate the function
of CUSE.

25.8.2.(2) + What is the length of the longest matching substring that can be found using
CUSE?

25.8.3.(2) Suppose a CUSE instruction detects an inequality following several equal bytes, but
the number of equal bytes is less than the required substring length. Should the instruction
restart its comparison at the second equal bytes, or at the bytes following the inequality?

25.8.4.(2) + Suppose your CUSE instruction specifies a substring length 2 with padding char-
acter A. If the strings ABCA and DEFA are compared, will it find a matching substring AA?

25.8.5.(2) If the substring length is 1, how is CUSE similar to and different from CLCLE?

25.8.6.(4) Create a flow diagram for CUSE, similar to those in Figures 236 and 239.

25.8.7.(5) Suppose the CUSE instruction supports negative operand lengths, and performs a
backward search. For example, if StringA is ABCD and has length + 4, while StringB is WCBZ and

424 Assembler Language Programming for IBM System z™ Servers Version 2.00
 has length − 4. If the search starts at the rightmost byte of an operand with negative length, it
would find a matching substring BC in this case.
Write instructions to emulate a CUSE instruction that supports negative operand lengths.

25.9. Summary
Null-terminated C-strings must be handled carefully. If the terminating null byte is omitted, pro-
grams scanning or moving such strings may process far more data than intended, possibly over-
writing other data or parts of the program.

The instructions discussed in this section are listed in Table 167; all set the Condition Code.

Function Length control End-char control

MVCL MVST
Move
MVCLE
CLCL CLST
Compare CLCLE
CUSE
Search SRST
Translate TRE
Table 167. Extended instructions for character data

Exercises
25.9.1.(3) + The C/C++ function strncpy copies at most N characters from a C-string at From to
a C-string at To and pads it with null bytes if the “From” string has fewer than N characters.
Assuming that the number N is stored in a word at NBytes, write an instruction sequence to
perform this function.

25.9.2.(2) + The C/C++ function strcat concatenates characters from the C-string at Second to
the end of the C-string at First. Write an instruction sequence to perform this function, being
sure that the result has only a single null character.

25.9.3.(3) The C/C++ function strncat concatenates at most N characters from a C-string at
Second to the end of the C-string at First and terminates the result with a null byte. Assuming
that the number N is stored in a word at NBytes, write an instruction sequence to perform this
function.

25.9.4.(3) The C/C++ function strncmp compares at most N characters from the C-string at A to
the C-string at B. Assuming that the number N is stored in a word at NBytes, write an instruc-
tion sequence to perform this function, setting GR0 to + 1 if A>B, to 0 if A=B, and to − 1 if A<B.

25.9.5.(2) The C/C++ function strchr searches a C-string for the first occurrence of a character.
Write instructions to perform this function, assuming that the C-string is stored at CString and
the character to be sought is stored at FindChar. If the character is found, set GR3 to its
address; otherwise, set GR3 to zero.

25.9.6.(3) + The C/C++ function strrchr searches a C-string for the last occurrence of a char-
acter. Write instructions to perform this function, assuming that the C-string is stored at
CString and the character to be sought is stored at FindChar. If the character is found, set GR3
to its address; otherwise, set GR3 to zero.

25.9.7.(3) The C/C++ function strspn searches a C-string for any of the characters in a second
C-string, and returns the length of the initial portion of the first string containing characters
belonging to the second. Assuming that the C-strings are stored at First and Second, write
instructions that will place in GR1 the length of the first part of the first string containing only
characters from the second.

Chapter VII: Bit and Character Data 425

 25.9.8.(3) The C/C++ function strcspn searches a C-string for any of the characters not in a
second C-string, and returns the length of the initial portion of the first string containing no
characters belonging to the second. Assuming that the C-strings are stored at First and Second,
write instructions that will place in GR1 the length of the first part of the first string containing
none of the characters from the second.

25.9.9.(3) The C/C++ function strpbrk searches a C-string for the first occurrence of any char-
acter in a second C-string, and returns the address of the character if present, or a null (zero)
pointer if none is found. Assuming that the C-strings are stored at First and Second, write
instructions that will place in GR1 the address of the first occurrence in the first string of any
character from the second, or zero if none is found.

25.9.10.(3) The C/C++ function strstr searches a C-string for the first occurrence of a second
C-string, and returns the address of the first character of that matching string if present, or a
null (zero) pointer if none is found. Assuming that the C-strings are stored at First and
Second, write instructions that will place in GR1 the address of the first occurrence in the first
string of the second string, or zero if none is found. If the second string is null, return the
address of the first.

25.9.11.(2) The C/C++ function memchr searches N bytes in memory for the first occurrence of a
character, and returns a pointer to the character if present or a null (zero) pointer if none is
present. Write instructions to perform this function, assuming that the data to be searched is
stored at MemData, the character to be sought is stored at FindChar, and the number N is stored
in a word at NBytes. If the character is found, set GR3 to its address; otherwise, set GR3 to
zero.

25.9.12.(2) The C/C++ function memset stores a character into the first N bytes of a C-string.
Write instructions to perform this function, assuming that the C-string is stored at CString, the
character to be stored is at FillChar, and the number N is stored in a word at NBytes.
What will happen if the null bytes at the end of the C-string is overwritten, or if no null byte is
placed after the N-th byte?

25.9.13.(4) + A string of EBCDIC characters starting at Str+2 contains substrings of blanks and
nonblanks. The total length of the string is a halfword binary integer in the two bytes at Str.
Write instructions to replace multiple blanks in the string with a single blank, and update the
string length accordingly. (Such a result is sometimes called “blank-compressed”.)

Instructions Discussed in this Section

The instruction mnemonics and opcodes are shown in the following table:

Mnemonic Opcode Mnemonic Opcode Mnemonic Opcode

CLCL 0F CUSE B257 MVST B255
CLCLE A9 MVCL 0E SRST B25E
CLST B25D MVCLE A8 TRE B2A5

The instruction opcodes and mnemonics are shown in the following table:

Opcode Mnemonic Opcode Mnemonic Opcode Mnemonic

0E MVCL A9 CLCLE B25D CLST
0F CLCL B255 MVST B25E SRST
A8 MVCLE B257 CUSE B2A5 TRE

426 Assembler Language Programming for IBM System z™ Servers Version 2.00
Terms and Definitions
C-string
A string of zero or more bytes ending with a zero or “null” byte.
destructive overlap
Destructive overlap occurs when any part of a target operand field is used for a source after
data has been moved into it.
interruptible
An instruction is interruptible if the CPU suspends its operation, updates the registers
involved in the operation and subtracts the instruction's length from the Instruction Address
in the PSW, so that when the program resumes execution, the instruction will start from the
point where it was interrupted.
null byte
A zero or X'00' byte, sometimes indicated by the character n.

Programming Problems
Problem 25.1.(3) Write a program that reads two character strings from two 80-byte records,
and searches for the first and longest matching substring at any offset within the two strings.
Use a blank for the padding character. Print the original strings, the matching substring and its
length, and its offset within each string. Repeat for several pairs of input strings.
For example, if the two strings are 'XYA12345' and '$12345678', the longest matching substring
is '12345' with length 5, at offsets 3 and 1 respectively. The requirement that you find the
longest matching substring means that you shouldn't report a one-byte substring like '1'.

Problem 25.2.(3) + Programs must sometimes isolate a string of characters preceded and fol-
lowed by strings of blanks. For example, if the original string is '•••AB•CD••' (where • means a
blank character), the desired result is the string 'AB•CD'.
Write a program that reads 80-character records and removes leading and trailing blanks. Print
the original record, and the “blank-trimmed” result and its length. Repeat for several input
records.
Some sample input records might include
DC CL80' AB CD ' As in the example above
DC 80C'*' No blanks
DC CL80'AB' No leading blanks
DC CL78' ',C'YZ' No trailing blanks
DC CL80' ' All blanks
You should create other records to exercise your program.

Chapter VII: Bit and Character Data 427

26. Other Types of Character Data (*)

2222222222 6666666666
222222222222 666666666666
22 22 66 66
22 66
22 66
22 66666666666
22