100% found this document useful (1 vote)

540 views1,313 pages

Assembler Language Programming For IBM Z System Servers

The basic bible regarding assembler language for IBM Z system

Uploaded by

a_houzet

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

100% found this document useful (1 vote)

540 views1,313 pages

Assembler Language Programming For IBM Z System Servers

The basic bible regarding assembler language for IBM Z system

Uploaded by

a_houzet

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

Assembler Language Programming

for
IBM z System Servers
Version 1.00

John R. Ehrman

IBM Silicon Valley Lab

First Edition (January 2015)

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
Contract with IBM Corp.

Use, duplication or disclosure restricted by GSA ADP Schedule

Assembler Language Programming for IBM z System Servers

Version 1.00

Contents
Figures
Tables

xxviii

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Foreword

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.

Outline and Overview . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .
Programming Environments
Levels of Difficulty (*) . . . . . . . . . . . . . . . . . . .
Exercises and Programming Problems . . . . . . . . . .
Some Observations . . . . . . . . . . . . . . . . . . . . .
Why Program in Assembler Language (and Why Not)?
Assembler Language Misconceptions
. . . . . . . . . .

Index

xvi

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapter I: Getting Started

Chapter II: z System

. . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

3. Conceptual Structure of z System . . . . . . . . .

3.1. Memory Organization . . . . . . . . . . . . .
3.2. Central Processing Unit . . . . . . . . . . . .
3.3. General Registers
. . . . . . . . . . . . . . .
3.4. Floating-Point Registers
. . . . . . . . . . .
3.5. Program Status Word (PSW)
. . . . . . . .
3.6. Other Registers . . . . . . . . . . . . . . . . .
3.7. Input-Output (I/O) . . . . . . . . . . . . . .
3.8. Features, Facilities, and Assists
. . . . . . .
3.9. Microprograms and Millicode (*) . . . . . .
4. Instruction Execution
. . . . . . . . . . . . . . . .
4.1. Basic Instruction Cycle . . . . . . . . . . . .
4.2. Basic Instruction Types . . . . . . . . . . . .
4.3. Instruction Lengths . . . . . . . . . . . . . .
4.4. Some Operation Codes (*) . . . . . . . . . .
4.5. Interruptions (*) . . . . . . . . . . . . . . . .
4.6. Exceptions and Program Interruptions (*) .
4.7. Machine Language and Assembler Language
4.8. Processor Evolution . . . . . . . . . . . . . .
5. Memory Addressing . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
. .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

1
1
2
2
2
2
5
8
11

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
. .
. .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

13
14
14
15
16
18
18
19
21
24
26
27
27
29
32
33
34
36
38
39
40

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

43
44
45
47
47
48
49
50
50
50
50
52
52
53
55
56
57
59
61
61
63

Contents

iii

. . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

1. Some Basic Items . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.1. Notation and Terminology . . . . . . . . . . . . . . . . . . . .
1.2. Instruction Elements
. . . . . . . . . . . . . . . . . . . . . . .
1.2.1. Register Names . . . . . . . . . . . . . . . . . . . . . . . .
2. Binary and Hexadecimal Numbers . . . . . . . . . . . . . . . . . . .
2.1. Positional Notation and Binary Numbers
. . . . . . . . . . .
2.2. Hexadecimal Numbers . . . . . . . . . . . . . . . . . . . . . .
2.3. Converting Integers from One Base to Another (*) . . . . . .
2.4. Examples of General Conversions (*) . . . . . . . . . . . . . .
2.5. Number Representations . . . . . . . . . . . . . . . . . . . . .
2.6. Logical (Unsigned) Representation . . . . . . . . . . . . . . .
. . . . . . .
2.7. Twos Complement (Signed) Representation (*)
2.8. Computing Two s Complements . . . . . . . . . . . . . . . .
2.9. Sign Extension . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.10. Binary Addition
. . . . . . . . . . . . . . . . . . . . . . . . .
2.11. Binary Subtraction . . . . . . . . . . . . . . . . . . . . . . . .
2.12. How Additions and Subtractions Are Actually Performed (*)
2.13. A Circular View of Binary Arithmetic (*) . . . . . . . . . . .
2.14. Logical (Unsigned) and Arithmetic (Signed) Results (*)
. .
2.15. Examples of Representations (*) . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

5.1. The Addressing Halfword . . . . . . . . . . .

5.2. Examples of Effective Addresses . . . . . . .
5.3. Indexing . . . . . . . . . . . . . . . . . . . . .
5.4. Examples of Indexing . . . . . . . . . . . . .
5.5. Addressing Problems (*) . . . . . . . . . . .
5.6. Address Translation and Virtual Memory (*)
5.7. Summary . . . . . . . . . . . . . . . . . . . .

Chapter III: Assembler Language Programs

.
.
.
.
.
.
.

64
65
65
67
68
69
70

. . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

73
74
74
74
75
75
76
78
81
81
82
84
84
87
87
89
91
93
94
95
96
98
98
99
100
102
104
105
108
108
109
110
110
111
113
113
115
115
117
118
118
119
121
122
123
124
125
127
129
130
131
132
134
135

.
.
.
.
.

.
.
.
.
.
.
. .

.
.
.
.
.
.
.

6. Assembler Language . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1. Processing Your Program . . . . . . . . . . . . . . . . . . . . .
6.1.1. Assembly . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.2. Linking . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.3. Loading and Execution . . . . . . . . . . . . . . . . . . .
6.2. Preparing Assembler Language Statements . . . . . . . . . . .
6.3. Statement Fields . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.1. What s in a Name Field? (*) . . . . . . . . . . . . . . . .
6.4. Writing Programs . . . . . . . . . . . . . . . . . . . . . . . . .
6.5. A Sample Program
. . . . . . . . . . . . . . . . . . . . . . . .
6.6. Basic Macro Instructions . . . . . . . . . . . . . . . . . . . . .
6.7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
7. Self-Defining Terms and Symbols
7.1. Self-Defining Terms . . . . . . . . . . . . . . . . . . . . . . . .
7.2. EBCDIC Character Representation . . . . . . . . . . . . . . .
7.3. Symbols and Attributes . . . . . . . . . . . . . . . . . . . . . .
7.4. Program Relocatability . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
7.5. The Location Counter
7.6. Assigning Values to Symbols . . . . . . . . . . . . . . . . . . .
7.7. Symbols and Variables . . . . . . . . . . . . . . . . . . . . . .
8. Terms, Operators, Expressions, and Operands . . . . . . . . . . . .
8.1. Terms and Operators . . . . . . . . . . . . . . . . . . . . . . .
8.2. Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3. Evaluating Assembly-Time Expressions (*)
. . . . . . . . . .
8.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5. Machine Instruction Statement Operand Formats . . . . . . .
8.6. Details of Expression Evaluation (*)
. . . . . . . . . . . . . .
9. Instructions, Mnemonics, and Operands . . . . . . . . . . . . . . . .
9.1. Basic RR-Type Instructions . . . . . . . . . . . . . . . . . . .
9.2. Writing RR-Type Instructions . . . . . . . . . . . . . . . . . .
9.3. Basic RX-Type Instructions . . . . . . . . . . . . . . . . . . .
9.4. Writing RX-Type Instructions . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
9.5. Explicit and Implied Addresses
9.6. Typical RS- and SI-Type Instructions
. . . . . . . . . . . . .
9.7. Writing RS- and SI-Type Instructions
. . . . . . . . . . . . .
9.8. Typical SS-Type Instructions
. . . . . . . . . . . . . . . . . .
9.9. Writing SS-Type Instructions
. . . . . . . . . . . . . . . . . .
9.10. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10. Establishing and Maintaining Addressability . . . . . . . . . . . . .
10.1. The BASR Instruction
. . . . . . . . . . . . . . . . . . . . .
10.2. Computing Displacements
. . . . . . . . . . . . . . . . . . .
10.3. Explicit Base and Displacement
. . . . . . . . . . . . . . . .
10.4. The USING Assembler Instruction and Implied Addresses .
10.5. Location Counter Reference . . . . . . . . . . . . . . . . . .
10.6. Destroying Base Registers . . . . . . . . . . . . . . . . . . . .
10.7. Calculating Displacements: the Assembly Process, Pass One
10.8. Calculating Displacements: the Assembly Process, Pass Two
10.9. Multiple USING Table Entries . . . . . . . . . . . . . . . . .
10.10. The DROP Assembler Instruction . . . . . . . . . . . . . .
10.11. Addressability Errors . . . . . . . . . . . . . . . . . . . . . .
10.12. Resolutions With Register Zero (*) . . . . . . . . . . . . . .
10.13. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.13.1. How the Assembler Helps . . . . . . . . . . . . . . . .

Assembler Language Programming for IBM z System Servers

Version 1.00

.
.
.
.
.
.

Chapter IV: Defining Constants and Storage Areas

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

137
138
139
140
140
141
142
143
144
145
145
145
146
148
148
149
151
152
154
156
158
159
161
161
162
164
168
169
171
173
175
176

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

179
180
181
182
184
186
187
189
192
194
195
196
197
198
198
199
199
199
200
201
206
206
207
208
208
208
209
212
214

. . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

11. Defining Constants . . . . . . . . . . . . . . . . . . . . .

11.1. Defining Constants . . . . . . . . . . . . . . . . . .
11.2. DC Instruction Statements and Operands . . . . .
11.2.1. Blanks in Nominal Values . . . . . . . . . . .
11.3. Boundary Alignment . . . . . . . . . . . . . . . . .
11.4. Length Modifiers . . . . . . . . . . . . . . . . . . .
11.5. Duplication Factors and Multiple Operands . . .
11.6. Multiple Nominal Values . . . . . . . . . . . . . .
11.7. Length Attributes . . . . . . . . . . . . . . . . . . .
11.8. Decimal Exponents (*)
. . . . . . . . . . . . . . .
11.8.1. Decimal Exponents . . . . . . . . . . . . . . .
11.8.2. Exponent Modifiers
. . . . . . . . . . . . . .
12. Basic Constants . . . . . . . . . . . . . . . . . . . . . . .
12.1. F-Type and H-Type Constants . . . . . . . . . . .
12.2. A-Type Address Constants . . . . . . . . . . . . .
12.3. Y-Type Address Constants . . . . . . . . . . . . .
12.4. Constants of Types C, B, and X . . . . . . . . . .
12.5. Padding and Truncation . . . . . . . . . . . . . . .
12.6. Literals . . . . . . . . . . . . . . . . . . . . . . . . .
12.7. The LTORG Assembler Instruction . . . . . . . .
12.8. Type Extensions . . . . . . . . . . . . . . . . . . .
13. Data Storage Definition
. . . . . . . . . . . . . . . . . .
13.1. Storage Areas: The DS Assembler Instruction . .
13.2. Zero Duplication Factor . . . . . . . . . . . . . . .
13.3. The EQU Assembler Instruction . . . . . . . . . .
13.4. EQU Instruction Extended Syntax (*) . . . . . . .
13.5. The ORG Assembler Instruction . . . . . . . . . .
13.6. Parameterization . . . . . . . . . . . . . . . . . . .
13.7. Constants Depending on the Location Counter .
13.8. Assembly Time and Execution Time, Revisited (*)
13.9. Summary Observations . . . . . . . . . . . . . . .

Chapter V: Basic Instructions

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

14. General Register Data Transmission . . . . . . . . . . . . . . . . . . . . . .

14.1. Load and Store Instructions
. . . . . . . . . . . . . . . . . . . . . . .
14.2. Multiple Loads and Stores
. . . . . . . . . . . . . . . . . . . . . . . .
14.3. Halfword Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
14.4. Insert and Store Character
14.5. ICM and STCM Instructions . . . . . . . . . . . . . . . . . . . . . . .
14.6. RR-Type Data Transmission Instructions
. . . . . . . . . . . . . . .
14.7. Load, Store, and Insert for 64-bit General Registers . . . . . . . . . .
14.8. RR-Type Data Transmission Instructions for 64-bit General Registers
14.9. The Load and Test Instructions . . . . . . . . . . . . . . . . . . . . .
14.10. Mixed 32- and 64-bit Operands . . . . . . . . . . . . . . . . . . . . .
14.11. Other General Register Load Instructions (*) . . . . . . . . . . . . .
14.11.1. Load Byte Instructions . . . . . . . . . . . . . . . . . . . . . . .
14.11.2. Load Logical Character Instructions . . . . . . . . . . . . . . .
14.11.3. Load Logical Halfword Instructions
. . . . . . . . . . . . . . .
14.11.4. Load Logical (Word) Instructions . . . . . . . . . . . . . . . . .
14.11.5. Load Logical Thirty One Bit Instructions . . . . . . . . . . . .
14.12. Misunderstandings to Avoid . . . . . . . . . . . . . . . . . . . . . . .
14.13. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15. Testing the Condition Code: Conditional Branching . . . . . . . . . . . . .
15.1. The Branch Address . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15.2. The Branch Mask and Branch Condition . . . . . . . . . . . . . . . .
15.3. Examples of Conditional Branch Instructions
. . . . . . . . . . . . .
15.4. No-Operation Instructions
. . . . . . . . . . . . . . . . . . . . . . . .
15.4.1. Special No-Operation Instructions (*) . . . . . . . . . . . . . . .
15.5. Conditional No-Operation
. . . . . . . . . . . . . . . . . . . . . . . .
15.6. Extended Mnemonics . . . . . . . . . . . . . . . . . . . . . . . . . . .
15.7. A Comment on Programming Style . . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

Contents

16.

17.

18.

19.

15.8. A Design Oversight and a Modern Correction (*) .

15.9. Summary . . . . . . . . . . . . . . . . . . . . . . . . .
Fixed-Point Binary Addition, Subtraction, and Comparison
16.1. Signed-Arithmetic Add and Subtract Instructions . .
16.2. Signed-Arithmetic Operations Using 32-Bit Registers
16.3. Signed-Arithmetic Operations Using 64-Bit Registers
16.4. Signed-Arithmetic Compare Instructions . . . . . . .
16.5. Logical-Arithmetic Add and Subtract Instructions . .
16.6. Add With Carry, Subtract With Borrow (*)
. . . . .
16.7. Operations With Mixed 64-Bit and 32-Bit Operands
16.8. Logical-Arithmetic Compare Instructions . . . . . . .
16.9. Retrieving and Setting the Program Mask (*)
. . . .
16.10. Summary . . . . . . . . . . . . . . . . . . . . . . . . .
Binary Shifting . . . . . . . . . . . . . . . . . . . . . . . . . .
17.1. Unit Shifts . . . . . . . . . . . . . . . . . . . . . . . . .
17.2. Single-Length Logical Shifts
. . . . . . . . . . . . . .
17.2.1. Three-Operand Shift Instructions . . . . . . . . .
17.3. Double-Length Logical Shifts . . . . . . . . . . . . . .
17.4. Arithmetic Shift Instructions . . . . . . . . . . . . . .
17.5. Rotating Shifts . . . . . . . . . . . . . . . . . . . . . .
17.6. Calculated Shift Amounts . . . . . . . . . . . . . . . .
17.7. Bit-Length Constants (*) . . . . . . . . . . . . . . . .
17.8. Summary . . . . . . . . . . . . . . . . . . . . . . . . .
Binary Multiplication and Division . . . . . . . . . . . . . .
18.1. Overview of Multiplication Instructions . . . . . . . .
18.2. Arithmetic (Signed) Multiplication Instructions
. . .
18.2.1. Double-Length Arithmetic Products . . . . . . .
18.2.2. Single-Length Arithmetic Products . . . . . . . .
18.3. Logical (Unsigned) Multiplication Instructions . . . .
18.4. How Multiplication Is Done (*) . . . . . . . . . . . .
18.5. Division Instructions . . . . . . . . . . . . . . . . . . .
18.6. Arithmetic (Signed) Division Instructions . . . . . . .
18.6.1. Double-Length Division . . . . . . . . . . . . . .
18.6.2. Single-Length Division . . . . . . . . . . . . . . .
18.7. Logical (Unsigned) Division Instructions . . . . . . .
18.8. How Division Is Done (*)
. . . . . . . . . . . . . . .
18.9. Summary . . . . . . . . . . . . . . . . . . . . . . . . .
Logical Operations
. . . . . . . . . . . . . . . . . . . . . . .
19.1. Logical Operations . . . . . . . . . . . . . . . . . . . .
19.2. Register-Based Logical Instructions . . . . . . . . . .
19.3. Logical AND . . . . . . . . . . . . . . . . . . . . . . .
19.4. Logical OR . . . . . . . . . . . . . . . . . . . . . . . .
19.5. Logical Exclusive OR . . . . . . . . . . . . . . . . . .
19.6. Interesting Uses of Logical Instructions (*) . . . . . .
19.7. Summary . . . . . . . . . . . . . . . . . . . . . . . . .

Chapter VI: Addressing, Immediate Operands, and Loops

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

214
215
218
218
219
222
223
225
229
231
233
235
236
242
243
245
247
248
252
257
258
259
261
264
264
265
265
267
270
272
274
275
275
278
279
280
283
288
289
289
290
291
292
295
298

. . . . . . .
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

301
302
302
302
302
304
306
309
314
314
317
319
319
319
322
322

. . .
. . .
. .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

20. Address Generation and Addressing Modes . . . . . . . . . . . . .

20.1. Address Generation
. . . . . . . . . . . . . . . . . . . . . . .
20.1.1. Address Generation With 12-Bit Displacements . . . .
20.1.2. Address Generation With 20-Bit Displacements . . . .
20.1.3. Address Generation With Relative-Immediate Operands
20.2. Addressing Modes . . . . . . . . . . . . . . . . . . . . . . . .
20.3. Load Address Instructions
. . . . . . . . . . . . . . . . . . .
20.4. 64-Bit Virtual Addresses . . . . . . . . . . . . . . . . . . . . .
20.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21. Immediate Operands . . . . . . . . . . . . . . . . . . . . . . . . . .
21.1. Insert and Load Instructions with Immediate Operands . . .
21.1.1. Logical-Immediate Insert Instructions . . . . . . . . . .
21.1.2. Arithmetic- and Logical-Immediate Load Instructions .
21.2. Arithmetic Instructions with Immediate Operands . . . . . .
21.2.1. Arithmetic-Immediate Add and Subtract Instructions .

Assembler Language Programming for IBM z System Servers

Version 1.00

.
.
.
.
.
.
.
.
.
.

21.2.2. Arithmetic-Immediate Compare Instructions

21.2.3. Arithmetic-Immediate Multiply Instructions
21.3. Logical Operations with Immediate Operands .
21.3.1. Logical-Immediate AND Instructions . . .
21.3.2. Logical-Immediate OR Instructions . . . .
21.3.3. Logical-Immediate XOR Instructions . . .
21.4. Summary . . . . . . . . . . . . . . . . . . . . . .
22. Branches, Loops, and Indexing . . . . . . . . . . . . .
22.1. Branch Relative on Condition Instructions . . .
22.2. A Simple Example of a Loop . . . . . . . . . . .
22.3. Simple Tables and Array Indexing . . . . . . . .
22.4. Branch on Count Instructions . . . . . . . . . .
. . . . . . . . . . . . . . . .
22.5. Looping in General
22.6. Branch on Index Instructions . . . . . . . . . . .
22.7. Examples Using BXLE . . . . . . . . . . . . . .
22.8. Examples Using BXH . . . . . . . . . . . . . . .
22.9. Specialized Uses of BXH and BXLE (*) . . . .
22.10. Summary . . . . . . . . . . . . . . . . . . . . . .

Chapter VII: Bit and Character Data

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

323
323
324
324
324
325
326
330
330
333
334
335
340
342
344
347
348
350

. . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

353
354
354
355
355
356
358
360
361
363
364
365
367
367
369
370
372
373
374
374
375
376
378
379
380
384
385
388
390
391
392
393
394
397
404
404
406
408
411
412
414
415
416

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

23. Bit Data and Instructions

. . . . . . . . . . . . . . . . . . . . . . . . . . .
23.1. SI-Type Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . .
23.2. MVI Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23.3. NI, OI, and XI Instructions . . . . . . . . . . . . . . . . . . . . . . .
23.4. CLI Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23.5. Test Under Mask Instructions . . . . . . . . . . . . . . . . . . . . .
23.6. Bit Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23.7. Bit-Naming Problems (*) . . . . . . . . . . . . . . . . . . . . . . . .
23.8. A Conversion Example . . . . . . . . . . . . . . . . . . . . . . . . .
23.9. Instruction Modification (*)
. . . . . . . . . . . . . . . . . . . . . .
23.10. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24. Character Data and Basic Instructions . . . . . . . . . . . . . . . . . . . .
24.1. Basic SS-Type Instructions . . . . . . . . . . . . . . . . . . . . . . .
24.2. Operand Specifications . . . . . . . . . . . . . . . . . . . . . . . . . .
24.3. Implied Lengths
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24.4. Symbol Length Attribute References
. . . . . . . . . . . . . . . . .
24.5. The Encoded Length L (*) . . . . . . . . . . . . . . . . . . . . . .
24.6. The MVC and MVCIN Instructions
. . . . . . . . . . . . . . . . .
24.6.1. MVC: Move Characters . . . . . . . . . . . . . . . . . . . . . .
24.6.2. MVCIN: Move Characters Inverse . . . . . . . . . . . . . . . .
24.6.3. MVCOS: Move Characters With Optional Specifications . . .
. . . . . . . . . . . . . . . . . .
24.7. The NC, OC, and XC Instructions
24.8. The CLC Instruction
. . . . . . . . . . . . . . . . . . . . . . . . . .
24.9. The TR Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . .
24.10. The TRT and TRTR Instructions . . . . . . . . . . . . . . . . . .
24.10.1. T R T
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24.10.2. T R T R
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24.11. The Execute Instructions . . . . . . . . . . . . . . . . . . . . . . . .
24.11.1. Execute Instruction Without Target-Instruction Modification
24.11.2. Execute Instruction with Target-Instruction Modification . .
24.11.3. Comments on the Execute Instructions (*) . . . . . . . . . .
24.11.4. Modifiable Parts of Instructions . . . . . . . . . . . . . . . . .
24.12. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25. Character Data and Extended Instructions . . . . . . . . . . . . . . . . . .
25.1. Move Long and Compare Logical Long
. . . . . . . . . . . . . . .
25.1.1. MVCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25.1.2. CLCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25.2. Move Long and Compare Logical Long Extended
. . . . . . . . .
25.2.1. MVCLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25.2.2. CLCLE
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25.3. Special String-Handling Instructions . . . . . . . . . . . . . . . . . .
25.4. Search String Instruction
. . . . . . . . . . . . . . . . . . . . . . . .

Contents

vii

25.5. Move String Instruction . . . . . . . . . . . . . . . . . . . .

25.6. Compare Logical String Instruction . . . . . . . . . . . . .
25.7. Translate Extended Instruction . . . . . . . . . . . . . . . .
25.8. Compare Until Substring Equal Instruction (*)
. . . . . .
25.9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26. Other Types of Character Data (*) . . . . . . . . . . . . . . . . .
26.1. Character Representations . . . . . . . . . . . . . . . . . . .
26.1.1. BCD characters . . . . . . . . . . . . . . . . . . . . . .
26.2. EBCDIC Representations and Code Pages . . . . . . . . .
26.3. ASCII . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26.4. Double-Byte EBCDIC Data (*) . . . . . . . . . . . . . . .
26.4.1. The DBCS Option (*) . . . . . . . . . . . . . . . . . .
26.4.2. G-Type DBCS Constants and Self-Defining Terms (*)
26.4.3. Continuation Rules for DBCS Data (*) . . . . . . . .
26.5. Unicode . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26.5.1. The Unicode Representation . . . . . . . . . . . . . .
26.5.2. Glyphs and Characters . . . . . . . . . . . . . . . . . .
26.5.3. Unicode Character Constants . . . . . . . . . . . . . .
26.6. Unicode Instructions . . . . . . . . . . . . . . . . . . . . . .
26.6.1. String Search, Compare, and Move
. . . . . . . . . .
26.6.3. Optional Operands . . . . . . . . . . . . . . . . . . . .
26.6.4. Translation
. . . . . . . . . . . . . . . . . . . . . . . .
26.6.5. Conversion Among Transformation Formats . . . . .
26.7. Byte Reversal and Workstation Data
. . . . . . . . . . . .
26.7.1. Byte-Reversing Instructions . . . . . . . . . . . . . . .
26.8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapter VIII: Zoned and Packed Decimal Data and Operations

27. Zoned and Packed Decimal Representations
. . . . . . . . .
27.1. Zoned Decimal Representation . . . . . . . . . . . . . .
27.1.1. Why Zoned Decimal Is The Way It Is (*)
. . . .
27.2. Zoned Decimal Constants . . . . . . . . . . . . . . . . .
27.3. Packed Decimal Representation . . . . . . . . . . . . .
27.4. Packed Decimal Constants . . . . . . . . . . . . . . . .
27.4.1. Scale Attributes and Packed Decimal Constants (*)
27.5. Converting Between Packed and Zoned . . . . . . . . .
27.6. The PACK Instruction . . . . . . . . . . . . . . . . . .
27.7. The UNPK Instruction . . . . . . . . . . . . . . . . . .
27.8. Packing and Unpacking ASCII and Unicode Data (*)
27.8.1. Packing ASCII and Unicode Data . . . . . . . . .
27.8.2. Unpacking ASCII and Unicode Data . . . . . . .
27.9. Printing Hexadecimal Values . . . . . . . . . . . . . . .
27.10. Summary . . . . . . . . . . . . . . . . . . . . . . . . . .
28. Packed Decimal Arithmetic
. . . . . . . . . . . . . . . . . . .
28.1. General Rules . . . . . . . . . . . . . . . . . . . . . . . .
28.1.1. Precision and Accuracy
. . . . . . . . . . . . . . .
28.2. Decimal Addition and Subtraction . . . . . . . . . . . .
28.3. Decimal Comparison
. . . . . . . . . . . . . . . . . . .
28.4. Decimal Multiplication
. . . . . . . . . . . . . . . . . .
28.5. Decimal Division . . . . . . . . . . . . . . . . . . . . . .
28.6. True Decimal Addition (*) . . . . . . . . . . . . . . . .
28.7. Complement Decimal Addition (*)
. . . . . . . . . . .
29. Packed Decimal Instructions . . . . . . . . . . . . . . . . . . .
29.1. TP Instruction . . . . . . . . . . . . . . . . . . . . . . .
29.2. ZAP Instruction . . . . . . . . . . . . . . . . . . . . . .
29.3. AP and SP Instructions . . . . . . . . . . . . . . . . . .
29.4. CP Instruction . . . . . . . . . . . . . . . . . . . . . . .
29.5. MP Instruction . . . . . . . . . . . . . . . . . . . . . . .
29.6. DP Instruction . . . . . . . . . . . . . . . . . . . . . . .
29.7. SRP Instruction
. . . . . . . . . . . . . . . . . . . . . .
29.7.1. Biased and Unbiased Rounding with SRP
. . . .
29.8. MVO Instruction . . . . . . . . . . . . . . . . . . . . . .

viii

Assembler Language Programming for IBM z System Servers

Version 1.00

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

418
420
422
424
426
429
429
429
430
432
433
435
435
436
437
437
438
439
440
440
442
443
445
448
449
451

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

453
454
454
457
458
459
461
461
463
465
468
471
472
473
475
476
477
477
478
478
480
481
483
484
486
489
490
491
493
496
497
500
502
504
507

.
.
.
.
.
.
.
.
.
.
.
.

29.9. Decimal Shifting Using MVO (*)

. . . . . . . . . . . . .
29.9.1. Shift Right an Odd Number of Digits . . . . . . . .
29.9.2. Shift Left an Odd Number of Digits . . . . . . . . .
29.9.3. Shifting an Even Number of Digits . . . . . . . . . .
29.9.4. Shifting Left an Even Number of Digits . . . . . . .
29.9.5. Shifting Right an Even Number of Digits . . . . . .
29.10. Scaled Packed Decimal Computations: General Rules .
29.10.1. Precision and Scale . . . . . . . . . . . . . . . . . .
29.10.2. General Rules: Addition and Subtraction
. . . . .
29.10.3. General Rules: Multiplication . . . . . . . . . . . .
29.10.4. General Rules: Division (*) . . . . . . . . . . . . .
29.10.5. COBOL and PL/I Notations (*) . . . . . . . . . .
29.11. Example of a Packed Decimal Business Computation
29.11.1. The Wholesalers Calculation . . . . . . . . . . . .
29.11.2. The Retailers Calculation . . . . . . . . . . . . . .
29.11.3. Comments . . . . . . . . . . . . . . . . . . . . . . .
29.11.4. Using Integer and Scale Attributes (*) . . . . . . .
29.12. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .
30. Converting and Formatting Packed Decimal Data . . . . . . .
30.1. CVD, CVDY, and CVDG Instructions . . . . . . . . . .
30.2. CVB, CVBY, and CVBG Instructions
. . . . . . . . . .
30.3. Editing Overview . . . . . . . . . . . . . . . . . . . . . . .
30.4. Simple Examples of Editing . . . . . . . . . . . . . . . . .
30.5. Single-Field Editing
. . . . . . . . . . . . . . . . . . . . .
30.5.1. Editing Negative Values . . . . . . . . . . . . . . . .
30.5.2. Protecting High-Order Fields . . . . . . . . . . . . .
30.6. The EDMK Instruction . . . . . . . . . . . . . . . . . . .
30.7. Editing Multiple Fields (*) . . . . . . . . . . . . . . . . .
30.8. Summary Comments on Editing (*) . . . . . . . . . . . .

Chapter IX: Floating-Point Data and Operations

. . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.

. . . . . . . . . . . .
31. Floating-Point Number Representation
31.1. Scaled Fixed-Point Arithmetic . . . . . . . . . . . . . .
31.2. Converting Fractions . . . . . . . . . . . . . . . . . . . .
31.3. Mixed Integer-Fraction Representation . . . . . . . . .
31.3.1. Scaled Fixed-Point Binary Arithmetic (*) . . . . .
31.3.2. Scaled Fixed-Point Binary Constants (*) . . . . .
31.4. Why Use Floating-Point Numbers? . . . . . . . . . . .
31.4.1. Precision and Accuracy
. . . . . . . . . . . . . . .
31.5. Floating-Point Representations . . . . . . . . . . . . . .
31.5.1. Some Additional Details (*) . . . . . . . . . . . . .
31.6. z System Floating-Point Representations . . . . . . . .
31.7. z System Floating-Point Registers . . . . . . . . . . . .
31.8. Floating-Point Constants . . . . . . . . . . . . . . . . .
31.9. Representation-Independent Floating-Point Instructions
31.9.1. Register-Storage Instructions . . . . . . . . . . . .
31.9.2. Register-Register Instructions . . . . . . . . . . . .
31.9.3. Load-Zero Instructions
. . . . . . . . . . . . . . .
31.9.4. GPR-FPR Copying Instructions . . . . . . . . . .
31.9.5. Sign-Copying Instruction . . . . . . . . . . . . . .
31.10. Summary . . . . . . . . . . . . . . . . . . . . . . . . . .
32. Basic Concepts of Floating-Point Arithmetic . . . . . . . . .
32.1. Floating-Point Multiplication . . . . . . . . . . . . . . .
32.2. Pre-Normalization of Fraction Operands . . . . . . . .
32.3. Floating-Point Rounding . . . . . . . . . . . . . . . . .
32.4. Guard and Rounding Digits (*)
. . . . . . . . . . . . .
32.5. Integer-Based Representations (*) . . . . . . . . . . . .
32.6. Floating-Point Division . . . . . . . . . . . . . . . . . .
32.7. Floating-Point Addition and Subtraction . . . . . . . .
32.8. Floating-Point Precision . . . . . . . . . . . . . . . . . .
32.9. Floating-Point Range . . . . . . . . . . . . . . . . . . .
32.10. Exponents and Characteristics . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

509
509
510
510
511
511
513
513
514
514
515
516
517
517
518
520
520
521
522
522
524
526
528
531
531
532
533
534
535

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

539
540
540
541
543
544
545
547
547
548
550
551
551
554
555
555
555
556
557
557
558
560
560
561
561
562
564
564
565
567
569
571

.
.
.
.
.
.
.
.
.
.
.
.

Contents

32.11. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33. Hexadecimal Floating-Point Data and Operations . . . . . . . . . . . . . . . . . .
33.1. Hexadecimal Floating-Point Data . . . . . . . . . . . . . . . . . . . . . . . .
33.2. Writing Hexadecimal Floating-Point Constants
. . . . . . . . . . . . . . . .
33.2.1. Decimal Exponents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33.3. Modifiers
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33.3.1. Length Modifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33.3.2. Scale Modifiers (*) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33.3.3. Exponent Modifiers
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33.4. Subtypes Q and H (*) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33.4.1. LQ-Type Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33.4.2. Subtype H . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33.4.3. Difficult Numbers (*) . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33.5. Basic Hexadecimal Floating-Point Instructions . . . . . . . . . . . . . . . . .
33.6. Hexadecimal Floating-Point RR-Type Data-Movement Instructions . . . .
33.7. Hexadecimal Floating-Point Multiplication . . . . . . . . . . . . . . . . . . .
33.7.1. Exponent Overflow and Underflow. . . . . . . . . . . . . . . . . . . . .
33.8. Hexadecimal Floating-Point Division . . . . . . . . . . . . . . . . . . . . . .
33.8.1. The Halve Instructions (*)
. . . . . . . . . . . . . . . . . . . . . . . . .
33.9. Hexadecimal Floating-Point Addition and Subtraction . . . . . . . . . . . .
33.9.1. Unnormalized Addition and Subtraction
. . . . . . . . . . . . . . . . .
33.9.2. Older Uses of Unnormalized Addition (*) . . . . . . . . . . . . . . . . .
33.10. Adding Operands of Like Sign (*) . . . . . . . . . . . . . . . . . . . . . . .
33.11. Adding Operands of Unlike Sign (*) . . . . . . . . . . . . . . . . . . . . . .
33.11.1. Hexadecimal Floating-Point Complement Addition (*) . . . . . . . .
33.11.2. Implementing Hexadecimal Floating-Point Complement Addition (*)
33.12. Hexadecimal Floating-Point Comparison . . . . . . . . . . . . . . . . . . .
33.13. Rounding and Lengthening Instructions . . . . . . . . . . . . . . . . . . . .
33.13.1. Rounding Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . .
33.13.2. Lengthening Instructions . . . . . . . . . . . . . . . . . . . . . . . . . .
33.14. Converting Between Binary Integers and HFP . . . . . . . . . . . . . . . .
33.14.1. Converting Binary Integers to Hexadecimal Floating-Point . . . . . .
33.14.2. Converting Hexadecimal Floating-Point to Binary Integers . . . . . .
33.15. Hexadecimal Floating-Point Integers and Remainders (*) . . . . . . . . . .
33.16. Square Root Instructions (*) . . . . . . . . . . . . . . . . . . . . . . . . . .
33.17. Multiply and Add/Subtract Instructions (*) . . . . . . . . . . . . . . . . . .
33.18. Some Hexadecimal Floating-Point History (*) . . . . . . . . . . . . . . . .
33.18.1. Zeroing Floating-Point Registers . . . . . . . . . . . . . . . . . . . . .
33.18.2. Hexadecimal Floating-Point to Binary Conversion Comments (*) . .
33.18.3. Initial System/360 Oversights . . . . . . . . . . . . . . . . . . . . . . .
33.19. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34. Binary Floating-Point Data and Operations . . . . . . . . . . . . . . . . . . . . . .
34.1. Binary Floating-Point Data . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34.1.1. Data Representations
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
34.1.2. Normal Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34.1.3. Special Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34.1.4. Range of the Representation . . . . . . . . . . . . . . . . . . . . . . . .
34.2. Writing Binary Floating-Point Constants . . . . . . . . . . . . . . . . . . . .
34.2.1. Decimal Exponents and Exponent Modifiers . . . . . . . . . . . . . . .
34.2.2. Length Modifiers (*) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34.3. Binary Floating-Point Arithmetic in General . . . . . . . . . . . . . . . . . .
34.3.1. Rounding Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34.3.2. Denormalized Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . .
34.3.3. Arithmetic with Zero, Infinity, and NaNs . . . . . . . . . . . . . . . . .
34.4. Binary Floating-Point Exceptions, Interruptions, and Controls
. . . . . . .
34.4.1. Binary Floating-Point Exceptions (*) . . . . . . . . . . . . . . . . . . .
34.4.2. FPC Register Instructions (*) . . . . . . . . . . . . . . . . . . . . . . . .
34.4.3. Exception Actions (*) . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34.4.4. Scaled Exponents (*) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34.5. Basic Binary Floating-Point Instructions . . . . . . . . . . . . . . . . . . . .
34.6. Binary Floating-Point RR-Type Data Movement Instructions . . . . . . . .
34.7. Binary Floating-Point Multiplication . . . . . . . . . . . . . . . . . . . . . .

Assembler Language Programming for IBM z System Servers

Version 1.00

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

572
573
573
577
578
579
579
579
580
581
581
582
583
584
584
586
589
590
591
592
595
596
598
599
599
601
602
603
603
605
606
607
608
611
613
614
616
616
616
616
617
625
625
626
627
627
628
629
631
632
633
633
634
635
635
636
637
638
639
640
642
644

34.8. Binary Floating-Point Division . . . . . . . . . . . . . . . . . . . . . . . . .

34.9. Binary Floating-Point Addition and Subtraction . . . . . . . . . . . . . . .
34.10. Binary Floating-Point Comparison . . . . . . . . . . . . . . . . . . . . . .
34.10.1. Compare and Signal (*)
. . . . . . . . . . . . . . . . . . . . . . . . .
34.11. Binary Floating-Point Rounding and Lengthening Instructions (*)
. . .
34.11.1. Rounding Instructions (*) . . . . . . . . . . . . . . . . . . . . . . . .
34.11.2. Lengthening Instructions (*) . . . . . . . . . . . . . . . . . . . . . . .
34.12. Converting Between BFP and Binary Integers (*) . . . . . . . . . . . . .
34.12.1. Converting Binary Integers to Binary Floating-Point (*) . . . . . . .
34.12.2. Converting Binary Floating-Point to Binary Integers (*) . . . . . . .
34.13. Binary Floating-Point Integers and Remainders (*)
. . . . . . . . . . . .
34.13.1. Load FP Integer Instructions . . . . . . . . . . . . . . . . . . . . . .
34.13.2. Divide to Integer Instructions (*) . . . . . . . . . . . . . . . . . . . .
34.14. Binary Floating-Point Square Root Instructions (*) . . . . . . . . . . . .
34.15. Binary Floating-Point Multiply and Add/Subtract (*) . . . . . . . . . . .
34.16. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35. Decimal Floating-Point Data and Operations . . . . . . . . . . . . . . . . . . . .
35.1. Representations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35.1.1. Conceptual View of the Decimal Floating-Point Representation . . .
35.2. z System Decimal Floating-Point Data Encoding and Representation (*)
35.2.1. Decimal Floating-Point Data Encoding (*) . . . . . . . . . . . . . . .
35.2.2. Decimal Floating-Point Data Representation (*) . . . . . . . . . . . .
35.2.3. Decimal Floating-Point Combination Field (*) . . . . . . . . . . . . .
35.3. Decimal Floating-Point Constants . . . . . . . . . . . . . . . . . . . . . . .
35.3.1. Rounding-Mode Suffixes for Decimal Floating-Point Constants . . .
35.3.2. Decimal Exponents and Modifiers . . . . . . . . . . . . . . . . . . . .
35.4. Decimal Floating-Point Data Classes (*) . . . . . . . . . . . . . . . . . . .
35.5. Decimal Floating-Point Operations: Rounding, Quanta, and Exceptions .
35.5.1. Rounding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35.5.2. Preferred Exponent and Quantum . . . . . . . . . . . . . . . . . . . .
35.5.3. DFP Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35.4.4. Overflow/Underflow Scale Factors (*) . . . . . . . . . . . . . . . . . .
35.6. Decimal Floating-Point Data Movement Instructions . . . . . . . . . . . .
35.6.1. Copy Sign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . .
35.6.2. Copy between General and Floating-Point Registers
35.6.3. Copy Among Floating-Point Registers
. . . . . . . . . . . . . . . . .
35.7. Decimal Floating-Point Arithmetic Instructions . . . . . . . . . . . . . . .
35.7.1. Multiplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35.7.2. Division . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35.7.3. Addition and Subtraction . . . . . . . . . . . . . . . . . . . . . . . . .
35.8. Decimal Floating-Point Compare Instructions . . . . . . . . . . . . . . . .
35.8.1. Compare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35.8.2. Compare and Signal . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35.8.3. Compare Biased Exponent . . . . . . . . . . . . . . . . . . . . . . . .
35.9. Converting Decimal Floating-Point To and From Fixed Binary . . . . . .
35.9.1. Convert From Fixed Binary to DFP . . . . . . . . . . . . . . . . . . .
35.9.2. Convert From DFP To Fixed Binary . . . . . . . . . . . . . . . . . .
35.10. Converting Decimal Floating-Point To/From Packed and Zoned Decimal
35.10.1. Convert To/From Signed Packed Decimal . . . . . . . . . . . . . . .
35.10.2. Convert To/From Unsigned Packed Decimal . . . . . . . . . . . . .
35.10.3. Convert To/From Zoned Decimal . . . . . . . . . . . . . . . . . . .
35.11. Decimal Floating-Point Load Operations . . . . . . . . . . . . . . . . . .
35.11.1. Load and Test, Complement, Negative, and Positive . . . . . . . . .
35.11.2. Load Floating-Point Integer . . . . . . . . . . . . . . . . . . . . . . .
35.11.3. Load Lengthened . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35.11.4. Load Rounded
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35.12. Decimal Floating-Point Miscellaneous Operations (*) . . . . . . . . . . .
35.12.1. Set Decimal Rounding Mode . . . . . . . . . . . . . . . . . . . . . .
35.12.2. Extract and Insert Biased Exponent
. . . . . . . . . . . . . . . . . .
35.12.3. Extract Significance . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35.12.4. Shift Significand Left/Right . . . . . . . . . . . . . . . . . . . . . . .
35.12.5. Quantize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

Contents

646
648
649
650
651
651
651
653
653
653
655
655
656
658
659
660
667
668
669
671
671
673
674
676
677
678
679
681
681
682
684
685
686
686
686
686
687
688
689
689
691
691
692
692
693
693
694
696
696
697
698
701
701
702
702
703
704
704
705
706
707
708

35.12.6. Reround . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35.12.7. Decimal Floating-Point Data Groups (*)
. . . . . . . . . . . . .
35.13. Example of a Decimal Floating-Point Business Computation . . .
35.13.1. The Wholesalers Calculation . . . . . . . . . . . . . . . . . . . .
35.13.2. The Retailers Calculation . . . . . . . . . . . . . . . . . . . . . .
35.13.3. Comparing Packed and Floating Decimal . . . . . . . . . . . . .
35.14. Decimal Floating-Point Binary-Significand Format (*)
. . . . . . . .
35.15. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36. Floating-Point Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36.1. Floating-Point Data Representations
. . . . . . . . . . . . . . . . . . .
36.2. Floating-Point Properties . . . . . . . . . . . . . . . . . . . . . . . . . .
36.3. Floating-Point Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . .
36.4. Defining Floating-Point Constants . . . . . . . . . . . . . . . . . . . . .
36.5. Converting Among Decimal, Hexadecimal and Binary Representations
36.5.1. In-Out Conversions
. . . . . . . . . . . . . . . . . . . . . . . . . .
36.5.2. Out-In Conversions
. . . . . . . . . . . . . . . . . . . . . . . . . .
36.5.3. The PFPO Instruction (*) . . . . . . . . . . . . . . . . . . . . . . .
36.6. Real and Realistic (Floating-Point) Arithmetic . . . . . . . . . . .
36.7. When Does Zero Not Behave Like Zero? (*) . . . . . . . . . . . . . . .
36.7.1. Hexadecimal Floating-Point . . . . . . . . . . . . . . . . . . . . . .
36.7.2. Binary Floating-Point . . . . . . . . . . . . . . . . . . . . . . . . .
36.7.3. Decimal Floating-Point . . . . . . . . . . . . . . . . . . . . . . . .
36.8. Examples of Former Floating-Point Representations and Behaviors (*)
36.9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapter X: Large Programs and Modularization

Assembler Language Programming for IBM z System Servers

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

710
712
714
714
715
715
716
717
725
725
727
727
728
729
729
730
731
731
734
734
735
735
736
737

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
. .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

741
742
742
743
743
745
748
749
751
752
753
754
756
759
759
760
762
763
764
764
765
768
768
770
772
773
773
776
776
778
783
783
784
785
785
786
788

.
.
.
.
.
.
.
.
.

. . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

37. Subroutines and Linkage Conventions . . . . . . . . . . . . . . . . . . . . . .

37.1. Basic Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37.1.1. Linkage
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37.1.2. The Branch and Save Instructions . . . . . . . . . . . . . . . . . .
37.1.3. Argument Passing
. . . . . . . . . . . . . . . . . . . . . . . . . . .
37.1.4. Returned Values . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37.1.5. Status Preservation . . . . . . . . . . . . . . . . . . . . . . . . . . .
37.2. A General Linkage Convention
. . . . . . . . . . . . . . . . . . . . . .
37.3. Argument Passing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37.3.1. Variable-Length Argument Lists . . . . . . . . . . . . . . . . . . .
37.3.2. Argument Lists with 64-Bit Addresses . . . . . . . . . . . . . . . .
37.4. Save Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37.4.1. Extended Save Area Conventions (*)
. . . . . . . . . . . . . . . .
37.4.2. Format-4 Save Area Conventions for 64-bit Registers (*) . . . . .
37.4.3. Format-5 Save Area Conventions for 32- and 64-bit Registers (*)
37.5. Additional Conventions (*) . . . . . . . . . . . . . . . . . . . . . . . . .
37.5.1. Entry Point Identifiers (*) . . . . . . . . . . . . . . . . . . . . . . .
37.5.2. Calling Point Identifiers (*) . . . . . . . . . . . . . . . . . . . . . .
37.5.3. Save Area Return Flags (*) . . . . . . . . . . . . . . . . . . . . . .
37.5.4. Return Codes (*) . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37.5.5. Conventions for Floating-Point Registers. . . . . . . . . . . . . . .
37.5.6. Main-Program Parameters . . . . . . . . . . . . . . . . . . . . . . .
37.6. Assisted Linkage (*) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37.7. Lowest Level Subroutines . . . . . . . . . . . . . . . . . . . . . . . . . .
37.8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37.8.1. Standard Linkage Conventions . . . . . . . . . . . . . . . . . . . .
38. Large Programs, Control Sections, and Linking . . . . . . . . . . . . . . . . .
38.1. Uniform Addressability for Large Programs
. . . . . . . . . . . . . . .
38.1.1. Other Techniques (*)
. . . . . . . . . . . . . . . . . . . . . . . . .
38.2. Simplifying Addressability Problems in Large Programs
. . . . . . . .
38.2.1. Internal Subroutines Without Local Addressability
. . . . . . . .
38.2.2. Internal Subroutines With Local Addressability
. . . . . . . . . .
38.2.3. Minimizing the Number of Base Registers
. . . . . . . . . . . . .
38.2.4. Relative Branches, Immediate Operands, and Long Displacements
38.2.5. Separating Instructions and Data . . . . . . . . . . . . . . . . . . .
38.3. Separate Assemblies . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

xii

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

Version 1.00

38.4. Control Sections . . . . . . . . . . . . . . . . . . . . . . . . .

38.4.1. Resuming Control Sections . . . . . . . . . . . . . . . .
38.4.2. Literals in Multi-Section Assemblies (*) . . . . . . . . .
38.4.3. Location Counter Discontinuities (*)
. . . . . . . . . .
38.4.4. Section Alignment (*) . . . . . . . . . . . . . . . . . . .
38.4.5. Threaded Location Counters (*) . . . . . . . . . . . . .
38.4.6. The Location Counter Instruction LOCTR (*) . . .
38.5. External Symbols . . . . . . . . . . . . . . . . . . . . . . . . .
38.5.1. EXTRN and WXTRN Statements
. . . . . . . . . . .
38.5.2. V-Type Address Constants . . . . . . . . . . . . . . . .
38.5.3 E N T R Y Statement . . . . . . . . . . . . . . . . . . . . .
38.5.4. The External Symbol Dictionary Listing
. . . . . . . .
38.5.5. External Symbol Addressing and Residence Modes . .
38.6. Object Modules . . . . . . . . . . . . . . . . . . . . . . . . . .
38.6.1. Relocation Dictionary and External Symbol Dictionary
38.7. Program Linking: Combining Object Modules . . . . . . . .
38.7.1. Assigning COMMON Sections . . . . . . . . . . . . . .
38.7.2. Relocating Address Constants
. . . . . . . . . . . . . .
38.7.3. External Dummy Sections (*) . . . . . . . . . . . . . . .
38.7.4. Loading Object Modules (*)
. . . . . . . . . . . . . . .
38.8. Load Modules and Program Objects
. . . . . . . . . . . . .
38.8.1. External Subroutines and Assisted Linkage: Overlay (*)
38.8.2. Program Objects (*) . . . . . . . . . . . . . . . . . . . .
38.8.3. The Class Attribute Instruction CATTR . . . . . . .
38.8.4. Programming for Program Objects . . . . . . . . . . . .
38.8.5. Comparing Load Modules and Program Objects . . . .
38.9. Loading Saved Modules into Storage . . . . . . . . . . . . .
38.9.1. Loading Load Modules . . . . . . . . . . . . . . . . . .
38.9.2. Loading Program Objects . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
38.10. Changing Addressing Modes
38.10.1. The BASSM Instruction . . . . . . . . . . . . . . . . .
38.10.2. The BSM Instruction . . . . . . . . . . . . . . . . . . .
38.10.3. Branch and Return With Addressing Mode Change .
38.11. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

Chapter XI: Dummy Sections, Enhanced USINGs, and Data Structures

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

788
792
794
794
795
795
796
804
805
806
807
810
813
817
818
819
822
822
823
827
831
833
834
837
840
840
841
841
842
844
845
846
847
851

. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

855
856
856
859
860
861
866
866
867
867
869
870
870
873
874
874
875
876
876
877
877
880
881
882
886
887
887

Contents

xiii

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

39. Dummy Control Sections and Enhanced USING Statements . . . . . . .

39.1. Dummy Control Sections . . . . . . . . . . . . . . . . . . . . . . . .
39.2. Multiple Data Structures
. . . . . . . . . . . . . . . . . . . . . . . .
39.3. Shortcomings of Ordinary USING Statements . . . . . . . . . . . .
39.3.1. Ordinary USINGs . . . . . . . . . . . . . . . . . . . . . . . . .
39.4. Labeled USING Statements and Qualified Symbols . . . . . . . . .
39.4.1. Qualified Symbols . . . . . . . . . . . . . . . . . . . . . . . . .
39.4.2. Dropping a Labeled USING Statement . . . . . . . . . . . . .
39.4.3. Labeled USING Statement Summary . . . . . . . . . . . . . .
39.5. Dependent USING Statements . . . . . . . . . . . . . . . . . . . . .
39.5.1. Definition of Dependent USING Statements . . . . . . . . . .
39.5.2. Examples of Dependent USING Statements . . . . . . . . . .
39.5.3. Mapping a CSECT as a DSECT . . . . . . . . . . . . . . . . .
39.5.4. Dropping Dependent USINGs . . . . . . . . . . . . . . . . . .
39.5.5. Dependent USING Statement Summary . . . . . . . . . . . .
39.6. Labeled Dependent USING Statements . . . . . . . . . . . . . . . .
39.6.1. Nesting Structures Addressed with Ordinary USINGs . . . . .
39.6.2. Nesting Structures Addressed with Labeled USINGs
. . . . .
39.6.3. Nested Structures Addressed with Labeled Dependent USINGs
39.6.4. Multiple Nesting of Identical Structures . . . . . . . . . . . . .
39.6.5. Mapping an Array of Identical Data Structures . . . . . . . . .
39.6.6. Two MVS Data Control Blocks (DCBs) in a Program . . . .
39.7. Example of a Large Personnel-File Record (*)
. . . . . . . . . .
39.7.1. Personnel-File Record Example: Comparing Birth Dates . . .
39.7.2. Personnel-File Record Example: Comparing Different Dates .
39.7.3. Personnel-File Record Example: Copying Addresses
. . . . .

.
.
.
.
.
.
.

39.8. Summary . . . . . . . . . . . . . . . . .
39.8.1. USING Statement Summary . . .
39.8.2. DROP Statement Summary . . . .
40. Basic Data Structures . . . . . . . . . . . . . .
40.1. One-Dimensional Arrays
. . . . . . . .
40.2. Two-Dimensional Arrays . . . . . . . .
40.3. General Array Subscripts . . . . . . . .
40.3.1. Multi-Dimensional Arrays (*) . . .
40.3.2. Non-Homogeneous Arrays (Tables)
40.4. Address Tables . . . . . . . . . . . . . .
40.5. Searching an Ordered Array . . . . . . .
40.6. Stacks . . . . . . . . . . . . . . . . . . .
40.6.1. An Example Using a Stack . . . .
40.6.2. An Example Implementing a Stack
40.7. Lists . . . . . . . . . . . . . . . . . . . .
40.7.1. List Insertion . . . . . . . . . . . .
40.7.3. List Deletion
. . . . . . . . . . . .
40.7.4. Free Storage Lists
. . . . . . . . .
40.8. Queues . . . . . . . . . . . . . . . . . . .
40.9. Trees . . . . . . . . . . . . . . . . . . . .
40.10. Hash Tables . . . . . . . . . . . . . . .
40.11. Summary . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

889
889
890
893
894
896
899
899
900
903
905
908
908
909
913
913
914
915
919
922
927
930

.
. . .
. . .
. .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

935
936
936
937
938
942
943
947
957
961
966
968
968
972
977
979

.
.
.
.
.
.
.
.
.
. .
. .

.
.
.
.
.
.
.
.
.
.
.

981
981
982
983
986
987
989
997
998
999
1000

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

1001
1001
1002
1002
1003
1003
1005
1006
1006
1006

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

Chapter XII: System Services, Reenterability, and Recursion

41. Using System Services
. . . . . . . . . . . . . . . . . . .
41.1. Invoking System Services . . . . . . . . . . . . . .
41.2. Invoking System Services with Macro Instructions
41.3. Macro Formats: Standard, List, and Execute . . .
41.4. Causing Abnormal Termination . . . . . . . . . .
41.5. Storage Management . . . . . . . . . . . . . . . . .
41.6. Basic Input and Output . . . . . . . . . . . . . . .
41.7. Handling Program Interruptions . . . . . . . . . .
41.8. Abnormal Terminations of Any Kind . . . . . . .
41.9. Summary . . . . . . . . . . . . . . . . . . . . . . .
42. Reenterability and Recursion
. . . . . . . . . . . . . . .
42.1. Reenterability . . . . . . . . . . . . . . . . . . . . .
42.2. Recursion . . . . . . . . . . . . . . . . . . . . . . .
42.3. Summary . . . . . . . . . . . . . . . . . . . . . . .
43. Reserved for Future Expansion . . . . . . . . . . . . . .

Appendix A: Conversion and Reference Tables

. . . . . . . . . . . . .
.
.
.
.
.
.
.

Hexadecimal Digits in Decimal and Binary . . . . . . . . . . . . . . .

Hexadecimal Addition and Multiplication Tables
. . . . . . . . . . .
Powers of 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Multiples of Powers of Sixteen . . . . . . . . . . . . . . . . . . . . . .
Powers of 10 in Hexadecimal . . . . . . . . . . . . . . . . . . . . . . .
Hexadecimal and Decimal Integers . . . . . . . . . . . . . . . . . . . .
Conversion Tables for Hexadecimal Fractions . . . . . . . . . . . . .
EBCDIC Character Representation in Assembler Language Programs
ASCII Character Representation in Assembler Language Programs .
DC Statement Types . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Appendix B: Simple I/O Macros

. . . . . .
.
.
.
.
.
.
.

Macro Facilities . . . . . . . . . . . . . . .
The READCARD Macro-Instruction
The PRINTLIN Macro-Instruction .
The CONVERTO Macro-Instruction
The CONVERTI Macro-Instruction
The PRINTOUT Macro-Instruction
The DUMPOUT Macro-Instruction
PRINTOUT and DUMPOUT Header
Usage Notes . . . . . . . . . . . . . . .

xiv

Assembler Language Programming for IBM z System Servers

.
.
.
.
.
.
.
.
.
. .

.
.
.
.
.
.
.
.
.
.

Version 1.00

.
.
.
.
.
.
.
.
.
.

Sample Program . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Macro Instruction Definitions . . . . . . . . . . . . . . . . . .
Operating System Environment and Installation Considerations
READCARD Macro
. . . . . . . . . . . . . . . . . . . . . . .
PRINTLIN Macro . . . . . . . . . . . . . . . . . . . . . . . . .
CONVERTO Macro
. . . . . . . . . . . . . . . . . . . . . . .
CONVERTI Macro . . . . . . . . . . . . . . . . . . . . . . . .
D U M P O U T Macro . . . . . . . . . . . . . . . . . . . . . . . .
P R I N T O U T Macro . . . . . . . . . . . . . . . . . . . . . . . .
$$GENIO Macro . . . . . . . . . . . . . . . . . . . . . . . . . .

Glossary of Terms and Abbreviations

Bibliography

Notices

.
.
.
.
.
.
.
.
.
.

. . . . . . . . . . . . . . . . . . . .
. . . .
. . . .
. . .
. . . .

.
.
.
.
.

.
.
.
.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Trademarks
Section
Section
Section
Section
Section
Section
Section
Section
Section
Section
Section
Section
Section
Section
Section
Section
Section
Section
Section
Section
Section
Section
Section
Section
Section
Section
Section
Section
Section
Section
Section
Section
Section
Section
Section
Section

1 Solutions
2 Solutions
3 Solutions
4 Solutions
5 Solutions
6 Solutions
7 Solutions
8 Solutions
9 Solutions
10 Solutions
11 Solutions
12 Solutions
13 Solutions
14 Solutions
15 Solutions
16 Solutions
17 Solutions
18 Solutions
19 Solutions
20 Solutions
21 Solutions
22 Solutions
23 Solutions
24 Solutions
27 Solutions
28 Solutions
29 Solutions
30 Solutions
31 Solutions
32 Solutions
33 Solutions
34 Solutions
35 Solutions
36 Solutions
37 Solutions
38 Solutions

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

1041
1041
1042
1042
1042
1043

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Example of numbering and notation

. . . . . . . . . . . . . . . . . . . . . .
One stage of a binary adder . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Circular representation of twos complement representation . . . . . . . .
Conceptual structure of a typical computer . . . . . . . . . . . . . . . . . . .
Conceptual structure of z System . . . . . . . . . . . . . . . . . . . . . . . .
A byte containing 8 binary digits
. . . . . . . . . . . . . . . . . . . . . . . .
A portion of memory, with addresses shown above each byte . . . . . . . .
A portion of memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A single 64-bit general register . . . . . . . . . . . . . . . . . . . . . . . . . .
All sixteen general registers . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Four Floating-Point Registers . . . . . . . . . . . . . . . . . . . . . . . . . .
Sketch of a Program Status Word . . . . . . . . . . . . . . . . . . . . . . . .
Basic instruction cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Instruction formats and data interactions . . . . . . . . . . . . . . . . . . . .
Opcode bit patterns for typical instruction types . . . . . . . . . . . . . . . .
Instruction cycle with interruptions . . . . . . . . . . . . . . . . . . . . . . .
Typical instruction format for old computers
. . . . . . . . . . . . . . . . .
Structure of an addressing halfword . . . . . . . . . . . . . . . . . . . . . . .
Sketch of Effective Address calculation . . . . . . . . . . . . . . . . . . . . .
RX-type instruction, showing index register specification digit . . . . . . . .
Sketch of Effective Address calculation with indexing . . . . . . . . . . . . .
31-bit Virtual Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simple view of Assembler processing . . . . . . . . . . . . . . . . . . . . . .
Simple view of program linking . . . . . . . . . . . . . . . . . . . . . . . . .
Simple view of program loading and execution
. . . . . . . . . . . . . . . .
Assembler Language statement columns . . . . . . . . . . . . . . . . . . . .
Comment statement examples . . . . . . . . . . . . . . . . . . . . . . . . . .
Block comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Statement fields for machine, Assembler, and macro-instruction statements
A machine instruction statement . . . . . . . . . . . . . . . . . . . . . . . . .
An assembler instruction statement . . . . . . . . . . . . . . . . . . . . . . .
The macro-instruction statement RETURN . . . . . . . . . . . . . . . . . .
A complete Assembler Language program . . . . . . . . . . . . . . . . . . .
RX Instruction with explicit operands
. . . . . . . . . . . . . . . . . . . . .
A simple program segment . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simple program segment with assembled contents . . . . . . . . . . . . . . .
Same program segment, at different memory addresses . . . . . . . . . . . .
Same program segment, with assembled contents . . . . . . . . . . . . . . .
Program segment with pre-calculated explicit base and displacements
. . .
Program segment with explicit base and Assembler-calculated displacements
Program Segment with USING Instruction
. . . . . . . . . . . . . . . . . .
Sample program segment with erroneous statement . . . . . . . . . . . . . .
Sketch of pass one of an assembly . . . . . . . . . . . . . . . . . . . . . . . .
Sketch of pass two of an assembly . . . . . . . . . . . . . . . . . . . . . . . .
USING Table with one entry
. . . . . . . . . . . . . . . . . . . . . . . . . .
Program segment with second USING statement . . . . . . . . . . . . . . .
USING Table with multiple entries . . . . . . . . . . . . . . . . . . . . . . .
Assembled contents when two USINGs are active
. . . . . . . . . . . . . .
USING Table after DROP statement . . . . . . . . . . . . . . . . . . . . . .

Assembler Language Programming for IBM z System Servers

Version 1.00

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

14
37
38
44
45
45
45
46
47
48
49
49
52
54
55
58
63
64
64
66
66
70
74
75
76
77
78
78
79
80
80
80
83
111
119
120
120
120
121
121
122
124
126
127
128
129
129
130
131

50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.

USING Table after second DROP statement . . . . . . . . . . . . . . . . . . .

Implied and explicit length specifications . . . . . . . . . . . . . . . . . . . . . .
Multiple constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F-type constant with decimal exponent . . . . . . . . . . . . . . . . . . . . . . .
Character, hexadecimal, and binary constants . . . . . . . . . . . . . . . . . . .
Length attribute reference to two constants, one a literal . . . . . . . . . . . . .
Describing fields of a (U.S.) telephone number
. . . . . . . . . . . . . . . . . .
Describing fields of an Assembler Language statement . . . . . . . . . . . . . .
Define a group of words
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Describing fields of an Assembler Language statement using ORG instructions
Describing an Assembler symbol cross-reference listing line . . . . . . . . . . .
32-bit portion of a 64-bit general register . . . . . . . . . . . . . . . . . . . . . .
Sign extension by LH instruction . . . . . . . . . . . . . . . . . . . . . . . . . .
Loss of significant digits using STH/LH
. . . . . . . . . . . . . . . . . . . . . .
Loss of significant digits using STH/LH
. . . . . . . . . . . . . . . . . . . . . .
Action of IC and STC instructions . . . . . . . . . . . . . . . . . . . . . . . . .
Interchanging two bytes with IC and STC . . . . . . . . . . . . . . . . . . . . .
Inserting a small number into a register . . . . . . . . . . . . . . . . . . . . . . .
Examples of some RR-type instructions . . . . . . . . . . . . . . . . . . . . . .
Sign extension by LHR instruction . . . . . . . . . . . . . . . . . . . . . . . . .
64-bit general register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sign extension by LGH instruction . . . . . . . . . . . . . . . . . . . . . . . . .
Examples of some RR-type instructions for 64-bit operands . . . . . . . . . . .
Sign extension for instructions with mixed 32- and 64-bit signed operands . . .
Sign extension by Load Byte instructions . . . . . . . . . . . . . . . . . . . . . .
Zero extension by Load Logical Character instructions . . . . . . . . . . . . . .
Operation of Load Logical Halfword instructions . . . . . . . . . . . . . . . . .
Operation of Load Logical word instructions
. . . . . . . . . . . . . . . . . . .
Operation of Load Logical Thirty One Bits instructions . . . . . . . . . . . . .
Examples of conditional branch instructions . . . . . . . . . . . . . . . . . . . .
CNOP alignments and operands . . . . . . . . . . . . . . . . . . . . . . . . . . .
Calculate a sum with an intermediate test
. . . . . . . . . . . . . . . . . . . . .
Calculate the sum of the first N odd integers . . . . . . . . . . . . . . . . . . . .
Example of arithmetic addition and subtraction . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
Testing the result of arithmetic instructions
Calculate a 64-bit sum with an intermediate test . . . . . . . . . . . . . . . . . .
Adding two 64-bit numbers
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Examples of arithmetic comparisons
. . . . . . . . . . . . . . . . . . . . . . . .
Calculate the sum of N odd integers . . . . . . . . . . . . . . . . . . . . . . . . .
Adding two 64-bit numbers logically . . . . . . . . . . . . . . . . . . . . . . . .
Double-length complementation . . . . . . . . . . . . . . . . . . . . . . . . . . .
Double-length complementation, a simpler way . . . . . . . . . . . . . . . . . .
Double-length addition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Double-length subtraction
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example of logical addition and subtraction . . . . . . . . . . . . . . . . . . . .
Double-length addition with carry . . . . . . . . . . . . . . . . . . . . . . . . . .
Double-length subtraction with borrow . . . . . . . . . . . . . . . . . . . . . . .
Sign extension for instructions with mixed 32- and 64-bit signed operands . . .
Calculate a 64-bit sum with an intermediate test . . . . . . . . . . . . . . . . . .
Calculate a 64-bit sum with an intermediate test . . . . . . . . . . . . . . . . . .
Sign extension for instructions with mixed 32- and 64-bit unsigned operands .
Examples of logical comparisons . . . . . . . . . . . . . . . . . . . . . . . . . . .
Comparing logically ordered values . . . . . . . . . . . . . . . . . . . . . . . . .
Bit positions used by IPM and SPM instructions (System/360 PSW sketch)
.
Register contents before shifting . . . . . . . . . . . . . . . . . . . . . . . . . . .
Logical unit shift left
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Logical unit shift right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Arithmetic unit shift right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Arithmetic unit shift left . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Rounding an integer to the next higher multiple of 8 . . . . . . . . . . . . . . .
A 6-byte data entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Storage definitions for a 6-byte data entry
. . . . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

Figures

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

132
142
144
148
152
157
162
163
163
169
173
180
185
185
185
187
187
187
190
191
192
194
195
197
198
199
199
199
200
207
211
219
220
220
220
222
223
224
224
226
227
227
227
228
228
230
230
231
231
231
232
233
234
235
243
244
244
244
244
246
246
246

xvii

112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
138.
139.
140.
141.
142.
143.
144.
145.
146.
147.
148.
149.
150.
151.
152.
153.
154.
155.
156.
157.
158.
159.
160.
161.
162.
163.
164.
165.
166.
167.
168.
169.
170.
171.
172.
173.

xviii

Using shift instructions for a 6-byte data item . . . . . . . . . . . . . . . . . . . . . . . 246

Shifting to make the low-order bit one (1) . . . . . . . . . . . . . . . . . . . . . . . . . 249
Shifting to make the low-order bit one (2) . . . . . . . . . . . . . . . . . . . . . . . . . 249
Four integers packed in a 32-bit word . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Extracting one packed integer from a 32-bit word . . . . . . . . . . . . . . . . . . . . . 249
Unpacking four unsigned integers using right shifts . . . . . . . . . . . . . . . . . . . . 250
Unpacking four unsigned integers using left shifts . . . . . . . . . . . . . . . . . . . . . 250
Unpacking four signed integers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Logical rotate unit shift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Packing four unsigned bit-length constants in a 32-bit word . . . . . . . . . . . . . . . 260
Packing four signed bit-length constants in a 32-bit word
. . . . . . . . . . . . . . . . 260
General layout of multiplication operands . . . . . . . . . . . . . . . . . . . . . . . . . 265
Double-length product of multiply operations . . . . . . . . . . . . . . . . . . . . . . . 266
Calculate the sum of the first 10 cubed integers . . . . . . . . . . . . . . . . . . . . . . 267
Illustration of binary multiplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
General result of divide operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Operands of double-length division . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Example of division by 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
Example of rounded integer division
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
Example of rounded integer division with signed dividend . . . . . . . . . . . . . . . . 277
Ensuring a valid arithmetic division . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Causing a fixed-point divide interruption . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Operands of single-length division before division . . . . . . . . . . . . . . . . . . . . . 278
Operands of single-length division after division . . . . . . . . . . . . . . . . . . . . . . 278
Example of logical division . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Illustration of binary division . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Logical operations AND, OR, and XOR . . . . . . . . . . . . . . . . . . . . . . . . . . 289
Examples of logical operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Inserting a new integer value using AND and OR . . . . . . . . . . . . . . . . . . . . . 291
Data masking using Exclusive OR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Rounding to the next multiple of 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Rounding to the next multiple of 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Complementing a double-length integer
. . . . . . . . . . . . . . . . . . . . . . . . . . 294
Effective Address generation for long-displacement instructions . . . . . . . . . . . . . 303
Addressability range with 12-bit displacements . . . . . . . . . . . . . . . . . . . . . . . 304
Addressability range with 20-bit displacements . . . . . . . . . . . . . . . . . . . . . . . 304
Effective Address formation for relative-immediate instructions . . . . . . . . . . . . . 305
Areas of memory addressed by three AMODEs . . . . . . . . . . . . . . . . . . . . . . 308
z System PSW showing addressing-mode bits . . . . . . . . . . . . . . . . . . . . . . . 308
. . . . . . . . . . . . . . . . . . . 310
Loading integer constants with the LAY instruction
Counting number of shifts to make rightmost bit a 1-bit . . . . . . . . . . . . . . . . . 311
Using LA to set a branch address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
64bit Virtual Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
64-bit Virtual Address with Region Indexes . . . . . . . . . . . . . . . . . . . . . . . . 314
Instruction classes, including RI, RIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Four halfwords in a 64-bit general register . . . . . . . . . . . . . . . . . . . . . . . . . 318
Operation of six Insert Immediate instructions . . . . . . . . . . . . . . . . . . . . . . . 319
Operation of LHI instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
Operation of LGHI instruction
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
Examples of load-immediate instructions . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Operation of six logical load instructions . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Extracting an unsigned integer value using AND Immediate . . . . . . . . . . . . . . . 324
Inserting a new integer value using AND Immediate . . . . . . . . . . . . . . . . . . . 324
Data masking using immediate operands . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Data masking using a symbolically defined immediate operand . . . . . . . . . . . . . 325
A simple loop to scan and replace characters . . . . . . . . . . . . . . . . . . . . . . . . 333
A simple loop, using indexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Indexing into a branch table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
A backward loop to scan and replace characters . . . . . . . . . . . . . . . . . . . . . . 336
Calculate the sum of the first N odd integers . . . . . . . . . . . . . . . . . . . . . . . . 336
Store the cubes of the first 10 integers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
Sketch of a Do-Until loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340

Assembler Language Programming for IBM z System Servers

Version 1.00

174.
175.
176.
177.
178.
179.
180.
181.
182.
183.
184.
185.
186.
187.
188.
189.
190.
191.
192.
193.
194.
195.
196.
197.
198.
199.
200.
201.
202.
203.
204.
205.
206.
207.
208.
209.
210.
211.
212.
213.
214.
215.
216.
217.
218.
219.
220.
221.
222.
223.
224.
225.
226.
227.
228.
229.
230.
231.
232.
233.
234.
235.

Sketch of a Do-While loop . . . . . . . . . . . . . . . . . . . . . . .

Store the cubes of the first 10 integers in a different way . . . . . .
Operation of BXH and BXLE instructions . . . . . . . . . . . . . .
Operation of BXH and BXLE instructions . . . . . . . . . . . . . .
Replacing special characters with blanks, using BXLE . . . . . . .
Creating a table of cubed integers using BXLE
. . . . . . . . . . .
Creating a table of cubed integers using BXLE
. . . . . . . . . . .
Creating a table of cubed integers with addresses as controls . . . .
Creating a table of cubed integers using BXH . . . . . . . . . . . .
Creating a table of cubed integers, using BXH in a special way . .
Examples of the MVI instruction . . . . . . . . . . . . . . . . . . .
Examples of the NI instruction
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
Examples of the OI instruction
Example of the XI instruction . . . . . . . . . . . . . . . . . . . . .
A simpler loop to scan and replace characters . . . . . . . . . . . .
Setting an overflow-indication flag bit . . . . . . . . . . . . . . . . .
Adding alternate list elements twice . . . . . . . . . . . . . . . . . .
Defining bit names safely . . . . . . . . . . . . . . . . . . . . . . . .
Using safely-defined bit names . . . . . . . . . . . . . . . . . . . . .
Converting a binary integer to characters . . . . . . . . . . . . . . .
Adding alternate list elements twice, with program modification . .
Adding alternate list elements twice, without program modification
Assembler Language syntax of basic SS-type instructions
. . . . .
Examples of SS-type instruction operands . . . . . . . . . . . . . .
SS-type instruction using a Length Attribute reference . . . . . . .
Examples of Length Specification Bytes
. . . . . . . . . . . . . . .
Emulated operation of MVC instruction . . . . . . . . . . . . . . .
Example of Move Inverse instruction . . . . . . . . . . . . . . . . .
Emulated operation of MVCIN instruction
. . . . . . . . . . . . .
Example of MVCOS instruction . . . . . . . . . . . . . . . . . . . .
Inserting bits in a word using logical SS-type instructions . . . . .
Emulating the TR instruction . . . . . . . . . . . . . . . . . . . . .
TR instruction to change special characters to blanks . . . . . . . .
Translating hex digits to EBCDIC characters (1) . . . . . . . . . .
Translating hex digits to EBCDIC characters (2) . . . . . . . . . .
Searching for punctuation characters using CLI . . . . . . . . . . .
Searching for punctuation characters using TRT
. . . . . . . . . .
Using TRT to validate numeric characters . . . . . . . . . . . . . .
Using TRT to scan for embedded quotations . . . . . . . . . . . .
Using TRT to scan a string of names and build an occurrence list
Using TRTR to validate numeric characters . . . . . . . . . . . . .
Scanning a string backward using CLI
. . . . . . . . . . . . . . . .
Scanning a string backward using TRTR . . . . . . . . . . . . . . .
Executing a list of instructions . . . . . . . . . . . . . . . . . . . . .
Executing a list of instructions . . . . . . . . . . . . . . . . . . . . .
Constructing an executed instruction . . . . . . . . . . . . . . . . .
Moving a string of bytes of unknown length . . . . . . . . . . . . .
Register use by CLCL and MVCL . . . . . . . . . . . . . . . . . .
Execution of the MVCL instruction . . . . . . . . . . . . . . . . . .
Using MVCL to set a field to blanks . . . . . . . . . . . . . . . . .
Moving a message with padding and length checking . . . . . . . .
Execution of the CLCL instruction . . . . . . . . . . . . . . . . . .
Using CLCL to test for blanks . . . . . . . . . . . . . . . . . . . . .
Comparing two records without padding . . . . . . . . . . . . . . .
Register use by MVCLE and CLCLE
. . . . . . . . . . . . . . . .
Execution of the MVCLE instruction . . . . . . . . . . . . . . . . .
Using MVCLE to set a field to blanks . . . . . . . . . . . . . . . .
Using MVCLE to initialize an area to zero . . . . . . . . . . . . . .
Execution of the CLCLE instruction . . . . . . . . . . . . . . . . .
Using CLCLE to test for all blanks . . . . . . . . . . . . . . . . . .
Registers bounding the SRST search string . . . . . . . . . . . . . .
Execution of the SRST instruction . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

340
341
343
343
344
345
345
345
347
347
355
356
356
356
357
359
359
362
362
363
364
365
368
370
372
373
374
375
375
376
378
381
381
382
382
386
386
386
387
388
388
389
389
391
391
392
393
405
407
407
407
409
409
410
412
413
413
414
414
415
416
417

Figures

xix

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

236.
237.
238.
239.
240.
241.
242.
243.
244.
245.
246.
247.
248.
249.
250.
251.
252.
253.
254.
255.
256.
257.
258.
259.
260.
261.
262.
263.
264.
265.
266.
267.
268.
269.
270.
271.
272.
273.
274.
275.
276.
277.
278.
279.
280.
281.
282.
283.
284.
285.
286.
287.
288.
289.
290.
291.
292.
293.
294.
295.
296.
297.

Execution of the MVST instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Moving a null-terminated string . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using MVST to isolate comma-separated tokens . . . . . . . . . . . . . . . . . . . .
Execution of the CLST instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Translating characters to upper case with TRE . . . . . . . . . . . . . . . . . . . . .
Examples using the CUSE instruction
. . . . . . . . . . . . . . . . . . . . . . . . . .
Mixed single- and double-byte EBCDIC characters . . . . . . . . . . . . . . . . . . .
Examples of DBCS data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Extended continuation for DBCS data . . . . . . . . . . . . . . . . . . . . . . . . . .
CU-type constant generating Unicode characters
. . . . . . . . . . . . . . . . . . . .
Using MVCLU to initialize an area to Unicode spaces . . . . . . . . . . . . . . . . .
Using CLCLU to test for Unicode spaces . . . . . . . . . . . . . . . . . . . . . . . .
Assembler instruction statement for RRF-type instructions with an optional operand
Using TRTT to translate from DBCS to Unicode
. . . . . . . . . . . . . . . . . . .
Translating a long string with TR and MVC, and with TROO . . . . . . . . . . . .
Bits of a UTF-16 Unicode character
. . . . . . . . . . . . . . . . . . . . . . . . . . .
Bits of a UTF-16 Unicode surrogate pair . . . . . . . . . . . . . . . . . . . . . . . . .
Bits of a UTF-32 Unicode character from a UTF-16 surrogate pair
. . . . . . . . .
Big-Endian storage representation of X 87654321
. . . . . . . . . . . . . . . . . . .
Little-Endian storage representation of X 87654321 . . . . . . . . . . . . . . . . . .
Byte reversal by LRV, LRVR, and STRV instructions . . . . . . . . . . . . . . . . .
Byte reversal by LRVH and STRVH instructions . . . . . . . . . . . . . . . . . . . .
Four integers packed in a Big-Endian 32-bit word . . . . . . . . . . . . . . . . . . . .
The same four integers packed in a Little-Endian 32-bit word . . . . . . . . . . . . .
Zone and numeric digits of a byte . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example of MVN and MVZ instructions . . . . . . . . . . . . . . . . . . . . . . . . .
Zoned decimal sign conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A zoned decimal number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Zoned decimal constants with implied lengths . . . . . . . . . . . . . . . . . . . . . .
Zoned decimal constants with explicit lengths . . . . . . . . . . . . . . . . . . . . . .
Representation of a packed decimal number . . . . . . . . . . . . . . . . . . . . . . .
Packed decimal constants with implied lengths
. . . . . . . . . . . . . . . . . . . . .
Packed decimal constants with explicit lengths . . . . . . . . . . . . . . . . . . . . . .
Format of typical two-length SS-type instructions . . . . . . . . . . . . . . . . . . . .
Examples of assembled PACK and UNPK instructions . . . . . . . . . . . . . . . .
Zoned and packed forms of +12345 . . . . . . . . . . . . . . . . . . . . . . . . . . .
PACK instruction operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Converting from zoned to packed decimal using PACK . . . . . . . . . . . . . . . .
Examples of the PACK instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Digit swap using PACK
Operation of the UNPK instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example of an UNPK instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Examples of UNPK instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Digit swap using UNPK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Packing ASCII characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Packing Unicode characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Unpacking to ASCII and Unicode characters . . . . . . . . . . . . . . . . . . . . . .
Unpacking hex digits (incorrectly) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Unpacking hex digits (correctly) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Converting hex data to printable characters
. . . . . . . . . . . . . . . . . . . . . . .
Syntax of the TP instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Examples of the ZAP instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using ZAP to initialize a table of packed decimal operands . . . . . . . . . . . . . .
Initializing a table of decimal numbers using MVC . . . . . . . . . . . . . . . . . . .
Examples of the AP and SP instructions . . . . . . . . . . . . . . . . . . . . . . . . .
Adding a table of 50 packed decimal numbers . . . . . . . . . . . . . . . . . . . . . .
Adding positive and negative items separately . . . . . . . . . . . . . . . . . . . . . .
Finding the largest item in a table . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example of decimal multiplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using MP to square a table of decimal numbers
. . . . . . . . . . . . . . . . . . . .
Using ZAP to set correct decimal multiplicand length
. . . . . . . . . . . . . . . . .
Using ZAP to set correct decimal multiplicand length
. . . . . . . . . . . . . . . . .

Assembler Language Programming for IBM z System Servers

Version 1.00

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

418
419
419
421
423
425
433
434
437
439
441
442
443
445
445
446
446
446
449
449
449
450
450
451
454
455
456
456
458
458
460
461
461
463
464
465
465
465
466
466
468
468
469
469
472
472
473
475
475
475
490
492
492
492
494
494
496
497
498
498
499
499

298.
299.
300.
301.
302.
303.
304.
305.
306.
307.
308.
309.
310.
311.
312.
313.
314.
315.
316.
317.
318.
319.
320.
321.
322.
323.
324.
325.
326.
327.
328.
329.
330.
331.
332.
333.
334.
335.
336.
337.
338.
339.
340.
341.
342.
343.
344.
345.
346.
347.
348.
349.
350.
351.
352.
353.
354.
355.
356.
357.
358.
359.

Generating 0 using MP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Decimal division using DP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Decimal division using Length Attribute References for operands . . . . . . .
Computing the average of a table of decimal numbers . . . . . . . . . . . . .
Assembler Language format of SRP machine instruction statement
. . . . .
Shifting a decimal operand left 3 places using SRP . . . . . . . . . . . . . . .
Shifting a decimal operand right 2 places using SRP . . . . . . . . . . . . . .
Shifting a decimal operand right 1 place with rounding using SRP . . . . . .
Shifting a decimal operand with an EXecuted SRP . . . . . . . . . . . . . . .
Operation of the MVO instruction
. . . . . . . . . . . . . . . . . . . . . . . .
Two Examples of MVO results . . . . . . . . . . . . . . . . . . . . . . . . . .
Shifting a decimal operand right an odd number of digits
. . . . . . . . . . .
. . . . . . . . . . .
Shifting a decimal operand right an odd number of digits
Shifting a decimal operand left an odd number of digits . . . . . . . . . . . .
Shifting a decimal operand left by one digit
. . . . . . . . . . . . . . . . . . .
Shifting a decimal operand left by three or more digits . . . . . . . . . . . . .
Shifting a decimal operand left an even number of digits . . . . . . . . . . . .
Shifting a decimal operand left an even number of digits . . . . . . . . . . . .
Shifting a decimal operand left an even number of digits . . . . . . . . . . . .
Shifting a decimal operand right an even number of digits . . . . . . . . . . .
Shifting a decimal operand right an even number of digits . . . . . . . . . . .
Ensuring decimal point alignment for packed decimal addition . . . . . . . .
A business calculation in packed decimal, part 1 . . . . . . . . . . . . . . . . .
A business calculation in packed decimal, part 2 . . . . . . . . . . . . . . . . .
A business calculation in packed decimal, part 3 . . . . . . . . . . . . . . . . .
A business calculation in packed decimal, part 4 . . . . . . . . . . . . . . . . .
Integer and Scale Attributes
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using Scale Attributes in a SRP instruction . . . . . . . . . . . . . . . . . . .
Converting a 64-bit binary integer to packed decimal . . . . . . . . . . . . . .
Using CVD to format page numbers . . . . . . . . . . . . . . . . . . . . . . .
Converting decimal characters to binary
. . . . . . . . . . . . . . . . . . . . .
Sketch of an editing operation . . . . . . . . . . . . . . . . . . . . . . . . . . .
Representation of an editing pattern . . . . . . . . . . . . . . . . . . . . . . . .
Convert a packed decimal integer to characters using UNPK . . . . . . . . .
. . . . . . . . . . .
Convert a packed decimal integer to characters using ED
Converting a 32-bit binary integer to characters . . . . . . . . . . . . . . . . .
Editing a binary integer with separating commas
. . . . . . . . . . . . . . . .
Editing a signed number
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using field protection with ED . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
Edited result with a floating currency symbol
Edited result with a properly placed floating currency symbol . . . . . . . . .
Integer value with optional sign and separating commas . . . . . . . . . . . .
Editing multiple values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Logical-operation description of the editing process . . . . . . . . . . . . . . .
ED and EDMK operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A data item containing an integer value . . . . . . . . . . . . . . . . . . . . . .
A packed decimal field containing integer and fraction parts . . . . . . . . . .
A binary word containing integer and fraction parts . . . . . . . . . . . . . . .
Calculating a tax amount in scaled fixed decimal arithmetic . . . . . . . . . .
Calculating a tax amount in scaled fixed binary arithmetic . . . . . . . . . . .
Two binary constants scaled by 2**28
. . . . . . . . . . . . . . . . . . . . . .
Defining a scaled binary constant 10**12 . . . . . . . . . . . . . . . . . . . . .
Multiplying two scaled binary numbers . . . . . . . . . . . . . . . . . . . . . .
Examples of data with widely ranging values . . . . . . . . . . . . . . . . . . .
A typical floating-point representation
. . . . . . . . . . . . . . . . . . . . . .
An example of a floating-point representation using 4 decimal digits . . . . .
Another example of a floating-point representation using 4 decimal digits . .
A floating-point representation showing normalized and unnormalized values
Floating-point numbers with signed exponent . . . . . . . . . . . . . . . . . .
Examples of approximate floating-point representations . . . . . . . . . . . .
Three floating-point data lengths . . . . . . . . . . . . . . . . . . . . . . . . . .
Four floating-point registers
. . . . . . . . . . . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

499
500
501
501
503
504
504
504
504
507
508
509
509
510
510
510
511
511
511
511
512
514
518
518
519
519
520
520
523
523
525
526
527
528
528
530
531
532
532
533
533
534
535
536
537
540
540
541
543
544
545
545
546
547
548
549
549
549
550
550
551
552

Figures

xxi

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

360.
361.
362.
363.
364.
365.
366.
367.
368.
369.
370.
371.
372.
373.
374.
375.
376.
377.
378.
379.
380.
381.
382.
383.
384.
385.
386.
387.
388.
389.
390.
391.
392.
393.
394.
395.
396.
397.
398.
399.
400.
401.
402.
403.
404.
405.
406.
407.
408.
409.
410.
411.
412.
413.
414.
415.
416.
417.
418.
419.
420.
421.

xxii

All sixteen floating-point registers, showing register pairings . . . . . . . .

Integer-based representation of 73 in FPI(10,4) . . . . . . . . . . . . . . .
Illustrating floating-point division corrective right shift . . . . . . . . . . .
Exponent range of representable and computable values . . . . . . . . . .
Hexadecimal floating-point number representations . . . . . . . . . . . . .
Quadword aligned constants and data . . . . . . . . . . . . . . . . . . . . .
Hexadecimal floating-point constants with rounding suffixes . . . . . . . .
. . . . . . . . . . . .
Examples of hexadecimal floating-point instructions
Example of LTXR instruction . . . . . . . . . . . . . . . . . . . . . . . . .
Examples of extended-precision hexadecimal RR instructions . . . . . . .
Short hexadecimal floating-point multiplication . . . . . . . . . . . . . . .
Floating-point registers used for hexadecimal floating-point multiplication
. . . . .
Calculating a table of short hexadecimal floating-point products
Calculating a table of long hexadecimal floating-point products . . . . . .
Floating-point registers used for hexadecimal floating-point multiplication
Example of hexadecimal floating-point divide instructions . . . . . . . . .
Example of hexadecimal floating-point divide instructions . . . . . . . . .
Example of a hexadecimal floating-point halve instruction . . . . . . . . .
Hexadecimal halve instruction causing underflow . . . . . . . . . . . . . .
Example of hexadecimal floating-point addition . . . . . . . . . . . . . . .
Evaluating a hexadecimal floating-point expression . . . . . . . . . . . . .
Evaluating a hexadecimal floating-point inner product . . . . . . . . . . .
Evaluating a polynomial with hexadecimal floating-point arithmetic . . .
Evaluating a quadratic polynomial . . . . . . . . . . . . . . . . . . . . . . .
Converting a binary integer to hexadecimal floating-point . . . . . . . . .
Converting a hexadecimal floating-point number to a binary integer . . .
Rounding a long hexadecimal floating-point number to short . . . . . . .
Rounded inner product of long HFP numbers . . . . . . . . . . . . . . . .
Manually rounding long to short (1)
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
Manually rounding long to short (2)
Manually rounding long to short (3)
. . . . . . . . . . . . . . . . . . . . .
Converting a 32-bit integer to short hexadecimal floating-point . . . . . .
Converting a 64-bit integer to three hexadecimal floating-point values . .
Early conversion of integer to hexadecimal floating-point
. . . . . . . . .
Format of machine instruction statement for converting HFP to binary .
Calculating a HFP remainder
. . . . . . . . . . . . . . . . . . . . . . . . .
Evaluating a hexadecimal floating-point remainder . . . . . . . . . . . . .
Examples of HFP square root instructions . . . . . . . . . . . . . . . . . .
Three binary floating-point data representations . . . . . . . . . . . . . . .
Range of the binary floating-point representation . . . . . . . . . . . . . .
A view of the binary floating-point representation . . . . . . . . . . . . . .
Examples of short binary floating-point constants . . . . . . . . . . . . . .
Examples of long and extended binary floating-point constants . . . . . .
Rounding indicators for binary floating-point constants
. . . . . . . . . .
Examples of parameterized binary floating-point NaNs . . . . . . . . . . .
Binary floating-point constants with decimal exponents and modifiers . .
Values representable with gradual underflow . . . . . . . . . . . . . . . . .
Floating-Point Control (FPC) register
. . . . . . . . . . . . . . . . . . . .
Examples of binary floating-point data movement instructions . . . . . .
Example of binary floating-point multiply instructions . . . . . . . . . . .
Examples of binary floating-point multiplication overflow and underflow
Examples of binary floating-point multiply instructions
. . . . . . . . . .
Example of binary floating-point denormalized product
. . . . . . . . . .
Example of binary floating-point extended-precision operands . . . . . . .
Examples of binary floating-point division . . . . . . . . . . . . . . . . . .
Examples of binary floating-point division overflow and underflow . . . .
Examples of binary floating-point addition and subtraction . . . . . . . .
Examples of binary floating-point comparison . . . . . . . . . . . . . . . .
Examples of binary floating-point compare and signal instructions . . . .
Examples of binary floating-point rounding instructions . . . . . . . . . .
Examples of BFP load lengthened instructions
. . . . . . . . . . . . . . .
Examples of BFP load lengthened instructions with NaNs . . . . . . . . .

Assembler Language Programming for IBM z System Servers

Version 1.00

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

553
564
565
570
574
581
582
585
585
585
586
587
587
587
588
591
591
592
592
593
594
595
595
595
596
596
604
604
604
605
605
607
607
607
608
612
612
614
626
628
629
629
630
630
631
632
634
636
643
644
645
645
645
645
646
647
648
650
650
651
652
652

422.
423.
424.
425.
426.
427.
428.
429.
430.
431.
432.
433.
434.
435.
436.
437.
438.
439.
440.
441.
442.
443.
444.
445.
446.
447.
448.
449.
450.
451.
452.
453.
454.
455.
456.
457.
458.
459.
460.
461.
462.
463.
464.
465.
466.
467.
468.
469.
470.
471.
472.
473.
474.
475.
476.
477.
478.
479.
480.
481.
482.
483.

Examples of binary integer to binary floating-point instructions . . . . . . . . .

Examples of converting binary floating-point fractions to integers with rounding
Examples of Convert to Fixed instructions . . . . . . . . . . . . . . . . . . . . .
Examples of load FP integer instructions . . . . . . . . . . . . . . . . . . . . . .
Examples of divide to integer instructions
. . . . . . . . . . . . . . . . . . . . .
Example of iterative divide to integer . . . . . . . . . . . . . . . . . . . . . . . .
Iterative execution of a divide to integer instruction . . . . . . . . . . . . . . . .
Examples of binary floating-point square root instructions . . . . . . . . . . . .
Example of binary floating-point multiply and add instructions . . . . . . . . .
Hexadecimal and binary floating-point representations . . . . . . . . . . . . . .
Conceptual decimal floating-point representation . . . . . . . . . . . . . . . . .
Three decimal floating-point representations of the same value . . . . . . . . .
Decimal floating-point data representation . . . . . . . . . . . . . . . . . . . . .
z System decimal floating-point representations . . . . . . . . . . . . . . . . . .
DFP constants with exponent modifiers and decimal exponents . . . . . . . . .
Examples of decimal floating-point Test Data Class instructions . . . . . . . .
Illustration of decimal floating-point rounding candidates
. . . . . . . . . . . .
Illustration of decimal floating-point rounding candidates near zero . . . . . . .
Floating-Point Control (FPC) register
. . . . . . . . . . . . . . . . . . . . . . .
Examples of converting decimal floating-point to fixed binary . . . . . . . . . .
Examples of converting decimal floating-point to binary integer . . . . . . . . .
Converting signed packed decimal to decimal floating-point . . . . . . . . . . .
Converting decimal floating-point to signed packed decimal . . . . . . . . . . .
Converting decimal floating-point to signed packed decimal . . . . . . . . . . .
. . . . . . . . .
Converting unsigned packed decimal to decimal floating-point
Converting decimal floating-point to unsigned packed decimal
. . . . . . . . .
Effect of the mask operand on Convert from Zoned results . . . . . . . . . . .
Examples of converting decimal floating-point to zoned . . . . . . . . . . . . .
DFP arithmetic with short operands
. . . . . . . . . . . . . . . . . . . . . . . .
Floating-Point Control Register showing Decimal Rounding Mode bits . . . .
Example of extracting DFP biased exponent . . . . . . . . . . . . . . . . . . . .
Example of inserting a biased DFP exponent
. . . . . . . . . . . . . . . . . . .
Examples of DFP Extract Significance instructions . . . . . . . . . . . . . . . .
Converting an extended decimal floating-point value to packed decimal . . . .
Calculate price plus tax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Correctly rounding a cost to two decimal digits . . . . . . . . . . . . . . . . . .
Example of a reround instruction . . . . . . . . . . . . . . . . . . . . . . . . . .
Example of rerounding arbitrary amounts
. . . . . . . . . . . . . . . . . . . . .
Examples of assembled DFP constants using rounding for reround . . . . . . .
Example of DFP binary-significand format . . . . . . . . . . . . . . . . . . . . .
Sketch of short binary-significand format . . . . . . . . . . . . . . . . . . . . . .
BCD-to-DPD encodings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DPD-to-BCD translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Degraded precision in adding hexadecimal floating-point pseudo-zeros . . . . .
Trivial example of a subroutine (1) . . . . . . . . . . . . . . . . . . . . . . . . .
Trivial example of a subroutine (2) . . . . . . . . . . . . . . . . . . . . . . . . .
Subroutine linkage using a BAS instruction . . . . . . . . . . . . . . . . . . . .
Subroutine linkage using a BASR instruction . . . . . . . . . . . . . . . . . . .
Subroutine linkage using an address constant
. . . . . . . . . . . . . . . . . . .
Simple shift subroutine (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simple shift subroutine (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simple shift subroutine with named arguments (3) . . . . . . . . . . . . . . . .
Simple shift subroutine (4) using argument addresses . . . . . . . . . . . . . . .
Simple shift subroutine (5) with argument addresses in memory . . . . . . . . .
Subroutine call with inline arguments . . . . . . . . . . . . . . . . . . . . . . . .
Subroutine returning past inline argument . . . . . . . . . . . . . . . . . . . . .
Subroutine call with inline argument addresses . . . . . . . . . . . . . . . . . . .
Subroutine with argument address list . . . . . . . . . . . . . . . . . . . . . . . .
Subroutine saves and restores registers
. . . . . . . . . . . . . . . . . . . . . . .
General argument-passing scheme . . . . . . . . . . . . . . . . . . . . . . . . . .
Subroutine call using an argument address list . . . . . . . . . . . . . . . . . . .
Subroutine called with an argument address list . . . . . . . . . . . . . . . . . .

. .
.
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

Figures

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

653
654
654
656
657
657
658
659
660
668
669
670
673
673
678
680
681
682
685
695
695
696
697
697
698
698
699
700
704
705
705
706
707
708
710
710
711
711
712
716
716
720
721
734
743
743
744
745
745
746
746
746
747
747
747
748
748
749
750
752
752
752

xxiii

484.
485.
486.
487.
488.
489.
490.
491.
492.
493.
494.
495.
496.
497.
498.
499.
500.
501.
502.
503.
504.
505.
506.
507.
508.
509.
510.
511.
512.
513.
514.
515.
516.
517.
518.
519.
520.
521.
522.
523.
524.
525.
526.
527.
528.
529.
530.
531.
532.
533.
534.
535.
536.
537.
538.
539.
540.
541.
542.
543.
544.
545.

xxiv

Constructing an argument address list . . . . . . . . . . . . . . . . . . .

Two variable-length argument lists
. . . . . . . . . . . . . . . . . . . .
Calling a subroutine with a variable-length argument list . . . . . . . .
Subroutine called with a variable-length argument list
. . . . . . . . .
Sketch of a variable-length argument list . . . . . . . . . . . . . . . . .
Sample 64-bit argument list addresses . . . . . . . . . . . . . . . . . . .
Standard save area layout . . . . . . . . . . . . . . . . . . . . . . . . . .
Sample subroutine calling sequence . . . . . . . . . . . . . . . . . . . .
Save area chaining instructions . . . . . . . . . . . . . . . . . . . . . . .
Chained save areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reloading registers and returning to a caller . . . . . . . . . . . . . . .
Format-4 save area layout
. . . . . . . . . . . . . . . . . . . . . . . . .
Example of using a Format-4 save area . . . . . . . . . . . . . . . . . .
Format-5 save area layout
. . . . . . . . . . . . . . . . . . . . . . . . .
Saving registers using a Format-5 save area . . . . . . . . . . . . . . . .
Return from a routine using a Format-5 save area
. . . . . . . . . . .
Example of an entry point identifier . . . . . . . . . . . . . . . . . . . .
Example of two calling point identifiers . . . . . . . . . . . . . . . . . .
Setting a return flag . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Setting a return code in register 15 . . . . . . . . . . . . . . . . . . . . .
Testing a return code returned in register 15 . . . . . . . . . . . . . . .
Using a return code as a branch index
. . . . . . . . . . . . . . . . . .
Using a return code as a branch index with relative branch instructions
Checking for valid return code values . . . . . . . . . . . . . . . . . . .
Setting a reason code in register 0 . . . . . . . . . . . . . . . . . . . . .
Using RETURN macros to set return flags and return codes . . . . .
Returning to an error branch without a return code . . . . . . . . . . .
Call with error branch instructions
. . . . . . . . . . . . . . . . . . . .
Convention for passing main-program parameters . . . . . . . . . . . .
Example of calling with assisted linkage . . . . . . . . . . . . . . . . . .
Example of a routine to implement assisted linkage . . . . . . . . . . .
Assisted linkage routine with counters
. . . . . . . . . . . . . . . . . .
Example of a lowest level subroutine . . . . . . . . . . . . . . . . . . .
Establish three base registers (1) . . . . . . . . . . . . . . . . . . . . . .
Establish three base registers (2) . . . . . . . . . . . . . . . . . . . . . .
Establish three base registers (3) . . . . . . . . . . . . . . . . . . . . . .
Establish three base registers (4) . . . . . . . . . . . . . . . . . . . . . .
Establish three base registers (5) . . . . . . . . . . . . . . . . . . . . . .
Establish three base registers with risks (6) . . . . . . . . . . . . . . . .
Establish three base registers (7) . . . . . . . . . . . . . . . . . . . . . .
Establish three base registers (8) . . . . . . . . . . . . . . . . . . . . . .
Establish three base registers (9) . . . . . . . . . . . . . . . . . . . . . .
Calling a subroutine not needing local addressability . . . . . . . . . .
Calling a subroutine not locally addressable . . . . . . . . . . . . . . .
Subroutine with local addressability . . . . . . . . . . . . . . . . . . . .
Replacing based branch instructions with relative-immediates . . . . .
Replacing a based EXecute instruction with EXRL . . . . . . . . . . .
Replacing references to constants with immediate operands . . . . . .
Replacing short unsigned displacements with long signed displacements
A program fragment needing reorganization . . . . . . . . . . . . . . .
A program fragment after reorganization . . . . . . . . . . . . . . . . .
Reorganizing a program to minimize base registers . . . . . . . . . . .
Incorrect implied reference to a different control section . . . . . . . .
Correct implied reference to a different control section . . . . . . . . .
USING Table with two entries
. . . . . . . . . . . . . . . . . . . . . .
Main program and subroutine in one assembly . . . . . . . . . . . . .
Main program, subroutine, and common section in one assembly
. .
Resuming control sections . . . . . . . . . . . . . . . . . . . . . . . . .
Main program and subroutine in one assembly, multiple CSects . . .
Statements with Location Counter discontinuities . . . . . . . . . . . .
Technique for rounding the length of a CSECT . . . . . . . . . . . . .
Rearrangement of source groups by LOCTR
. . . . . . . . . . . . . .

Assembler Language Programming for IBM z System Servers

Version 1.00

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

753
753
753
753
754
754
757
757
758
758
758
760
760
761
762
762
763
764
764
765
766
766
766
766
767
767
767
768
768
770
770
771
772
777
777
777
778
778
778
779
779
779
784
784
785
785
786
786
786
786
787
787
790
790
790
791
792
792
793
794
795
797

546.
547.
548.
549.
550.
551.
552.
553.
554.
555.
556.
557.
558.
559.
560.
561.
562.
563.
564.
565.
566.
567.
568.
569.
570.
571.
572.
573.
574.
575.
576.
577.
578.
579.
580.
581.
582.
583.
584.
585.
586.
587.
588.
589.
590.
591.
592.
593.
594.
595.
596.
597.
598.
599.
600.
601.
602.
603.
604.
605.
606.
607.

Simple example of LOCTR (1) . . . . . . . . . . . . . . . . . .

Simple example of LOCTR (2) . . . . . . . . . . . . . . . . . .
Simple example of LOCTR (3) . . . . . . . . . . . . . . . . . .
A program fragment using LOCTR for reorganization . . . . .
Organizing a program to minimize addressability problems
. .
Organizing a program to minimize addressability problems
. .
Simple example of LOCTR (4) . . . . . . . . . . . . . . . . . .
Example of unexpected LOCTR behavior (1) . . . . . . . . . .
Example of unexpected LOCTR behavior (2) . . . . . . . . . .
Calling ShftRt as an external routine . . . . . . . . . . . . . . .
ShftRt subroutine as a separate assembly . . . . . . . . . . . . .
External references using relative branch instructions . . . . . .
Using WXTRN to test whether a routine was linked . . . . . .
Calling ShftRt as an external routine . . . . . . . . . . . . . . .
ShftRt subroutine in a different CSect
. . . . . . . . . . . . . .
Main program with ENTRY for data . . . . . . . . . . . . . . .
Subroutine using EXTRN to reference data . . . . . . . . . . .
Subroutine using EXTRN and adcons to reference data . . . .
Subroutine with entries for two similar functions . . . . . . . .
Subroutine with two similar functions and some common code
Sample assembly with external symbols . . . . . . . . . . . . . .
External symbol dictionary from sample assembly
. . . . . . .
Program assembled with different SECTALGN options . . . .
Example of ESD listings with different SECTALGN options .
Assigning RMODE and AMODE to a section name . . . . . .
ESD showing RMODE and AMODE of section names . . . .
Example of two source modules to be linked
. . . . . . . . . .
Sketch of object module from source module 1 . . . . . . . . .
Sketch of object module from source module 2 . . . . . . . . .
Composite ESD after reading first object module . . . . . . . .
Composite ESD after loading second object module . . . . . .
Composite ESD after assigning memory addresses
. . . . . . .
Memory layout of loaded program
. . . . . . . . . . . . . . . .
Sample DXD declarations
. . . . . . . . . . . . . . . . . . . . .
External dummy section declaration . . . . . . . . . . . . . . . .
Referencing external dummy items with Q-cons . . . . . . . . .
External dummy items in ESD listing . . . . . . . . . . . . . . .
Separate DXD declaration . . . . . . . . . . . . . . . . . . . . .
Example of a completed External Dummy Section . . . . . . .
. . . . . . . . . .
Retrieving an External Dummy Section item
PL/I technique for loading Pseudo Registers . . . . . . . . . . .
ESDID Translation Table entry for an incoming symbol . . . .
A typical load-time CESD entry . . . . . . . . . . . . . . . . . .
Composite ESD after assigning load module addresses . . . . .
. . . . . . . . . . . . . . . . . . . . . .
Sketch of a load module
A load module after loading . . . . . . . . . . . . . . . . . . . .
Sketch of program object structure
. . . . . . . . . . . . . . . .
Sample program assembled with the GOFF option . . . . . . .
ESD from program assembled with the GOFF option . . . . .
Assigning AMODE to an entry symbol . . . . . . . . . . . . . .
ESD showing AMODE assigned to entry and external symbols
Sample program defining two Sections and three Classes . . . .
Assignment of instructions and data into elements
. . . . . . .
Assembly listing for sample program . . . . . . . . . . . . . . .
External symbol dictionary for sample program . . . . . . . . .
Example of declaring parts in a GOFF class . . . . . . . . . . .
ESD for parts in a GOFF class
. . . . . . . . . . . . . . . . . .
Sketch of virtual memory . . . . . . . . . . . . . . . . . . . . . .
Sample program defining two Sections and three Classes . . . .
Sketch of classes in virtual memory . . . . . . . . . . . . . . . .
z System PSW showing addressing-mode bits . . . . . . . . . .
Important addressing mode bits for BASSM . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

Figures

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

797
798
798
798
799
799
800
800
801
805
805
806
806
807
808
808
808
809
810
810
811
811
813
813
814
815
820
820
821
821
822
822
823
824
824
824
824
825
825
826
826
828
828
831
832
833
835
835
836
837
837
837
837
838
838
839
839
842
842
843
844
845

xxv

608.
609.
610.
611.
612.
613.
614.
615.
616.
617.
618.
619.
620.
621.
622.
623.
624.
625.
626.
627.
628.
629.
630.
631.
632.
633.
634.
635.
636.
637.
638.
639.
640.
641.
642.
643.
644.
645.
646.
647.
648.
649.
650.
651.
652.
653.
654.
655.
656.
657.
658.
659.
660.
661.
662.
663.
664.
665.
666.
667.
668.
669.

xxvi

BASSM setting of first-operand register for 24-, 31-, and 64-bit addressing modes
Sketch of residence and addressing modes
. . . . . . . . . . . . . . . . . . . . . .
Example showing why LLGT/LLGTR are necessary . . . . . . . . . . . . . . . .
Example of a dummy control section . . . . . . . . . . . . . . . . . . . . . . . . .
Example using a dummy control section . . . . . . . . . . . . . . . . . . . . . . .
USING Table with two entries, one for a dummy section . . . . . . . . . . . . .
Object code from references to a dummy control section . . . . . . . . . . . . . .
Example using a dummy control section . . . . . . . . . . . . . . . . . . . . . . .
A poor method for describing two instances of a record . . . . . . . . . . . . . .
A better record description with a DSECT . . . . . . . . . . . . . . . . . . . . . .
Ordinary USING statement syntax . . . . . . . . . . . . . . . . . . . . . . . . . .
Copying a field from Old record to New . . . . . . . . . . . . . . . . . . . . . . .
Incorrect addressing with ordinary USING . . . . . . . . . . . . . . . . . . . . . .
Correct but awkward addressing with ordinary USING
. . . . . . . . . . . . . .
Manual coding of base and displacement for a large DSECT . . . . . . . . . . .
Labeled USING statement syntax . . . . . . . . . . . . . . . . . . . . . . . . . . .
Qualified symbol syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Examples of qualifier definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Copying a field with Labeled USINGs . . . . . . . . . . . . . . . . . . . . . . . .
DROP statement for Labeled USING . . . . . . . . . . . . . . . . . . . . . . . .
Concurrently active Ordinary and Labeled USINGs
. . . . . . . . . . . . . . . .
Dummy control section for record address . . . . . . . . . . . . . . . . . . . . . .
Improved definition of a record description
. . . . . . . . . . . . . . . . . . . . .
Mapping a substructure with a second DSECT . . . . . . . . . . . . . . . . . . .
Dependent USING statement syntax . . . . . . . . . . . . . . . . . . . . . . . . .
Anchoring an internal DSECT with a Dependent USING . . . . . . . . . . . . .
Outer DSECT with two nested DSECTs . . . . . . . . . . . . . . . . . . . . . . .
Assembler listing of multiple Dependent USINGs and DSECTs . . . . . . . . .
Three independent data structures with one base register . . . . . . . . . . . . . .
Defining DSECTs for three independent data structures . . . . . . . . . . . . . .
Defining a mapping of three independent but contiguous data structures . . . . .
Example of a message-skeleton CSECT
. . . . . . . . . . . . . . . . . . . . . . .
Example of mapping a CSECT as though it is a DSECT . . . . . . . . . . . . .
Labeled Dependent USING statement syntax . . . . . . . . . . . . . . . . . . . .
Nesting two identical structures within a third . . . . . . . . . . . . . . . . . . . .
Addressing two nested DSECTs with Labeled Dependent USINGs
. . . . . . .
Data in nested DSECTs addressed with Labeled Dependent USINGs . . . . . .
Multiply-Nested Data Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Doubly Nested DSECT definitions . . . . . . . . . . . . . . . . . . . . . . . . . .
Addressing doubly nested DSECT definitions . . . . . . . . . . . . . . . . . . . .
Using the Labeled Dependent USINGs to move data
. . . . . . . . . . . . . . .
Addressing two DCBs with ordinary USINGs . . . . . . . . . . . . . . . . . . . .
Addressing instructions and DCBs with one register
. . . . . . . . . . . . . . . .
Define a personnel-file record
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Employee-record Person DSECT . . . . . . . . . . . . . . . . . . . . . . . . . . .
Employee-record Date DSECT . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Employee-record Address DSECT
. . . . . . . . . . . . . . . . . . . . . . . . . .
Employee-record Phone DSECT
. . . . . . . . . . . . . . . . . . . . . . . . . . .
DSECT nesting in an employee record . . . . . . . . . . . . . . . . . . . . . . . .
Anchoring various DSECTs within Employee record . . . . . . . . . . . . . . . .
Manipulating fields within an Employee record . . . . . . . . . . . . . . . . . . .
Addressing DSECTs within Employee record with ordinary USINGs . . . . . .
Comparing dates of birth in Employee record . . . . . . . . . . . . . . . . . . . .
Comparing date fields in different parts of an Employee record . . . . . . . . . .
Copying addresses with an Employee Record . . . . . . . . . . . . . . . . . . . .
Example of a one-dimensional array of halfwords . . . . . . . . . . . . . . . . . .
Sum of array elements with known subscript bounds . . . . . . . . . . . . . . . .
Sum of array elements with unknown subscript bounds . . . . . . . . . . . . . .
Typical arrangement of elements of a matrix . . . . . . . . . . . . . . . . . . . . .
Storing an array in column order
. . . . . . . . . . . . . . . . . . . . . . . . . . .
Storing an array in row order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Retrieving a specified element of an array
. . . . . . . . . . . . . . . . . . . . . .

Assembler Language Programming for IBM z System Servers

Version 1.00

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

845
849
849
857
857
858
858
858
859
860
860
861
862
862
863
866
866
866
867
867
868
869
869
870
870
871
871
872
872
873
873
873
874
875
876
877
877
877
878
879
880
881
881
882
883
883
883
883
885
884
886
886
886
887
888
894
894
895
896
896
896
897

670.
671.
672.
673.
674.
675.
676.
677.
678.
679.
680.
681.
682.
683.
684.
685.
686.
687.
688.
689.
690.
691.
692.
693.
694.
695.
696.
697.
698.
699.
700.
701.
702.
703.
704.
705.
706.
707.
708.
709.
710.
711.
712.
713.
714.
715.
716.
717.
718.
719.
720.
721.
722.
723.
724.
725.
726.
727.
728.
729.
730.
731.

Retrieving a specified element of an array efficiently

. . . . . . . .
Searching for a matching table entry
. . . . . . . . . . . . . . . . .
Searching for a table entry mapped by a DSECT . . . . . . . . . .
USING Table with two entries, one for a DSECT . . . . . . . . .
Creating a table of addresses . . . . . . . . . . . . . . . . . . . . . .
Creating a better table of addresses . . . . . . . . . . . . . . . . . .
Creating a table of addresses at assembly time . . . . . . . . . . . .
Example of a binary search . . . . . . . . . . . . . . . . . . . . . . .
A stack growing toward higher addresses . . . . . . . . . . . . . . .
A stack implemented as an array . . . . . . . . . . . . . . . . . . . .
Pushing a data item onto a stack
. . . . . . . . . . . . . . . . . . .
Adding top two elements of a stack . . . . . . . . . . . . . . . . . .
A stack growing toward lower addresses . . . . . . . . . . . . . . .
Add top two elements of a stack . . . . . . . . . . . . . . . . . . . .
Sketch of a linked list . . . . . . . . . . . . . . . . . . . . . . . . . .
Inserting an element into a linked list . . . . . . . . . . . . . . . . .
Example of inserting an element into a linked list . . . . . . . . . .
DSECT describing a list element . . . . . . . . . . . . . . . . . . . .
Mapping multiple list elements with Labeled USINGs . . . . . . .
Deleting an element from a linked list . . . . . . . . . . . . . . . . .
Example of deleting an element from a linked list . . . . . . . . . .
Example of deleting an element from a linked list . . . . . . . . . .
Defining a free storage list as an array . . . . . . . . . . . . . . . . .
Initializing a free storage list as an array
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
Example of a list anchor
DSECT mapping a list anchor . . . . . . . . . . . . . . . . . . . . .
Defining an anchor for a working list . . . . . . . . . . . . . . . . .
Moving a list element from the FSL to the working list . . . . . .
A two-dimensional array to implement a linked list . . . . . . . . .
. .
Initializing a two-dimensional array implementing a linked list
Structure of a queue element . . . . . . . . . . . . . . . . . . . . . .
A queue with several elements . . . . . . . . . . . . . . . . . . . . .
DSECT structure of a typical queue element . . . . . . . . . . . . .
An element to be inserted into a queue . . . . . . . . . . . . . . . .
A queue after insertion of a new element . . . . . . . . . . . . . . .
Instructions to insert a new queue element . . . . . . . . . . . . . .
Insert a new list element with ordinary USINGs
. . . . . . . . . .
Ordinary-USING Code to Insert a New List Element . . . . . . .
Labeled USING example: inserting a new queue element . . . . .
Node of a binary tree . . . . . . . . . . . . . . . . . . . . . . . . . .
DSECT structure of a typical tree element . . . . . . . . . . . . . .
Three nodes of a binary tree . . . . . . . . . . . . . . . . . . . . . .
A growing binary tree with seven nodes
. . . . . . . . . . . . . . .
Entering a new node in a binary tree . . . . . . . . . . . . . . . . .
Retrieving data from a binary tree . . . . . . . . . . . . . . . . . . .
Example of a binary tree of 7 elements . . . . . . . . . . . . . . . .
Example of searching a hash table . . . . . . . . . . . . . . . . . . .
Example of searching a hash table . . . . . . . . . . . . . . . . . . .
Sample macro invocation, Standard form . . . . . . . . . . . . . . .
Generated statements from an OPEN macro . . . . . . . . . . . . .
Sample macro invocation using List form
. . . . . . . . . . . . . .
Generated statements from a List form OPEN macro
. . . . . . .
Sample macro invocation using Execute form . . . . . . . . . . . .
Generated statements from an Execute form OPEN macro . . . .
Sample macro invocation using empty List form . . . . . . . . . .
Generated instructions from empty List form . . . . . . . . . . . .
Sample macro invocation using Execute form . . . . . . . . . . . .
Generated statements from an Execute form OPEN macro . . . .
Another macro invocation using Execute form and same List form
An R-Type macro invocation generating an argument in a register
Generated statements from R-Type macro . . . . . . . . . . . . . .
A macro invocation with arguments in registers . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

Figures

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

898
900
901
901
903
903
904
906
909
910
910
910
911
911
913
913
913
914
914
914
914
914
915
915
916
916
916
917
917
918
919
920
920
920
920
921
921
921
922
923
923
923
924
924
926
926
928
929
937
938
938
939
939
939
939
939
939
939
940
940
940
940

xxvii

732.
733.
734.
735.
736.
737.
738.
739.
740.
741.
742.
743.
744.
745.
746.
747.
748.
749.
750.
751.
752.
753.
754.
755.
756.
757.
758.
759.
760.
761.
762.
763.
764.
765.
766.
767.
768.
769.
770.
771.
772.
773.
774.
775.

Generated statements from a Standard-form macro with arguments in registers

A Standard macro invocation specifying MODE=31 . . . . . . . . . . . . . .
. . . . .
Generated statements from a Standard-for macro with MODE=31
Example of a mixed-case positional macro argument . . . . . . . . . . . . . .
Example of mixed-case keyword macro arguments . . . . . . . . . . . . . . .
Example of mixed-case keyword macro arguments . . . . . . . . . . . . . . .
Sample ABEND macro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
Generated statements from an ABEND macro
Sample R=type GETMAIN request . . . . . . . . . . . . . . . . . . . . . . .
Expansion of a sample R-type GETMAIN request . . . . . . . . . . . . . . .
Expansion of a sample VRU-type GETMAIN request . . . . . . . . . . . . .
Example of an R-type FREEMAIN macro . . . . . . . . . . . . . . . . . . .
Sample STORAGE OBTAIN request . . . . . . . . . . . . . . . . . . . . . .
Example of a STORAGE OBTAIN macro expansion . . . . . . . . . . . . .
Sample STORAGE RELEASE request
. . . . . . . . . . . . . . . . . . . . .
Example of a STORAGE RELEASE macro expansion . . . . . . . . . . . .
A Data Set with records you want to read . . . . . . . . . . . . . . . . . . . .
You submitted a job with a program to read the records . . . . . . . . . . . .
Your program, loaded into memory before execution . . . . . . . . . . . . . .
Your program after executing the OPEN macro . . . . . . . . . . . . . . . . .
Your program after executing the GET macro . . . . . . . . . . . . . . . . . .
Your program after executing the CLOSE macro . . . . . . . . . . . . . . . .
Example of typical DCB parameters
. . . . . . . . . . . . . . . . . . . . . . .
Unblocked and blocked F-type record and block formats
. . . . . . . . . . .
Unblocked and blocked V-type record and block formats . . . . . . . . . . .
U-type block formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Completion of a DCB during OPEN processing
. . . . . . . . . . . . . . . .
DCBD operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DCBD operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . .
Using IHADCB to map two different DCBs simultaneously
A complete sample program . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Instruction cycle with interruptions . . . . . . . . . . . . . . . . . . . . . . . .
Establishing a program interruption exit . . . . . . . . . . . . . . . . . . . . .
Expansion of an ESPIE macro establishing a program interruption exit . . .
Terminating a program interruption exit . . . . . . . . . . . . . . . . . . . . .
Expansion of an ESPIE macro terminating a program interruption exit . . .
ESA/390-mode old PSW in EPIE . . . . . . . . . . . . . . . . . . . . . . . . .
Sketch of interruption handling control flow . . . . . . . . . . . . . . . . . . .
A simple ESTAE macro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Skeleton form of a reenterable program . . . . . . . . . . . . . . . . . . . . . .
I/O macros in a reenterable program . . . . . . . . . . . . . . . . . . . . . . .
Assembly listing for a simple reenterable program . . . . . . . . . . . . . . . .
Example of a reenterable, recursive routine . . . . . . . . . . . . . . . . . . . .
Assembly listing of the reenterable recursive routine
. . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

940
940
941
941
941
941
942
942
944
944
945
946
946
946
946
947
947
948
949
949
950
951
954
954
954
954
955
955
956
956
957
958
958
959
959
959
960
962
964
970
972
973
976
976

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

Tables
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.

xxviii

Binary, decimal, and hexadecimal . . . . . . .

Multiples of powers of sixteen (part 1 of 2)
.
Multiples of powers of sixteen (part 2 of 2)
.
Examples of twos complement representation
Examples of sign extension . . . . . . . . . . .
RR-type instruction format . . . . . . . . . . .
RX-type and RS-type instruction format . . .
SI-type instruction format
. . . . . . . . . . .
SS-type instruction format . . . . . . . . . . .
Instruction Length Code and instruction types
General instruction classifications . . . . . . .

Assembler Language Programming for IBM z System Servers

.
.
.
.
.
.
.
.
.
.
.

Version 1.00

.
.
.
.
.
.
.
.
.
.
.

20
22
23
31
32
54
54
54
55
56
57

12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.

Punched-card image of a RETURN statement

. . . . . . . . . . . . . . .
Assembler Language EBCDIC character representation
. . . . . . . . . .
Differences between Assembler Language and high-level language symbols
Expressions with absolute and relocatable terms . . . . . . . . . . . . . . .
Typical RR-type instructions . . . . . . . . . . . . . . . . . . . . . . . . . .
RR-type instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Typical RX-type instructions . . . . . . . . . . . . . . . . . . . . . . . . . .
RX-type instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Operands of RX-type instructions . . . . . . . . . . . . . . . . . . . . . . .
Typical RS- and SI-type instructions . . . . . . . . . . . . . . . . . . . . .
Typical RS-type instruction
. . . . . . . . . . . . . . . . . . . . . . . . . .
Operands of RS-type instructions . . . . . . . . . . . . . . . . . . . . . . .
Typical SI-type instruction . . . . . . . . . . . . . . . . . . . . . . . . . . .
Operands of SI-type instructions . . . . . . . . . . . . . . . . . . . . . . . .
Typical SS-type instructions . . . . . . . . . . . . . . . . . . . . . . . . . .
Typical type SS-1 instruction with one length field . . . . . . . . . . . . .
Operands of type SS-1 single-length instructions . . . . . . . . . . . . . . .
Typical type SS-2 instruction with two length fields . . . . . . . . . . . . .
Operands of type SS-2 two-length instructions . . . . . . . . . . . . . . . .
Examples of truncated and padded constants . . . . . . . . . . . . . . . . .
Truncation/padding rules for some DC operands . . . . . . . . . . . . . .
Truncation and padding rules for some DC operands with extended types
Load/Store instructions for 32-bit general registers
. . . . . . . . . . . . .
Format of an RX-type instruction . . . . . . . . . . . . . . . . . . . . . . .
Multiple load/store instructions for 32-bit general registers . . . . . . . . .
RS-type instruction format . . . . . . . . . . . . . . . . . . . . . . . . . . .
Halfword load/store instructions for 32-bit general registers . . . . . . . .
Character insert/store instructions for 32-bit general registers
. . . . . . .
Insert/Store characters under mask instructions for 32-bit general registers
. . . . . . . . . . . . . .
RS-type instruction format for ICM and STCM
CC settings after ICM instruction . . . . . . . . . . . . . . . . . . . . . . .
Register/register instructions for 32-bit general registers . . . . . . . . . . .
Action of five RR-type general register instructions . . . . . . . . . . . . .
Condition Code settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Register/storage instructions for 64-bit general registers . . . . . . . . . . .
RXY-type instruction format . . . . . . . . . . . . . . . . . . . . . . . . . .
RSY-type instruction format.
. . . . . . . . . . . . . . . . . . . . . . . . .
RRE-type instruction format . . . . . . . . . . . . . . . . . . . . . . . . . .
Register/register instructions for 64-bit general registers . . . . . . . . . . .
Action of five RR-type 64-bit general register instructions . . . . . . . . .
Load and Test instructions . . . . . . . . . . . . . . . . . . . . . . . . . . .
Register/register instructions for 64-bit general registers . . . . . . . . . . .
Action of 32-bit-to-64-bit general register instructions
. . . . . . . . . . .
Other general register load instructions . . . . . . . . . . . . . . . . . . . .
Summary of instructions discussed in this section . . . . . . . . . . . . . .
BCR instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BC instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mask bits and corresponding CC values . . . . . . . . . . . . . . . . . . .
CNOP operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Extended branch mnemonics and their branch mask values . . . . . . . .
Frequently used add and subtract instructions . . . . . . . . . . . . . . . .
CC settings for arithmetic add and subtract instructions . . . . . . . . . .
Arithmetic compare instructions . . . . . . . . . . . . . . . . . . . . . . . .
CC settings after arithmetic comparisons . . . . . . . . . . . . . . . . . . .
Logical arithmetic instructions . . . . . . . . . . . . . . . . . . . . . . . . .
CC settings for logical add and subtract instructions
. . . . . . . . . . . .
CC indications for logical addition and subtraction . . . . . . . . . . . . .
CC settings after logical addition . . . . . . . . . . . . . . . . . . . . . . . .
CC settings after logical subtraction . . . . . . . . . . . . . . . . . . . . . .
Logical arithmetic instructions with carry/borrow . . . . . . . . . . . . . .
Instructions for mixed-length operands . . . . . . . . . . . . . . . . . . . .
Arithmetic compare instructions . . . . . . . . . . . . . . . . . . . . . . . .

. . .
. . .
. .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

Tables

. .
. .
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

80
89
96
101
108
109
110
110
111
113
113
114
114
114
115
115
115
116
116
154
155
160
181
181
182
182
184
186
187
188
189
189
190
190
192
192
192
194
195
195
195
196
196
198
202
207
207
207
210
212
218
219
223
223
225
225
226
229
229
230
231
233

xxix

74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.

xxx

CC settings after logical comparisons . . . . . . . . . . . . . . . . . . . . . . . . .

IPM and SPM instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Program Mask bits
Summary of instructions discussed in this section . . . . . . . . . . . . . . . . . .
General register shift instructions
. . . . . . . . . . . . . . . . . . . . . . . . . . .
RS-type shift instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
RSY-type instruction format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
CC settings for arithmetic shift instructions
Summary of shift instructions discussed in this section . . . . . . . . . . . . . . .
Binary integer multiply instructions . . . . . . . . . . . . . . . . . . . . . . . . . .
Double-length arithmetic multiply instructions
. . . . . . . . . . . . . . . . . . .
Single-length arithmetic multiply instructions
. . . . . . . . . . . . . . . . . . . .
Logical multiply instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Binary divide instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Arithmetic divide instructions
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Binary divide instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary of multiply instructions discussed in this section . . . . . . . . . . . . .
Summary of divide instructions discussed in this section . . . . . . . . . . . . . .
Logical operations involving general registers
. . . . . . . . . . . . . . . . . . . .
CC settings by logical instructions . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary of the logical operations AND, OR, XOR . . . . . . . . . . . . . . . .
Logical-operation instructions discussed in this section . . . . . . . . . . . . . . .
Format of RXY- and RSY-type instructions . . . . . . . . . . . . . . . . . . . . .
Format of R-I instructions with 16-bit immediate operands . . . . . . . . . . . .
Format of R-I instructions with 32-bit immediate operands . . . . . . . . . . . .
PSW addressing-mode bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Load Address instructions
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Load Address instructions described in this section . . . . . . . . . . . . . . . . .
RI-type instruction
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
RIL-type instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Insert-Immediate instructions
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Load and insert instructions with immediate operands . . . . . . . . . . . . . . .
Arithmetic-immediate add and subtract instructions . . . . . . . . . . . . . . . . .
Arithmetic-immediate compare instructions . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
Arithmetic-immediate multiply instructions
AND-immediate instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OR-immediate instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
XOR-immediate instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Load and insert instructions with immediate operands . . . . . . . . . . . . . . .
Arithmetic instructions with immediate operands . . . . . . . . . . . . . . . . . .
Logical instructions with immediate operands . . . . . . . . . . . . . . . . . . . .
Format of the BRC instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Format of the BRCL instruction
. . . . . . . . . . . . . . . . . . . . . . . . . . .
Extended branch relative on condition mnemonics and their branch mask values
Branch on count instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Extended mnemonics for branch relative on count instructions . . . . . . . . . .
Branch on index instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
RS-type BXH and BXLE instructions . . . . . . . . . . . . . . . . . . . . . . . .
RSY-type BXHG and BXLEG instructions . . . . . . . . . . . . . . . . . . . . .
RSI-type BRXH and BRXLE instructions . . . . . . . . . . . . . . . . . . . . . .
RIE-type BRXHG and BRXLG instructions . . . . . . . . . . . . . . . . . . . .
Extended mnemonics for branch relative on index instructions . . . . . . . . . .
Branch relative on condition instructions . . . . . . . . . . . . . . . . . . . . . . .
Branch instructions for loop control . . . . . . . . . . . . . . . . . . . . . . . . . .
SI-type instruction format
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SIY-type instruction format
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SI-type instruction actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Move Immediate instructions
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Logical Storage-Immediate instructions . . . . . . . . . . . . . . . . . . . . . . . .
CC settings by SI-type logical instructions . . . . . . . . . . . . . . . . . . . . . .
Compare Immediate instructions
. . . . . . . . . . . . . . . . . . . . . . . . . . .
CC settings after CLI instruction
. . . . . . . . . . . . . . . . . . . . . . . . . . .

Assembler Language Programming for IBM z System Servers

Version 1.00

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

233
235
236
237
242
243
243
253
261
264
265
268
270
274
275
279
283
283
288
290
298
298
302
304
304
308
309
314
318
318
319
320
322
323
323
324
325
325
327
327
327
330
330
331
335
335
342
342
342
342
342
344
350
350
354
354
355
355
355
356
356
357

136.
137.
138.
139.
140.
141.
142.
143.
144.
145.
146.
147.
148.
149.
150.
151.
152.
153.
154.
155.
156.
157.
158.
159.
160.
161.
162.
163.
164.
165.
166.
167.
168.
169.
170.
171.
172.
173.
174.
175.
176.
177.
178.
179.
180.
181.
182.
183.
184.
185.
186.
187.
188.
189.
190.
191.
192.
193.
194.
195.
196.
197.

Storage-Immediate instructions
. . . . . . . . . . . . . . . . . . . . . . .
CC settings after TM instruction . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
Storage-Immediate instructions
Basic character-handling instructions . . . . . . . . . . . . . . . . . . . .
Format of single-length SS-type instructions . . . . . . . . . . . . . . . .
Instruction types and operand formats . . . . . . . . . . . . . . . . . . .
SS-type instructions with explicit length
. . . . . . . . . . . . . . . . . .
SS-type instructions with implied length . . . . . . . . . . . . . . . . . .
Determining the Length Specification Byte . . . . . . . . . . . . . . . . .
Condition Code settings for TRT and TRTR instructions . . . . . . . .
Execute instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modifiable portions of typical EX target instructions . . . . . . . . . . .
Operands of single-length SS-type instructions . . . . . . . . . . . . . . .
Basic instructions for data in storage
. . . . . . . . . . . . . . . . . . . .
Character-handling instructions using padding characters . . . . . . . . .
CC settings after MVCL . . . . . . . . . . . . . . . . . . . . . . . . . . .
CC settings after CLCL . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Format of MVCLE and CLCLE instructions . . . . . . . . . . . . . . .
CC settings after MVCLE
. . . . . . . . . . . . . . . . . . . . . . . . . .
CC settings after CLCLE . . . . . . . . . . . . . . . . . . . . . . . . . . .
Character-handling instructions for terminated strings
. . . . . . . . . .
Format of RRE-type instructions . . . . . . . . . . . . . . . . . . . . . .
CC settings for SRST instruction . . . . . . . . . . . . . . . . . . . . . .
CC settings for MVST instruction . . . . . . . . . . . . . . . . . . . . . .
CC settings for CLST instruction . . . . . . . . . . . . . . . . . . . . . .
CC settings for TRE instruction . . . . . . . . . . . . . . . . . . . . . . .
Compare Until Substring Equal instruction
. . . . . . . . . . . . . . . .
Condition Code settings by CUSE
. . . . . . . . . . . . . . . . . . . . .
Results of examples using the CUSE instruction
. . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
Extended instructions for character data
Old BCD character representation . . . . . . . . . . . . . . . . . . . . . .
Sample EBCDIC characters with varying code points among code pages
7-bit ASCII character representation
. . . . . . . . . . . . . . . . . . . .
Japanese DBCS assignments . . . . . . . . . . . . . . . . . . . . . . . . .
DBCS encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sample Unicode assignments . . . . . . . . . . . . . . . . . . . . . . . . .
Unicode string instructions . . . . . . . . . . . . . . . . . . . . . . . . . .
CC settings for SRSTU instruction . . . . . . . . . . . . . . . . . . . . .
CC settings after MVCLU . . . . . . . . . . . . . . . . . . . . . . . . . .
CC settings after CLCLU . . . . . . . . . . . . . . . . . . . . . . . . . . .
RRE-type instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
RRF-format instruction with an optional operand . . . . . . . . . . . .
Unicode translate instructions . . . . . . . . . . . . . . . . . . . . . . . .
Arguments and translate tables for TRxx instructions . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
Registers used by TRxx instructions
Condition Code settings for TRxx instructions
. . . . . . . . . . . . . .
Unicode format conversion instructions . . . . . . . . . . . . . . . . . . .
CC settings after Unicode format conversion instructions
. . . . . . . .
Byte-reversing load and store instructions
. . . . . . . . . . . . . . . . .
Extended instructions for Unicode data . . . . . . . . . . . . . . . . . . .
Unicode-based translate instructions . . . . . . . . . . . . . . . . . . . . .
Unicode format conversion instructions . . . . . . . . . . . . . . . . . . .
Summary of byte-reversing instructions . . . . . . . . . . . . . . . . . . .
Basic packed and zoned decimal instructions . . . . . . . . . . . . . . . .
Examples of zoned decimal data . . . . . . . . . . . . . . . . . . . . . . .
Punched-card image of two numbers, + 12345 and 67890
. . . . . . .
Examples of packed decimal data . . . . . . . . . . . . . . . . . . . . . .
Format of two-length SS-type instructions . . . . . . . . . . . . . . . . .
Operands of two-length SS-type instructions . . . . . . . . . . . . . . . .
Format of PKA and PKU instructions . . . . . . . . . . . . . . . . . . .
Format of UNPKA and UNPKU instructions
. . . . . . . . . . . . . .
CC settings after UNPKA, UNPKU instructions . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

Tables

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

358
358
366
367
367
369
369
370
371
385
390
395
397
398
404
406
408
411
413
414
416
416
417
418
420
422
424
425
425
426
430
431
432
434
435
438
440
440
441
442
442
442
443
444
444
444
447
447
449
451
451
452
452
454
456
457
460
463
463
472
473
474

xxxi

198.
199.
200.
201.
202.
203.
204.
205.
206.
207.
208.
209.
210.
211.
212.
213.
214.
215.
216.
217.
218.
219.
220.
221.
222.
223.
224.
225.
226.
227.
228.
229.
230.
231.
232.
233.
234.
235.
236.
237.
238.
239.
240.
241.
242.
243.
244.
245.
246.
247.
248.
249.
250.
251.
252.
253.
254.
255.
256.
257.
258.
259.

xxxii

Instructions for moving numeric and zone digits . . . . . . . . . . . . . . . . . .

Instructions for packing and unpacking data . . . . . . . . . . . . . . . . . . . .
CC settings for decimal addition and subtraction . . . . . . . . . . . . . . . . .
CC setting after decimal comparison
. . . . . . . . . . . . . . . . . . . . . . . .
Packed decimal arithmetic instructions . . . . . . . . . . . . . . . . . . . . . . .
Format of the TP instruction
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Operand formats for TP instruction . . . . . . . . . . . . . . . . . . . . . . . . .
CC settings for the TP instruction . . . . . . . . . . . . . . . . . . . . . . . . . .
CC settings by the ZAP, AP, and SP instructions . . . . . . . . . . . . . . . . .
CC setting by the CP instruction
. . . . . . . . . . . . . . . . . . . . . . . . . .
Format of the SRP instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary of decimal instruction behavior
. . . . . . . . . . . . . . . . . . . . .
Instructions used for converting and formatting packed decimal . . . . . . . . .
Format of the ED and EDMK instructions . . . . . . . . . . . . . . . . . . . .
CC settings after ED, EDMK . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ED and EDMK treatment of pattern characters . . . . . . . . . . . . . . . . . .
Basic floating-point instructions . . . . . . . . . . . . . . . . . . . . . . . . . . .
Instructions copying data between FPRs . . . . . . . . . . . . . . . . . . . . . .
Floating-point Load Zero instructions
. . . . . . . . . . . . . . . . . . . . . . .
Instructions moving data between FPRs and GPRs
. . . . . . . . . . . . . . .
Copy Sign instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Basic Load/Store instructions for floating-point operands . . . . . . . . . . . .
Instructions moving operands between GPRs and FPRs . . . . . . . . . . . . .
Hexadecimal floating-point data representations . . . . . . . . . . . . . . . . . .
Unnormalized and normalized short hexadecimal floating-point numbers . . .
Short hexadecimal floating-point numbers . . . . . . . . . . . . . . . . . . . . .
Long hexadecimal floating-point numbers . . . . . . . . . . . . . . . . . . . . .
Extended hexadecimal floating-point numbers . . . . . . . . . . . . . . . . . . .
Assembled hexadecimal floating-point constants . . . . . . . . . . . . . . . . . .
Hex floating-point constants with decimal exponents . . . . . . . . . . . . . . .
Length-modified hexadecimal floating-point constants . . . . . . . . . . . . . .
Hexadecimal floating-point constants with modifiers . . . . . . . . . . . . . . .
Hexadecimal floating-point rounding modes with subtype H
. . . . . . . . . .
Symbolic hexadecimal floating-point constants
. . . . . . . . . . . . . . . . . .
Difficult hexadecimal floating-point conversion values . . . . . . . . . . . . .
Data-moving hexadecimal floating-point instructions . . . . . . . . . . . . . . .
Hexadecimal floating-point Multiply instructions . . . . . . . . . . . . . . . . .
Summary of hexadecimal floating-point multiplication results . . . . . . . . . .
Hexadecimal floating-point Divide instructions
. . . . . . . . . . . . . . . . . .
Hexadecimal floating-point Halve instructions . . . . . . . . . . . . . . . . . . .
Hexadecimal floating-point Add/Subtract instructions
. . . . . . . . . . . . . .
Hexadecimal floating-point Compare instructions . . . . . . . . . . . . . . . . .
CC settings for hexadecimal floating-point comparison . . . . . . . . . . . . . .
Hexadecimal floating-point Round instructions . . . . . . . . . . . . . . . . . .
Hexadecimal floating-point Load Lengthened instructions . . . . . . . . . . . .
Hexadecimal floating-point FPR/GPR conversion instructions . . . . . . . . .
Format of HFP to fixed binary instructions . . . . . . . . . . . . . . . . . . . .
Rounding modifiers for HFP-to-binary conversion . . . . . . . . . . . . . . . .
CC settings for HFP-to-binary conversion . . . . . . . . . . . . . . . . . . . . .
Instructions moving/converting binary and hexadecimal floating-point operands
Hexadecimal floating-point instructions generating floating-point integers . . .
Hexadecimal floating-point Square Root instructions . . . . . . . . . . . . . . .
Hexadecimal floating-point Multiply and add/subtract instructions . . . . . . .
Format of RRF-type HFP multiply and add/subtract instructions . . . . . . .
Format of RXF-type multiply and add/subtract instructions
. . . . . . . . . .
Hexadecimal floating-point Move/Test instructions . . . . . . . . . . . . . . . .
Hexadecimal floating-point Multiply instructions . . . . . . . . . . . . . . . . .
Hexadecimal floating-point Divide instructions
. . . . . . . . . . . . . . . . . .
Hexadecimal floating-point Add, Subtract, and Compare instructions . . . . .
Hexadecimal floating-point Round instructions . . . . . . . . . . . . . . . . . .
Hexadecimal floating-point Lengthening instructions . . . . . . . . . . . . . . .
Convert hexadecimal floating-point to binary instructions . . . . . . . . . . . .

Assembler Language Programming for IBM z System Servers

Version 1.00

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

476
476
479
480
489
490
490
490
491
496
503
521
522
526
534
536
555
556
556
557
557
558
558
574
575
575
576
576
578
578
579
581
582
583
583
584
586
588
590
591
593
602
602
603
605
606
608
608
608
609
612
613
614
614
614
617
617
617
618
618
618
618

260.
261.
262.
263.
264.
265.
266.
267.
268.
269.
270.
271.
272.
273.
274.
275.
276.
277.
278.
279.
280.
281.
282.
283.
284.
285.
286.
287.
288.
289.
290.
291.
292.
293.
294.
295.
296.
297.
298.
299.
300.
301.
302.
303.
304.
305.
306.
307.
308.
309.
310.
311.
312.
313.
314.
315.
316.
317.
318.
319.
320.
321.

Convert binary to hexadecimal floating-point instructions . . . . . . . . . .

Form hexadecimal floating-point integer instructions . . . . . . . . . . . . .
Hexadecimal floating-point Square Root instructions . . . . . . . . . . . . .
Hexadecimal floating-point Multiply-Add/Subtract instructions . . . . . . .
Binary floating-point data representations
. . . . . . . . . . . . . . . . . . .
Examples of short-precision binary floating-point normal values . . . . . .
Examples of short-precision binary floating-point denormalized values . . .
Examples of short-precision binary floating-point special values . . . . . . .
Nominal-value operands for binary floating-point special values
. . . . . .
Assembled binary floating-point special-value constants . . . . . . . . . . .
Minimum bit lengths for binary floating-point constants . . . . . . . . . . .
Binary floating-point DXC values . . . . . . . . . . . . . . . . . . . . . . . .
Binary floating-point FPC register control instructions . . . . . . . . . . . .
Invalid operation binary floating-point exception . . . . . . . . . . . . . . .
Divide by zero binary floating-point exception . . . . . . . . . . . . . . . . .
Exponent overflow binary floating-point exception . . . . . . . . . . . . . .
Exponent underflow binary floating-point exception . . . . . . . . . . . . .
Inexact result binary floating-point exception
. . . . . . . . . . . . . . . . .
BFP overflow/underflow scale factors . . . . . . . . . . . . . . . . . . . . . .
Binary floating-point Test Data Class instructions . . . . . . . . . . . . . . .
Test Data Class second-operand bits . . . . . . . . . . . . . . . . . . . . . .
Test Data Class second-operand test-bit/tested-value correspondence . . . .
Binary floating-point RR-type data movement instructions . . . . . . . . .
CC settings for BFP data movement instructions . . . . . . . . . . . . . . .
Binary floating-point Multiply instructions . . . . . . . . . . . . . . . . . . .
Binary floating-point Divide instructions . . . . . . . . . . . . . . . . . . . .
Binary floating-point Add and Subtract instructions
. . . . . . . . . . . . .
CC settings after BFP add/subtract instructions . . . . . . . . . . . . . . . .
Binary floating-point Compare instructions
. . . . . . . . . . . . . . . . . .
CC settings for BFP comparisons . . . . . . . . . . . . . . . . . . . . . . . .
Binary floating-point Compare and Signal instructions . . . . . . . . . . . .
Binary floating-point Round instructions . . . . . . . . . . . . . . . . . . . .
Binary floating-point Lengthening instructions . . . . . . . . . . . . . . . . .
Binary integer to binary floating-point conversion instructions
. . . . . . .
Binary floating-point to integer conversion instructions . . . . . . . . . . . .
Format of BFP Convert To Fixed instructions . . . . . . . . . . . . . . . .
Rounding modifier for BFP convert to fixed instructions
. . . . . . . . . .
CC settings after convert to binary instructions . . . . . . . . . . . . . . . .
Load floating-point integer instructions . . . . . . . . . . . . . . . . . . . . .
Rounding mode modifiers for BFP load integer instructions . . . . . . . . .
Binary floating-point Divide to Integer instructions . . . . . . . . . . . . . .
Format of BFP Divide to Integer instructions . . . . . . . . . . . . . . . . .
CC settings after divide to integer instructions . . . . . . . . . . . . . . . . .
Binary floating-point Square Root instructions
. . . . . . . . . . . . . . . .
Binary floating-point Multiply and Add/Subtract instructions . . . . . . . .
Summary of binary floating-point instructions with uniform operand lengths
Binary floating-point Multiply instructions . . . . . . . . . . . . . . . . . . .
Binary floating-point Round instructions . . . . . . . . . . . . . . . . . . . .
Binary floating-point Lengthening instructions . . . . . . . . . . . . . . . . .
Convert binary floating-point to binary integer instructions . . . . . . . . .
Convert binary integer to binary floating-point instructions . . . . . . . . .
Summary of binary floating-point operations and exceptions
. . . . . . . .
Decimal floating-point data representations
. . . . . . . . . . . . . . . . . .
Declet encoding for BCD digits . . . . . . . . . . . . . . . . . . . . . . . . .
Converting decimal floating-point declets to BCD digits . . . . . . . . . . .
First five bits of special-values Combination Field
. . . . . . . . . . . . . .
First 5 bits of finite-value Combination Field . . . . . . . . . . . . . . . . .
Properties of decimal floating-point representations . . . . . . . . . . . . . .
Assembled decimal floating-point special-value constants
. . . . . . . . . .
Examples of decimal floating-point short precision zeros . . . . . . . . . . .
Assembler rounding-mode suffixes for DFP constants . . . . . . . . . . . .
Decimal floating-point Test Data Class instructions . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

Tables

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

618
619
619
619
625
627
627
628
631
631
632
637
638
638
639
639
639
639
640
641
641
641
642
642
644
646
648
648
649
649
650
651
651
653
653
653
654
654
655
656
656
656
657
658
659
660
661
661
661
662
662
662
670
672
672
674
674
675
677
677
677
680

xxxiii

322.
323.
324.
325.
326.
327.
328.
329.
330.
331.
332.
333.
334.
335.
336.
337.
338.
339.
340.
341.
342.
343.
344.
345.
346.
347.
348.
349.
350.
351.
352.
353.
354.
355.
356.
357.
358.
359.
360.
361.
362.
363.
364.
365.
366.
367.
368.
369.
370.
371.
372.
373.
374.
375.
376.
377.
378.
379.
380.
381.
382.
383.

xxxiv

DFP Test Data Class second-operand bits . . . . . . . . . . . . . . . . . . . .

Test Data Class test-bit vs. tested-class correspondence . . . . . . . . . . . . .
Example of DFP rounding modes . . . . . . . . . . . . . . . . . . . . . . . . .
Preferred quanta for some decimal floating-point operations . . . . . . . . . .
Decimal floating-point additional DXC value . . . . . . . . . . . . . . . . . .
Decimal floating-point quantum exception . . . . . . . . . . . . . . . . . . . .
Decimal floating-point scale factors for exponent spills . . . . . . . . . . . . .
Copy Sign instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Instructions moving data between FPRs and GPRs
. . . . . . . . . . . . . .
Instructions copying data between FPRs . . . . . . . . . . . . . . . . . . . . .
Decimal floating-point basic arithmetic instructions . . . . . . . . . . . . . . .
Format of DFP arithmetic instructions . . . . . . . . . . . . . . . . . . . . . .
Format of DFP arithmetic instructions with rounding mask . . . . . . . . . .
Instruction-specific rounding mask values
. . . . . . . . . . . . . . . . . . . .
CC settings for Add/Subtract instructions
. . . . . . . . . . . . . . . . . . . .
CC settings for Compare instructions . . . . . . . . . . . . . . . . . . . . . . .
Decimal floating-point Compare instructions
. . . . . . . . . . . . . . . . . .
Decimal floating-point Compare and Signal instructions . . . . . . . . . . . .
Decimal floating-point Compare Biased Exponent instructions . . . . . . . .
CC settings for Compare Biased Exponent instructions
. . . . . . . . . . . .
Decimal floating-point convert to/from fixed binary instructions . . . . . . .
Format of Convert to Fixed Binary instructions . . . . . . . . . . . . . . . . .
Format of Convert to Fixed Binary instructions . . . . . . . . . . . . . . . . .
CC settings for Convert to Fixed instructions . . . . . . . . . . . . . . . . . .
Decimal floating-point convert to/from signed packed decimal instructions .
Format of Convert to Signed Packed instructions . . . . . . . . . . . . . . . .
Decimal floating-point convert to/from unsigned packed decimal instructions
Instructions converting between decimal floating-point and zoned decimal
.
Format of DFP/zoned decimal conversion instructions . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
Condition Code settings for Convert to Zoned
Decimal floating-point Load and Test instructions . . . . . . . . . . . . . . .
CC setting after DFP Load and Test instructions . . . . . . . . . . . . . . . .
Instructions copying/complementing data between FPRs
. . . . . . . . . . .
Decimal floating-point Load Floating-point Integer instructions
. . . . . . .
Format of Load FP Integer instructions . . . . . . . . . . . . . . . . . . . . .
Decimal floating-point Load Lengthened instructions . . . . . . . . . . . . . .
Load Lengthened special operand control mask . . . . . . . . . . . . . . . . .
Decimal floating-point rounding/lengthening instructions
. . . . . . . . . . .
Decimal floating-point Set Rounding Mode instruction
. . . . . . . . . . . .
. . . . .
Decimal floating-point Insert/Extract Biased Exponent instructions
Extracted Biased Exponent for DFP special values . . . . . . . . . . . . . . .
DFP Insert Biased Exponent results . . . . . . . . . . . . . . . . . . . . . . . .
Decimal floating-point Extract Significance instructions
. . . . . . . . . . . .
Decimal floating-point Shift Significand instructions . . . . . . . . . . . . . .
Format of DFP shift instructions . . . . . . . . . . . . . . . . . . . . . . . . .
Decimal floating-point Quantize instructions . . . . . . . . . . . . . . . . . . .
Format of decimal floating-point Quantize instructions . . . . . . . . . . . . .
Decimal floating-point Reround instructions . . . . . . . . . . . . . . . . . . .
Decimal floating-point Test Data Group instructions . . . . . . . . . . . . . .
Test Data Group second-operand bits
. . . . . . . . . . . . . . . . . . . . . .
DFP Test Data Class and Test Data Group instructions . . . . . . . . . . . .
DFP Arithmetic and related instructions . . . . . . . . . . . . . . . . . . . . .
DFP length and type conversion instructions
. . . . . . . . . . . . . . . . . .
DFP rounding and lengthening instructions . . . . . . . . . . . . . . . . . . .
DFP data-loading instructions . . . . . . . . . . . . . . . . . . . . . . . . . . .
Instructions copying between FPRs and GPRs . . . . . . . . . . . . . . . . .
Instruction setting decimal rounding mode . . . . . . . . . . . . . . . . . . . .
Non-canonical declets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary of z System floating-point representations . . . . . . . . . . . . . .
Adding 0.1 in hexadecimal, binary, and decimal floating-point . . . . . . . . .
Exception behavior for hexadecimal floating-point
. . . . . . . . . . . . . . .
Exception behavior for binary and decimal floating-point
. . . . . . . . . . .

Assembler Language Programming for IBM z System Servers

Version 1.00

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

680
681
682
684
685
685
685
686
686
686
687
687
688
688
690
691
691
692
692
692
693
694
694
695
696
696
697
699
699
700
701
701
701
702
702
702
703
703
704
705
706
706
706
707
707
708
708
710
712
712
718
718
718
718
719
719
719
719
725
727
727
727

384.
385.
386.
387.
388.
389.
390.
391.
392.
393.
394.
395.
396.
397.
398.
399.
400.
401.
402.
403.
404.
405.
406.
407.
408.
409.
410.
411.
412.
413.
414.
415.
416.
417.
418.
419.
420.
421.
422.
423.
424.
425.
426.
427.
428.
429.
430.
431.
432.
433.
434.
435.
436.
437.
438.
439.
440.
441.
442.
443.
444.

Length modifiers of floating-point constants . . . . . . . . . . . . .

Assembler rounding-mode suffixes for floating-point constants . .
. . . . .
Internal precision required for faithful In-Out conversion
Decimal precision required for faithful Out-In conversion . . . . .
Perform Floating-Point Operation instruction . . . . . . . . . . . .
Laws of real and realistic arithmetic . . . . . . . . . . . . . . . . . .
Examples of hexadecimal floating-point pseudo-zeros . . . . . . . .
. . . . . . . . . .
Examples of other floating-point representations
Equivalent decimal and floating-point precisions
. . . . . . . . . .
Branch and Save instructions . . . . . . . . . . . . . . . . . . . . . .
Standard (Format-0) Save Area . . . . . . . . . . . . . . . . . . . .
Standard Format-4 save area . . . . . . . . . . . . . . . . . . . . . .
Standard Format-5 save area . . . . . . . . . . . . . . . . . . . . . .
AMODE values . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
R M O D E values . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Default AMODE and RMODE values . . . . . . . . . . . . . . . .
Valid combinations of AMODE and RMODE values . . . . . . .
Differences in linking COMMONs and External dummy items . .
ESD symbol search types . . . . . . . . . . . . . . . . . . . . . . . .
Matching existing CESD SD symbol to incoming symbols
. . . .
Matching existing CESD LD symbol to incoming symbols . . . .
Matching existing CESD CM symbol to incoming symbols . . . .
Matching existing CESD ER symbol to incoming symbols . . . .
Matching existing CESD ER symbol to incoming symbols . . . .
. . . . . . . . . . .
Comparing load modules and program objects
Instructions to change addressing mode . . . . . . . . . . . . . . . .
CC settings for TAM instruction
. . . . . . . . . . . . . . . . . . .
PSW addressing-mode bits . . . . . . . . . . . . . . . . . . . . . . .
BASSM actions summary
. . . . . . . . . . . . . . . . . . . . . . .
Operation of BSM instruction . . . . . . . . . . . . . . . . . . . . .
BSM actions summary . . . . . . . . . . . . . . . . . . . . . . . . .
Instruction pairs for call/return with possible AMODE change . .
Calling among addressing modes within an assembly . . . . . . . .
LLGT and LLGTR instructions . . . . . . . . . . . . . . . . . . . .
Symbol table entries for DSECT symbols . . . . . . . . . . . . . .
Summary of USING Statements . . . . . . . . . . . . . . . . . . . .
Summary of DROP Statement Behaviors
. . . . . . . . . . . . . .
Example of a non-homogeneous array . . . . . . . . . . . . . . . .
Array addressing with a table of addresses . . . . . . . . . . . . . .
Example of an address tables contents . . . . . . . . . . . . . . . .
Supervisor and Program Call instructions
. . . . . . . . . . . . . .
SVC instruction format . . . . . . . . . . . . . . . . . . . . . . . . .
PC instruction format . . . . . . . . . . . . . . . . . . . . . . . . . .
GETMAIN request options . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
FREEMAIN request options
Comparing QSAM and BSAM
. . . . . . . . . . . . . . . . . . . .
Partial contents of Extended Program Interruption Element (EPIE)
Hexadecimal, decimal, and binary . . . . . . . . . . . . . . . . . . .
Hexadecimal Addition Table . . . . . . . . . . . . . . . . . . . . . .
Hexadecimal Multiplication Table . . . . . . . . . . . . . . . . . . .
Integer powers of 2
. . . . . . . . . . . . . . . . . . . . . . . . . . .
Integer powers of 2
. . . . . . . . . . . . . . . . . . . . . . . . . . .
Multiples of powers of sixteen (part 1 of 2)
. . . . . . . . . . . . .
Multiples of powers of sixteen (part 2 of 2)
. . . . . . . . . . . . .
Powers of 10 expressed in hexadecimal . . . . . . . . . . . . . . . .
Assembler Language EBCDIC character representation
. . . . . .
7-bit ASCII character representation
. . . . . . . . . . . . . . . . .
High Level Assembler DC-Statement Constant Types . . . . . . .
ASCII Character Representation . . . . . . . . . . . . . . . . . . . .
Examples of different types of integer division . . . . . . . . . . . .
Comparing five binary floating-point operands
. . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

Tables

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

728
728
730
730
731
732
734
736
737
744
756
759
761
813
814
814
814
827
827
829
829
829
830
830
841
844
844
844
846
846
847
848
848
849
857
890
890
900
903
904
936
936
937
944
945
952
960
981
982
982
983
984
986
986
987
998
999
1000
1061
1112
1197

xxxv

xxxvi

Assembler Language Programming for IBM z System Servers

Version 1.00

Foreword
FFFFFFFFFFFF
FFFFFFFFFFFF
FF
FF
FF
FFFFFFFF
FFFFFFFF
FF
FF
FF
FF
FF

WW
WW
WW
WW
WW
WW
WW
WW
WW
WW
WW
WW
WW WW WW
WW WWWW WW
WW WW WW WW
WWWW
WWWW
WWW
WWW
WW
WW

Outline and Overview

We will survey many aspects of Assembler Language programming on z System processors.
Chapters I-IV cover basic material needed for almost all programs.
Chapter I introduces some notation well use, and discusses the important topics of binary and
hexadecimal number representations and arithmetic, and conversion among number representations.
Chapter II introduces the Central Processing Unit or CPU. Well survey central memory,
the registers youll use in your programs, and the Program Status Word (PSW). Then well
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, selfdefining 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 z System: 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

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, conversion, and display operations.

Programming Environments
Every programming language must eventually deal with the environments under which the programs will be run. While we will see many examples of program segments, we will defer complete
programs until later sections.
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 Systems Supervisor are described in
Appendix B: Simple I/O Macros on page 1001; 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.
The Exercise and Programming Problem solutions should be considered as samples, and are not
in any way intended to be the correct solutions. 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 useful approaches to solving a programming
problem.

Some 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 calculating 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

Assembler Language Programming for IBM z System Servers

Version 1.00

concepts such as loops and conditional branching. Because the internal structures of computers have many similarities, I sometimes try to point out not only what a particular
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 large 1 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. 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.

Yes, this book is too long. As my Chinese-restaurant fortune cookie said: You have a love for words, and should
write a book.
Foreword

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

NN
NN
NNN
NN
NNNN
NN
NN NN
NN
NN NN
NN
NN NN NN
NN
NN NN
NN
NN NN
NN
NNNN
NN
NNN
NN
NN
NN
NN

A digital computer can be considered from various viewpoints; here are five possible views, each
treating the computers 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 computation of a quotient.
At the next level one might consider a computers 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 macroinstructions that perform operations in a larger context.
The level that is our primary concern is usually known as Assembler Language programming or
Assembler coding. 2 The Assembler well 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 z System.
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 3 and the operating system Supervisor. Each will be considered
in the appropriate context.

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 z System processors operations.
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.)

Assembler Language Programming for IBM z System Servers

Version 1.00

To give hardware designers greater freedom to implement instructions in the best way, without
your having to be aware of each implementations techniques, IBM describes an architecture.
A processors 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 behaviors.
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 z System architecture. You should consult it regularly 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 youre writing programs.

Why Program in Assembler Language (and Why Not)?

Before going any further, ask why youre considering writing programs in Assembler Language.
These are some reasons for programming in Assembler Language:
1. You have to.
Maybe youre taking a course like Assembler Language Programming, or youve been
made responsible for an existing Assembler Language application.
2. You want to.
Its useful to know, or maybe youre 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-1960s, 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. Its 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
processors properties will help you understand why certain choices and tradeoffs are made in
programming in those languages.
4. Its fundamental.
A key to writing efficient software is understanding the underlying hardware; no language
other than Assembler Language provides such insights. Even if you dont write much Assembler 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 isnt very highlevel, but it is necessary at times.)
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 Language can often lead to savings.

Foreword

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 programs lifetime.4
There is another objection to using Assembler Language to attain efficiency: some modern
compilers can produce quite efficient code for certain applications.5 However, even clever
coding and powerful compilers cant help a badly implemented algorithm. Also, you may
have difficulty learning the costs of various high-level language statements.
6. Its 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. Its more flexible.
There are some processor 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 elses program structures or concepts of proper programming technique arent forced on you by the language, and you have
more freedom to choose solutions you like.
8. Its more powerful.
In addition to Assembler Languages efficiency and flexibility, you also have available to you
the entire repertoire of the processors instruction set. New instructions on your CPU are
usable immediately; you dont 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. Its 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. Its controllable.
Unlike higher-level languages, the Assembler creates machine language instructions and
data in exactly the form and order you specify. It doesnt 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.
11. Its stable.
You neednt worry about re-translating and re-testing programs with new releases of compilers or run-time libraries; the object code wont change each time you re-assemble.
12. Its 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 Language 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.

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, Ive done that...)
Compilers do have occasional errors; finding problems with the generated code is easier if you know Assembler
Language.
Assembler Language Programming for IBM z System Servers

Version 1.00

13. Its 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 programming. Unfortunately, we dont 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 processors 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 semantics of the Assembler Language are due to irregularities in the z System 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 languages flexibility means its 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 maintenance costs between Assembler Language and high-level languages.
7. Lack of a run-time library.
Assembler Language programs can be written as a component of a high-level language application. But stand-alone Assembler Language applications may not have access to the runtime 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 appropriate 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 programs are not always easily moved to other processor architectures!)
Foreword

If none of the reasons for programming in Assembler Language has much appeal to you you
dont have to program in Assembler Language, you dont need its efficiency, flexibility, power, or
extensibility, and your sources of amusement (or employment) lie elsewhere then dont. 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 important 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.
Its 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. (Well offer occasional bits of advice on ways to simplify your programming 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 zSeries instructions.
Its 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 dont 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.
Its 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 complete at home more promptly and cheaply.
You dont need to worry about efficiency, because a faster CPU will be along in a year.
Rarely true, because growing businesses continually need to process more data and their programs must provide new capabilities. Once you fall behind, its 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 opportunity.

Assembler Language Programming for IBM z System Servers

Version 1.00

Converting and validating test cases can be a major effort in itself.

High stress levels for bilingual staff.

You cant 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!
Whats good about Assembler Language?
Almost everything you do works OK.
Whats 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

Assembler Language Programming for IBM z System Servers

Version 1.00

Index
A
access register
addition
address constant
address generation
address resolution
address translation
addressing
addressing halfword
addressing mode
alignment
architecture
definition 5
arithmetic
ASCII
Assembler 4
assembler instruction statement
Assembler Language 4
assembler option
assembly
attribute
attribute reference
See attribute reference

data structure
decimal floating-point
decimal overflow
See overflow
decimal self-defining term
See self-defining term
definition
dependent USING
division
DROP assembler instruction
DSECT assembler instruction
DXC
See Data Exception Code

E
editing
Effective Address
Encoded Length
exception
See interruption
expression
extended mnemonic
External Symbol Dictionary

binary
binary floating-point
binary self-defining term
See self-defining term
blank

fixed-point binary
fixed-point overflow
See overflow
floating-point
Floating-Point Control Register
floating-point overflow
See overflow
floating-point register
floating-point underflow
See underflow
FPCR
See Floating-Point Control
Register
FPR
See floating-point register
fraction conversion

C
central processing unit (CPU)
character
character self-defining term
See self-defining term
comparison
complementation
Condition Code
constant
control register
control section
See section
conversion
CPU
See central processing unit

G
general register
GPR
See general register

data

hexadecimal

hexadecimal floating-point
hexadecimal self-defining term
See self-defining term
HLASM 4

I
IA
See Instruction Address
IBM High Level Assembler for
z/OS & z/VM & z/VSE 4
ILC
See Instruction Length Code
immediate operand
instruction
Instruction Address
instruction format
Instruction Length Code
instruction operation
instruction register
integer conversion
interruption
interruption code

L
labeled dependent USING
labeled USING
length field
library
linkage convention
Linker
literal
load module
Location Counter
logical

M
machine instruction
macro instruction
memory address
mnemonic
multiplication

N
notation

O
object module
ones complement representation
operand

Index

operation code
operator
option
See assembler option
ordinary USING
overflow

Z
z/Architecture 3
zoned decimal

P
packed decimal
pattern
program interruption
See interruption
Program Loader
Program Mask
program object
Program Status Word
PSW
See Program Status Word

Q
quantum

R
recipe
register
relative-immediate
relocatable
relocation attribute
representation
residence mode

S
section
self-defining term
shift
space
See blank
statement
subtraction
symbol

T
term
time
twos complement representation

U
underflow
Unicode
USING assembler instruction

Assembler Language Programming for IBM z System Servers

Version 1.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 well use.
Section 2 describes basic topics about the number representations used in z System processors:
binary and hexadecimal numbers, arithmetic and logical representations, 2s complement arithmetic, and discusses alternative number representations.

Chapter I: Getting Started

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 well use later, and then investigate 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 objects 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

Field1 Field2

0
3 4
7

Field widths

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 superscripts 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.
For the operations of addition, subtraction, multiplication, and division, we use the operators
+, , *, and / respectively. (In some descriptions, we use for multiplication and for

Assembler Language Programming for IBM z System Servers

Version 1.00

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 were 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 contents 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 z System and its Assembler Language.
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 GR R 1 is the first operand, and the contents of storage addressed by S2 is
the second operand. Note that operand numbers may not correspond 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.
Well 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,
JohnQ.Public
has a blank on each side of the middle initial.
Sometimes we refer to the euro character. Because this document formatter doesnt 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 14?

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

D2(X2,B2)

where the subscripted letters specify numeric values appearing in the fields of a machine instruction. They are simply a way to indicate numbers that you or the Assembler must provide. In
particular:

Chapter I: Getting Started

A notation like R 1 is simply a number that usually denotes any register, not register
number 1.
G R R 1 means the general register denoted by the number used in place of R1.
GR1 means general register 1.
Well 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 isnt really a register name; its only a name for a number. (Some exercises will help you
understand why it can be misleading.) I dont 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.6 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 z System 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 nickname 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 controls, and the physical implementation. 7
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.
Assembler
A program that translates programs written in Assembler Language to machine language
instructions and data.
HLASM
IBMs High Level Assembler for z/OS and z/VM and z/VSE. The Assembler we describe
here.

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, its no longer necessary to name registers.
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.
Assembler Language Programming for IBM z System Servers

Version 1.00

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

Chapter I: Getting Started

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.
z System, like most other digital computers, uses binarybase 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 z System, 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
11000 + 7100 + 010 + 51,
or as
1103 + 7102 + 0101 + 5100.
That is, each digit position as we move to the left is weighted by one more power of the base, ten.

Assembler Language Programming for IBM z System Servers

Version 1.00

Similarly, when in binary notation we write 11010 we mean

10000 + 1000 + 000 + 10 + 0,
124 + 123 + 022 + 121 + 020,
116 + 18 + 04 + 12 + 01
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 Assemblers: 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 = B11010, 1 = B1, 10 = B1010, 8 = B1000, 999 = B1111100111.
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 = 153 + 452 + 151 + 350
= 125 + 100 + 5 + 3
= 23310

Exercises
2.1.1.(1) + Determine the decimal value of the following binary numbers: (a) B000010110, (b)
B000101100, (c) B10101010, (d) B1111111.
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 represented 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 20. (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.8)
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
A163 + 9162 + 7161 + E160,
or
10163 + 9162 + 7161 + 14160 = 104096 + 9256 + 716 + 14 = 43390.

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

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 z System. Other groupings are possible; another form is octal, or
base eight, in which the binary digits are grouped by threes.9
Table 1. Binary, decimal, and
hexadecimal

Binary
Digits

Decimal
Value

Hex
Digit

0000
0001
0010
0011
0100
0101
0110
0111
1000
1001
1010
1011
1100
1101
1110
1111

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

0
1
2
3
4
5
6
7
8
9
A
B
C
D
E
F

The base sixteen digits in the third column are called hexadecimal10 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 Assemblers will denote hexadecimal quantities: the hexadecimal digits are preceded
by an X and an apostrophe, and are followed by an apostrophe. For example:
26 = B11010 = X 1A ,

X26 = B100110 = 38,

1 = B1 = X 1 ,

10 = B1010 = X A ,

B1000 = 8 = X 8 ,

100 = X64 = B1100100.

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 = B1101 0101 1011

(hexadecimal to binary),

B11 1110 1000 = X 3 E8

(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
X11 = B10001

(rather than B00010001).

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.
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.
Assembler Language Programming for IBM z System Servers

Version 1.00

Dont omit zeros on the right! That is, B00111100 /= X F .

Converting between decimal and hexadecimal representations is more cumbersome; it is simplest
to use Tables 2 and 3 starting on page 22 below, and the tables in Appendix A: Conversion and
Reference Tables on page 981. 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 3 E8 .
2.2.2.(1) Make a table similar to Table 1 on page 20 showing binary, decimal, and octal (base
8) values.
2.2.3.(2) In grouping bits to form hex digits, why cant 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.
2.
3.
4.
5.

21474
77777
1750
60341303
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 multiplication 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
7A4 + 3A3 + 2A2 + 9A1 + 4A0.
Using symbols, the digit string
dn ... d3 d2 d1 d0
is the representation in some base A of a number X:
X = dnAn + ... + d3A3 + d2A2 + d1A1 + d0A0.
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 + ... + e3B3 + e2B2 + e1B1 + e0B0.
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

X = B Quotient + Remainder
= B [em B(m-1) + ... + e3B2 + e2B1 + e1B0] + 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 digits 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
232
-224
8
-8
0

hex digit 3
hex digit E
hex digit 8

so that 1000 (decimal) is X 3 E8 .

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

Hex Digit
1
2
3
4
5
6
7
8
9
A
B
C
D
E
F

160
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

161
16
32
48
64
80
96
112
128
144
160
176
192
208
224
240

Assembler Language Programming for IBM z System Servers

162
256
512
768
1,024
1,280
1,536
1,792
2,048
2,304
2,560
2,816
3,072
3,328
3,584
3,840

Version 1.00

163
4,096
8,192
12,288
16,384
20,480
24,576
28,672
32,768
36,864
40,960
45,056
49,152
53,248
57,344
61,440

164
65,536
131,072
196,608
262,144
327,680
393,216
458,752
524,288
589,824
655,360
720,896
786,432
851,968
917,504
983,040

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

Hex Digit
1
2
3
4
5
6
7
8
9
A
B
C
D
E
F

165
1,048,576
2,097,152
3,145,728
4,194,304
5,242,880
6,291,456
7,340,032
8,388,608
9,437,184
10,485,760
11,534,336
12,582,912
13,631,488
14,680,064
15,728,640

166
16,777,216
33,554,432
50,331,648
67,108,864
83,886,080
100,663,296
117,440,512
134,217,728
150,994,944
167,772,160
184,549,376
201,326,592
218,103,808
234,881,024
251,658,240

167
268,435,456
536,870,912
805,306,368
1,073,741,824
1,342,177,280
1,610,612,736
1,879,048,192
2,147,483,648
2,415,919,104
2,684,354,560
2,952,790,016
3,221,225,472
3,489,660,928
3,758,096,384
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 = 210 as 4K. Similarly, 3220 might
be referred to as 3M. Thus, for example, an area of memory (which well discuss in Section
3.1) containing 8,192 storage locations might be said to contain 8K bytes or 8 K-bytes. 11

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

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

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

2.3.2.(2) Convert the following to decimal.

1. X 7 FFFFFFF
2. X C1C2C3
3. X4040405C (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.
2.
3.
4.
5.
6.

X257
X 7 FFA
X8008
X E000
X FFFA
X E1010

2.3.5.(3) Suppose we must convert a number from its representation in base A to its representation 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?

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

2.3.6.(2) Convert these octal (base 8) numbers to base 10: (a) 5061, (b) 257, (c) 192. Work
carefully!
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
2)19
18
1=e0

4
2)9
8
1=e1

2
2)4
4
0=e2

1
2)2
2
0=e3

0
2)1
0
1=e4

Hence, 19 = B10011.
2. Convert 1000 (base 10) to base 16. (The conversion arithmetic is done in base 10.)
62
16)1000
992
8=e0

3
0
16)62
16)3
48
0
14 (X E ) =e1
3=e2

Hence 1000 = X 3 E8 .
3. Convert 627 (base 10) to base 9.
69
9)627
621
6=e0

7
9)69
63
6=e1

0
9)7
0
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) = 781 + 69 + 6 = 567 + 54 + 6 = 627 (base 10)
89
7)627
623
4=e0

12
7)89
84
5=e1

1
7)12
7
5=e2

0
7)1
0
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
7)766
762
4=e0

13
7)108
103
5=e1

1
7)13
7
5=e2

0
7)1
0
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) = 1125 + 425 + 15 + 3 = 233 10 .

Assembler Language Programming for IBM z System Servers

Version 1.00

If you are still (or very) mathematically inclined:

Alternatively, since 10 (base 10) = 20 (base 5), we can do the conversion in base 5 arithmetic:
43
20)1413
130
113
110
3=e0

2
20)43
40
3=e1

0
20)2
0
2=e2

Again, we find 1413 (base 5) = 233 (base 10).

6. Convert X 3 E8 to base 10. In this case it is simpler to evaluate the positional notation:
X 3 E8 = 3162 + 14161 + 8160,
and then evaluate this sum in decimal. Thus we find
X 3 E8 = 3256 + 1416 + 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., respectively.
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 B1111101000 to base 10 using binary arithmetic (that is, divide by B1010).
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 = (((...(dnA)+...+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 multiplied 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.
Chapter I: Getting Started

2. 61436 (base 8) to base 10.

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 conversions 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 z System 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 radixcomplement, the sign-magnitude, and the diminished radix-complement representations. In practice, the radix-complement representation is called the twos complement representation, and the
diminished radix-complement representation is called the ones complement representation. 12 Two
of these representations are used in z System: the twos 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 well see in Chapter VIII.
With so many representations, you might wonder why the z System designers settled on twos
complement. The reason follows from the processors architecture: since virtually all computers
use the twos complement representation for address arithmetic, and because in z System 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.13

Why is it called twos complement? The name of the ones complement representation seems obvious: just complement each bit by subtracting it from 1 (or, change 0 to 1 and 1 to 0); but we dont get the twos complement by
subtracting each bit from 2! Well explain this oddity shortly.
z/Architecture provides 64-bit general registers, but for now our examples will use the 32-bit length.
Assembler Language Programming for IBM z System Servers

Version 1.00

2.6. Logical (Unsigned) Representation

To begin, we examine what is represented by the rightmost 32 bits of any nonnegative integer.
This
0
1
130
224 1
231 1
231
32
2 1
232+ 1

is represented
by:
X00000000
X00000001
X00000082
X00FFFFFF
X 7 FFFFFFF
X80000000
X FFFFFFFF
X100000001

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 numbers
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 representation 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 14), then the value X represented by the binary digits b31 b 30...b 1 b 0 is
X = b31231 + b30230 + ... + b222 + b121 + b020
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 signmagnitude, ones complement, and twos 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 twos complement representation is used for most integer arithmetic in
z System, 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 representation:
1. X DEADBEEF
2. X FFFFFFFF
3. X DEC0DED1

2.7. Twos Complement (Signed) Representation (*)

This section describes the mathematical justification for the twos complement representation.
You can skip to Section 2.8 where a simple recipe for calculating the twos complement of a
number is shown on page 29.
Most programs must deal with both positive and negative numbers. A single bit (usually, the leftmost) is used to represent the numbers sign. A 0 bit represents a + sign, and a 1 bit represents
a sign.
First, the twos complement representation of a 32-bit nonnegative binary integer Y satisfying the
inequalities
0 Y 2311 (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

Now, consider negative numbers. The twos complement representation of a negative integer Y
satisfying the inequalities
231 Y 1

(numbers within that range with a sign bit)

232 + Y.

is simply
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 2311.
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 (bi2i); 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 + b30230 + ... + b222 + b121 + b020,
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 representation, 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 twos complement representations is seen by examining the
above sum for the logical representation of X:
Xlogical = b31231 + b30230 + ... + b222 + b121 + b020.
If b31 is zero, the logical and twos complement representations yield the same value, and
Yarith = X logical. Now, suppose we are given the 32-bit twos complement representation of a
negative number Y arith , and we want to know the value those 32 bits would represent if we consider them as the logical representation of a number X logical. Since bit b31 is 1, indicating a negative 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 representation, 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 2321

and

231 Yarith 2311,

we have the following key relation between the logical and twos complement representations:
Xlogical = (Yarith + 232) (modulo 232).
That is, the bit pattern corresponding to the twos complement representation of any positive or negative 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 twos complement. In
the earliest computers it was customary to treat binary numbers as fractions: 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 relationship 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 twos complement.

Assembler Language Programming for IBM z System Servers

Version 1.00

Calculating the twos 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,
2311 + Y = (2311) |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 dont have to do
anything special with the sign bit!
This simple method lets us find the binary representation (in the twos complement representation) 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 tens-complement representation of the following values,
and indicate which are and are not validly representable.
(a) + 729, (b) 729, (c) 1, (d) + 9999, (e) 5000, (f) + 5000, (g) 9999.
2.7.3.(2) What is the decimal value of the 12-bit binary number 100000000001 in a signed twos
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 twos 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 twos complements is based on the observation that the representation of a negative number Y is simply 232 |Y|.
Two s-Complementation Recipe
Given a binary number Y, to find the twos 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 twos complement representation of 2.
Chapter I: Getting Started

(1) representation of +2:

(2) form ones complement:
(3) add one:

0000 0010
1111 1101
+
1
1111 1110

2. Find the twos complement representation of 75.

(1) representation of +75:
(2) form ones complement:
(3) add one:

0100 1011
1011 0100
+
1
1011 0101

This recipe also works in the opposite direction.

3. Find the twos complement representation of B11111110 (2).
(1) form ones complement:
(2) add one:

0000 0001
+
1
0000 0010

This is the binary representation of +2; thus the twos complement of the twos 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 twos complement representation of B00000000.
(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.14
5. Find the 8-bit twos complement representation of B10000000.
(1) form ones complement:
(2) add one:

0111 1111
+
1
1000 0000

In this case, the complement of the number is also the same as the original number. This particular 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 representable 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 following sections on twos complement arithmetic.
Some examples of numbers in the 32-bit arithmetic representation are shown in Table 4 on
page 31.

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

Version 1.00

Decimal Value
0
1
256
5000
+ 2147483647 ( + 231 1)
2147483648 ( 231)
2147483647 ( 231+ 1 )
5000
256
2
1

32-bit Twos
Complement
Representation
X00000000
X00000001
X00000100
X00001388
X 7 FFFFFFF
X80000000
X80000001
X FFFFEC78
X FFFFFF00
X FFFFFFFE
X FFFFFFFF

Table 4. Examples of twos 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 twos 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 twos complement representation:
1.
2.
3.
4.
5.

X0257
X 7 FFA
X8008
X E000
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)
c(B)
c(C)
c(D)

=
=
=
=

X 7 D40
X D000
X15A2
X800A

If they are the signed 16-bit twos complement binary representations of four decimal numbers,
determine their decimal values.
Chapter I: Getting Started

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 twos complement representation.
2.8.6.(3) Give the 32-bit twos complement representation (in either hexadecimal or binary) of
both the positive and negative values of the following decimal integers: (a) 10, (b) 729, (c)
1000000, (d) 1000000000, (e) 2147483648, (f) 65535, (g) 2147483647.
2.8.7.(3) Sometimes twos complementation is described by these steps:
Subtract 1
Complement all bits
Does this differ from the twos complementation recipe given on page 29? Create examples that
show how this form does or does not differ from that recipe.
2.8.8.(1) Give the 16-bit twos 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 twos complement binary representation of
each of the following decimal values:
1.
2.
3.
4.
5.
6.

+5
97
+ 65795
16777158
+ 16777219
78606

2.8.10.(1) + Assuming a 16-bit twos complement representation, give the signed decimal values
of these hexadecimal values:
1.
2.
3.
4.

X B00F
X FFF1
X 0 FFF
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 representations of +9 are
B0000 1001

and

B0000 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 twos complement representations of 9 are
B1111 0111

and

B1111 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:
Length
8 bits
16 bits
32 bits
64 bits

Representation of +1
X 0 1
X0001
X00000001
X0000000000000001

Assembler Language Programming for IBM z System Servers

Version 1.00

Representation of 1
X FF
X FFFF
X FFFFFFFF
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 following is slightly more general than if only z System is discussed. The rules for adding binary
digits are:
0
+0
0

0
+1
1

1
+0
1

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 twos 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 B0010 ( + 2) to itself, and then we add B0100 ( + 4) to itself.
0010
+0010
0100 (no overflow)

0100
+0100
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 its done:
Overflow Detection Recipe
If the carries into and out of the sign bit position disagree, arithmetic
overflow has occurred.
There are two kinds of binary addition: arithmetic and logical. They produce identical bit patterns, 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.
Chapter I: Getting Started

Exercises
2.10.1.(2) + Consider adding the 8-bit binary number X F5 to itself. There is no carry from
X 5 +X5=X A , but there is a carry from X F +X F=X 1E . Since the carry out of the loworder 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 twos complement of the number to be subtracted, the
second operand. That is, A B is calculated as A + ( B), where ( B) is the twos complement of
B. A few examples using 8-bit binary twos complement arithmetic will help illustrate addition
and subtraction.
While this prescription is essentially correct, there is a minor but important complication well
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

(carry lost)

0000 0101
+1111 1101
0000 0010 = 2

Example 2.
3-5:

0000 0011
-0000 0101

becomes

(no carry)

0000 0011
+1111 1011
1111 1110 = -2

Example 3.
25-(-17):

0001 1001
-1110 1111

becomes

(no carry)

0001 1001
+0001 0001
0010 1010 = 42

Example 4.
(-17)-25:

1110 1111
-0001 1001

becomes

(carry lost)

1110 1111
+1110 0111
1101 0110 = -42

Assembler Language Programming for IBM z System Servers

Version 1.00

Example 5.
-17-(-25):

1110 1111
-1110 0111

becomes

(carry lost)

1110 1111
+0001 1001
0000 1000 = 8

Example 6.
67-(-93):

0100 0011
-1010 0011

becomes

(no carry)

0100 0011
+0101 1101
1010 0000 = -96 (overflow)

Example 7.
(-93)-67:

1010 0011
-0100 0011

becomes

(carry lost)

1010 0011
+1011 1101
0110 0000 = 96 (overflow)

Example 8.
-128-(-93):

1000 0000
-1010 0011

becomes

(no carry)

1000 0000
+0101 1101
1101 1101 = -35

Example 9.
3-3:

0000 0011
-0000 0011

becomes

(carry lost)

0000 0011
+1111 1101
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 something. (This is the minor complication mentioned previously.)
Example 10.
1-(-128):

0000 0001
-1000 0000

becomes

(no carry)

0000 0001
+1000 0000
1000 0001 = -127 (no overflow found?)

Example 11.
-1-(-128):

1111 1111
-1000 0000

becomes

(carry lost)

1111 1111
+1000 0000
0111 1111 = +127 (overflow indicated?)
Chapter I: Getting Started

In each of these two last cases, the result seems to be arithmetically correct, but our original overflow indication is incorrect. This is because taking the twos complement of the maximum negative 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 37.

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.
2.
3.
4.
5.
6.

10 ( 10)
729 65535
2147483647 + 2
1000000000 + ( 2147483647)
0 ( + 0)
( 10) + 10

Do the arithmetic in the twos complement representation, indicating for each case (1) the presence 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 rightmost 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 determine (a) whether an arithmetic overflow occurs, and (b) whether there is a carry out of the
leftmost bit.
1.
2.
3.
4.
5.
6.

X 7 D26F071+X B40E99A4
X 7 D26F071 -X B40E99A4
X FFFFF39A+X FFFE4B06
X FFFFF39A -X FFFE4B06
X80000003+X0000007C
X80000003+X8000007C

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

Remember that the twos complement of a number (the twos 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.

Assembler Language Programming for IBM z System Servers

Version 1.00

Bit n of
Operand A

Carry bit Adder Carry bit

to Adder Positionfrom 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 operation! 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 operation. 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, compute the following 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.) (a) A + C; (b) D E; (c) Z + ( F); (d) ( E) C; (e) ( B) + A; (f) C Z; (g)
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 complement 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

2.13. A Circular View of Binary Arithmetic (*)

Well 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 twos 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 twos 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 examples 4 and 5 of Section 2.8 above.
Now, consider the numbers to be the signed 4-bit twos 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.

Assembler Language Programming for IBM z System Servers

Version 1.00

Experiment with this diagram; it reveals many properties of twos complement arithmetic.

Exercises
2.13.1.(3) + In many early editions of the System/360 Principles of Operation, the Subtract operation was described as follows: Subtraction is performed by adding the twos 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 satisfactory; 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 twos complement representation as though they were logical operands. For
32-bit operands, the logical representation X corresponding to an arithmetic signed integer x satisfies 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 highorder 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 representation. From the examples in Section 2.11, we see that 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. Well see examples 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 twos complement representations
of the following quantities: (a) 200, (b) 1023, (c) 1000, (d) 2047, (e) 1, (f) 1024, (g) 1023,
(h) 1024, (i) 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.)

Chapter I: Getting Started

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.)
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 (twos complement), and diminished radix-complement (ones complement) representations. 15 All 5-bit binary
numbers with positive and negative values would be represented as shown in the following table.
Binary
Digits
00000
00001
00010
00011
00100
00101
00110
00111
01000
01001
01010
01011
01100
01101
01110
01111
10000
10001
10010
10011
10100
10101
10110
10111
11000
11001
11010
11011
11100
11101
11110
11111

Logical
SignRepresentation Magnitude
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

Ones
Complement

Twos
Complement

+0
+1
+2
+3
+4
+5
+6
+7
+8
+9
+ 10
+ 11
+ 12
+ 13
+ 14
+ 15
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0

0
+1
+2
+3
+4
+5
+6
+7
+8
+9
+ 10
+ 11
+ 12
+ 13
+ 14
+ 15
16
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1

+0
+1
+2
+3
+4
+5
+6
+7
+8
+9
+ 10
+ 11
+ 12
+ 13
+ 14
+ 15
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

In the sign-magnitude and ones (diminished radix) complement representations, there are two
distinct representations for zero. In the twos (radix complement) representation, there is no representation 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 twos complement representation is not just an indicator: it
is numerically significant.

More formally, the representation in radix r of an n-bit negative number X is r n X in the twos complement representation, and (r n 1) X in the ones complement representation.
Assembler Language Programming for IBM z System Servers

Version 1.00

Representing signed numbers in a computer always involves tradeoffs: how should peculiar
cases like these be handled?

Exercises
2.15.1.(2) Suppose your computer uses the tens complement representation for integers. (This
representation was very widely used in mechanical desk calculators, and in many early computers.) Write the following values in tens-complement notation: (a) + 28, (b) 49, (c) + 527,
(d) 333, (e) 1234, (f) + 2469.
2.15.2.(3) Using the representations you calculated in Exercise 2.15.1, evaluate the following
using tens 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 complement) representation.

Terms and Definitions

bit
A binary digit, taking values 0 and 1.
hexadecimal
A base-16 representation. Its digits are 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F.
hex
See hexadecimal.
logical representation
An unsigned number representation.
arithmetic representation
A signed number representation.
sign-magnitude representation
The familiar signed representation of numbers with prefixed + or signs.
radix-complement representation
A signed representation where the numerically significant high-order digit contains sign information.
twos complement representation
A signed binary representation where the high-order bit contains sign information, and has
weight 2 n 1.
diminished radix-complement representation
A signed representation where negative numbers are represented by subtracting each digit
from (the radix minus 1).
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 represented in the number of digits provided.

Chapter I: Getting Started

Assembler Language Programming for IBM z System Servers

Version 1.00

Chapter II: z System

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

This chapters three sections introduce the main features of z System processors:
Section 3 describes basic structures memory organization and addressing, general purpose registers, 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: z System

3. Conceptual Structure of z System

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, arithmetic, 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

Arithmetic Control Inputoutput

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.
z System makes no special distinction between the arithmetic and control units, and the combination is often called the Central Processing Unit, or CPU.

Assembler Language Programming for IBM z System Servers

Version 1.00

Control

Central Processing
Inputoutput

Unit

Data
Data

Memory

Figure 5. Conceptual structure of z System

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 communicates 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.16 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
dont 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 contents of a byte does not affect the contents; the memory provides the CPU with a copy of the

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 wont.
Chapter II: z System

contents of a byte. Storing (or writing) a new bit pattern into a byte replaces the previous contents.
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.17 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.18 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

wordwordwordword
doubleworddoubleword
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 independent 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 operation, 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 operandits rightmost
bit corresponds to bit 7 of the byte at X 8EB .19
Bytes in memory contain only bit patterns. Whether the bit pattern is interpreted as an instruction, 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 z System can be thought of as a continuous string of bits. Does each
individual bit in memory have an address? Explain.

17
18

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

Version 1.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 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; 20
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, well understand why this picture
shows two 32-bit parts of a 64-bit general register.

Because the general registers are used for so many activities, they are sometimes called General Purpose Registers.
Chapter II: z System

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 z System 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.

Assembler Language Programming for IBM z System Servers

Version 1.00

64 bits

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 floatingpoint instruction using 128-bit operands will use a pair of floating-point registers.
We wont mention the floating-point registers until we discuss instructions for floating-point arithmetic. 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 register?
3.4.2.(3) Can you think of any reasons why the designers of System/360 and z System 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 z System 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; well see more about the others later.
Figure 12 illustrates these four parts of the PSW (and the System Flags). The IA is always in
the rightmost position; the positions of the other three arent significant.

System
I C
Flags
L C

Pro

Instruction

gram

Address

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 instructionsfor 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: z System

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 z System 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 arithmetic or for addressing by a program because they control various execution functions.
Well 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 z System family of processors has grown from its original System/360 capabilities.21 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 cant do. 22 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.
CPU
Central Processing Unit

21
22

This is quite an understatement.

If youre 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.
Assembler Language Programming for IBM z System Servers

Version 1.00

GR
General Register
FPR
Floating-Point Register
PSW
Program Status Word, containing information about the current state of a program.
CC
Condition Code, a 2-bit field in the PSW used to indicate the status or result of executing
certain instructions.
Instruction Length Code
Instruction Length Code, a 2-bit field in the PSW indicating the length in halfwords of the
currently executing instruction.
millicode
Internal instructions used by the CPU to perform operations too complex to be done costeffectively in hardware.
problem state
A state in which the CPU disallows the execution of certain privileged instructions.
supervisor state
A state in which the CPU allows the execution of all instructions.

Chapter II: z System

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 45, instructions executed by the computer reside in memory
along with the data to be processed. Instructions in z System 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 doesnt 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

Assembler Language Programming for IBM z System Servers

Version 1.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 confused 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 didnt intend the fetched bytes to be an instruction, its 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.
2.
3.
4.
5.

register-and-register (RR)
register-and-indexed-storage (RX)
register-and-storage (RS)
storage-and-immediate (SI)
storage-and-storage (SS)

Modern z System processors support over 30 instruction formats that well 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 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: z System

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

RX,

Instruction

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).23 The interpretation of this second byte therefore depends on the class to which the instruction belongs.
RR-type instructions are always one halfword long.
operation
code

Table 6. RR-type instruction

format

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

operation
code

addressing halfword

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
code

immediate
data

addressing halfword

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.

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 neednt worry.
Assembler Language Programming for IBM z System Servers

Version 1.00

SS-type instructions are always three halfwords long.

length
specification

operation
code

addressing halfword

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 64, 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 z System?
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 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
01xxxxxx
10xxxxxx
11xxxxxx

2-byte
4-byte
4-byte
6-byte

instructions
instructions
instructions
instructions

such
such
such
such

as
as
as
as

RR-type
RX-type
RS- and SI-type
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 * shows the relationship between the first 2 bits of the
opcode and the ILC:

Courtesy of Michael Stack.

Chapter II: z System

ILC
(decimal)

ILC
(binary)

Instruction
types

Opcode
bits 0-1

0
1
2
2
3

B 00
B 01
B 10
B 10
B 11

RR
RX
RS, SI
SS

B 00
B 01
B 10
B 11

Instruction length
Not available
One halfword
Two halfwords
Two halfwords
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 determine 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 instruction 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, deduce a simple formula that can be used to determine, for
any z System 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 contiguous.)
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 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 approximate,
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

Assembler Language Programming for IBM z System Servers

Version 1.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 ).
Second pair of bits

First pair
of bits

00
(RR)

Branching, status
switching

01
(RX)
10
(RS, SI)

Branching,
halfword fixedpoint
Branching,
shifting, status
switching

01
Word logical,
fixed-point
binary
Word logical,
fixed-point
binary

10
Long
hexadecimal
floating-point
Long
hexadecimal
floating-point

11
Short
hexadecimal
floating-point
Short
hexadecimal
floating-point

Fixed-point,
logical, I/O

Logical

Packed decimal

11
(SS)
Table 11. General instruction classifications

Since we will refer to instructions almost entirely using mnemonics

full names these details are only of minor interest.

short abbreviations for their

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 52 describes the basic mechanism of instruction sequencing. However, a more workable view requires understanding interruptions, sometimes
called interrupts. Well 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 predefined 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.

Chapter II: z System

FETCH DECODE EXECUTE

no
Any Interrupts?

yes
no

yes

Any other Load New PSWNote interruption cause,

interrupts?
from Memory
save Old PSW, status info

Figure 16. Instruction cycle with interruptions

The usual cycle of fetching, decoding, and executing will continue undisturbed so long as no interruption occurs. 24 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 information 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 interruptions. 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.
2.
3.
4.
5.
6.

Restart (operator action)

External (timer, clock comparator)
Machine Check 25 (equipment malfunction)
Input-Output (an I/O device has signaled a condition)
Program (exception condition during program execution)
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 sometimes called involuntary or asynchronous interrupts. The first four classes of interruption are involuntary. Except for the restart interruption, all the involuntary interruptions can be masked.

Figure 16 doesnt account for the possibility that an interruption can occur during the fetch or decode phases. In
almost all cases, this distinction is unimportant.
This interruption shouldnt be masked off because the CPU must save diagnostic information before the situation gets
worse.
Assembler Language Programming for IBM z System Servers

Version 1.00

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 executing 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 instruction could take.

4.6. Exceptions and Program Interruptions (*)

Programs can create a 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 instruction 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
that an instruction should be fetched from an odd memory address, no fetch occurs and an interruption 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 interruption are shown below with their associated Interruption 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 programs 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.

Chapter II: z System

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: fixedpoint and decimal overflow exceptions, and hexadecimal floating-point exponent underflow and
lost-significance exceptions. By setting an appropriate mask bit in the Program Mask to zero (see
Figure 12 on page 49), you can use the SPM instruction (described on page 235) 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 sometime 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 generate 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 PSW26 (sketched in
Figure 12 on page 49) was displayed as the result of a program interruption. What error condition 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?

The modern z/Architecture PSW is quite different!

Assembler Language Programming for IBM z System Servers

Version 1.00

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 processors internal bit patterns representing
instructions and data types. Because its 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.
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 language.27

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 well see in Section 20), 64-bit registers, and a vast variety of new instructions. Many of
the instructions well see didnt exist in System/360. Each generation of processors has introduced
small and large enhancements; while well start with basic instructions that have been used for
many years, well 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 doesnt apply as uniformly to specialized programs that use systemspecific features, but most such features are typically managed by the operating system.

Terms and Definitions

fetch
The CPU action of bringing halfwords from memory into the Instruction Register to be
interpreted as an instruction.
IR
Instruction Register, a conceptual internal register in the CPU into which fetched instructions
are placed.
decode
The CPU action of analyzing the contents of the IR to determine the validity and type of
instruction.
execute
The CPUs action of performing the operation requested by the instruction in the IR.

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: z System

operation code
The portion of an instruction specifying the actions to be performed by the CPU when it
executes the instruction. Often called opcode.
ILC
Instruction Length Code, a 2-bit field in the PSW containing the number of halfwords in the
current 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 interruption.
interruption
A process taking control away from the currently executing instruction stream, saving information about the interrupted program, and giving control to the Operating System Supervisor.
IC
Interruption Code, a value indicating the cause of an interruption.
machine language
The internal representations of instructions and data processed by a computer.
PM
Program Mask, a 4-bit field in the PSW used to control whether or not certain types of
exception condition should cause an interruption, or take a predefined default action.

Assembler Language Programming for IBM z System Servers

Version 1.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 z System 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.28
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 z System, 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 z System 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 generation.

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: z System

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 bits12 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.29 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 were assuming for now), only the rightmost 24 bits of the Effective Address are
used.

The base register specification digit was sometimes called the base register address, but this is misleading because
the base registers arent addressable like bytes in memory.
Assembler Language Programming for IBM z System Servers

Version 1.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
+0011 1110 1001 0000 1010 1111
0011 1110 1001 0011 1000 0100

0002D5 (displacement)
3E90AF (base)
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) = X12001038
c(GR1) = X0902A020
c(GR2) = X001AAEA4
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 Effective 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 54) 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.

Chapter II: z System

8 bits
4 bits 4 bits
16 bits

opcode
operand index

registerregister
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 specification 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 actually 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 computation?
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?

Assembler Language Programming for IBM z System Servers

Version 1.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
+0011
0011
+1101
0001

0000
0100
0100
1100
0001

0000
0101
0101
1011
0001

0100
0110
1010
1010
0101

0110
0111
1110
1001
0111

1000
1000
0000
1000
1000

000468
345678
345AE0
DCBA98
111578

(displacement)
(base, from GR7)
(index, from GR10)
(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
+0011 0100 0101 0110 0111 1000
0011 0100 0101 1010 1110 0000

000468 (displacement)
345678 (base)
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
+0011
0011

0000
0000
0000
0100
0100

0000
0000
0000
0101
0101

0100
0000
0100
0110
1010

0110
0000
0110
0111
1110

1000
0000
1000
1000
0000

000468
000000
000468
345678
345AE0

(displacement)
(base)
(index)
(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 Effective 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.30

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)
C(GR1)
C(GR2)
C(GR3)

=
=
=
=

12001028
8902A020
4F1AAEA4
FFFFFFF8

C(GR4)
C(GR5)
C(GR6)
C(GR7)

=
=
=
=

8888000E
12345678
0FDE3B72
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.

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: z System

C(GR0)
C(GR1)
C(GR2)
C(GR3)

=
=
=
=

00000044
000902AE
A20710FC
FFFFFFFF

C(GR4)
C(GR5)
C(GR6)
C(GR7)

=
=
=
=

41800000
00010000
00FFFF00
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. 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 (lowestaddressed) 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.31 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 F F F , so you will almost always use a base register to refer to operands in memory.
(Well see in Chapter VI, Section 20 that instructions with signed 20-bit displacements make this
4K-byte limitation much less severe.)
You cant put your program into those first 4096 bytes32 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 Assemblers 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

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 relaxation of the alignment requirement was called the Byte-Oriented Operand Feature; it soon was known as the
BOOF.
Unless youre writing your own operating system!
Assembler Language Programming for IBM z System Servers

Version 1.00

addressing halfword that can be used to address it. (1) X 02ABCD , (2) X 000A4D , (3)
X 001139 , (4) X 88888E , (5) X 02A010 .
5.5.2.(3) + Suppose the contents of the general registers are as follows:
C(GR0)
C(GR1)
C(GR2)
C(GR3)
C(GR4)
C(GR5)
C(GR6)
C(GR7)

=
=
=
=
=
=
=
=

00010A20
42319B7C
91F0F002
1002340A
00FF00FF
D907C401
12345678
992B42A3

C(GR8)
C(GR9)
C(GR10)
C(GR11)
C(GR12)
C(GR13)
C(GR14)
C(GR15)

=
=
=
=
=
=
=
=

8031B244
00000010
723B94C1
E931AB7F
00000E38
6B005000
80000000
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 F F F F F F , (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 accompanying 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
65 (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 basedisplacement 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 55).
(1) X D2078F1D57C4 , (2) X DCFFDCFF7000 , (3) X F26337390050 , (4)
X D58DFE4FC016 .

5.6. Address Translation and Virtual Memory (*)

All models of z System 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 translation takes your programs 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 cant 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 arent real.

Chapter II: z System

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.
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 protected 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 z System?
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 z System 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

Assembler Language Programming for IBM z System Servers

Version 1.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 z System addressing.
Effective Address
The address calculated from an addressing halfword, possibly with indexing.
EAR (Effective Address Register)
A (conceptual) internal register used to hold Effective Addresses.
base register specification digit
The first 4 bits of an addressing halfword.
base register
A general register used at execution time to form an Effective Address.
base address
The execution-time contents of a base 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.
index
The contents of an index register.
indexing
Computation of an Effective Address by adding a displacement to the contents of a base register and an index register.
displacement
An unsigned 12-bit integer field in an addressing halfword used in generating Effective
Addresses.33
addressability
A base register and a displacement provide an Effective Address allowing valid reference to a
byte in memory.
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.
address translation (Dynamic Address Translation, DAT)
The procedure used by the CPU to convert virtual addresses into real addresses.

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

Assembler Language Programming for IBM z System Servers

Version 1.00

Chapter III: Assembler Language Programs

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

We have seen how the CPU executes instructions and evaluates addresses; now well see how we
write Assembler Language programs.
Section 6 describes typical steps involved in preparing, assembling, linking, and executing programs written in Assembler Language.
Sections 7 and 8 examine the components from which machine, assembler, and macro instruction 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 z System.

Chapter III: Assembler Language Programs

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 conventions 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

Assembler Language Programming for IBM z System Servers

Version 1.00

The Assembler reads the statements of your Assembler Language program, processes
them possibly 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 containing object code. Usually you will want a program listing showing your
source program and the generated object code, with additional information about the Assemblers
processing and indications of errors it may have detected.
The Assembler converts the program from a form convenient for you (statements) to a form convenient for the processor (binary data and instructions), its machine language.

6.1.2. Linking
The Linker 34 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.35 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 well 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 36 and when it is finished it
returns control to the Supervisor.

Well use Linker to mean any program (such as the Binder and Linkage Editor) that combines object module files
into executable files like load modules.
The output of a Linker has many many different names and forms, depending on the operating system and the
system Linker. For example, on z System 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. Well
use load module to mean a data set or file ready to be loaded directly into memory for execution.
Which may not always be what you intended!
Chapter III: Assembler Language Programs

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 macroinstruction 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 registers 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. Macroinstructions are a very powerful and useful feature of the Assembler Language.

Assembler Language Programming for IBM z System Servers

Version 1.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.37
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 continuation 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.38 This is illustrated in Figure 26. These conventionscolumn 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 characters 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 information. 39
A comment statement is identified by an asterisk (*) in column 1. Any information may appear in
columns 2 through 71. Figure 27 has examples of comment statements:

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.
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.
Even though IBM cards have 80 columns, early computers like the IBM 704 and 709 couldnt 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

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
on this next line starts in column 16.

X column 72

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

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.40 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.

Its better to call this the remarks field, to avoid confusion with comment statements.
Assembler Language Programming for IBM z System Servers

Version 1.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 sometimes called the mnemonic or operation or operation mnemonic. 41
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 influence the processing of the statement unless this field extends into column 72, indicating a continuation 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

NameFieldEntry Operation Operands Remarks
usually
optional

required

usually
required

always
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 customary 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 characters 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 programs 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 45 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 illustrates a machine instruction statement in which entries appear in all four fields.

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

LOAD

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.42
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 43
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
Return

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.
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.)
Assembler Language Programming for IBM z System Servers

Version 1.00

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. Its too easy to start thinking of all name-field
symbols as labels when theyre actually used for other purposes.

Exercises
6.3.1.(1) Suppose a program contains the machine instruction statement shown in Figure 30.
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 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
1. a START statement,
2. the statements of your program, and
3. an END statement.

Chapter III: Assembler Language Programs

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 well
write our sample programs this way.
The Assembler allows no symbol as the name-field entry in an END statement. Assembler Language programs, unlike programs in many high-level languages, must not try to terminate execution 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 statement 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
cant set the initial location or assumed origin value. Well discuss control sections and the
CSECT instruction thoroughly in Chapter X, Section 38.

6.5. A Sample Program

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

Assembler Language Programming for IBM z System Servers

Version 1.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 Assembler, Linker, and Program Loader, and how to pass your programs 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 computer 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 executed; 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 84.)
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: well 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 executing 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

6.6. Basic Macro Instructions

For our sample programs, we need only very simple methods of reading 80-character cardimage 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 theyre
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 1001.

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
z System. The Assembler determines the needed base and displacement so that correct Effective 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 programs statements, as distinct from the
time when the machine language instructions created from your Assembler Language
program are executed by the processor.

Assembler Language Programming for IBM z System Servers

Version 1.00

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.
statement field
One of the four fields of an Assembler Language statement (other than a comment statement). They are the name, operation, operand, and the remarks fields. Which fields are
required and/or optional depends on the specific statement.
operand
(1) Something operated on by an instruction. (2) A field in a machine instruction statement.
object module
The machine language information created by the Assembler, used as input to the Linker.
object code
The machine language contents of an object module.
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.
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.
relocation
A procedure used by the Linker and the Program Loader to ensure that addresses in your
loaded program are correct and usable.
Program Loader
The component of the Operating System that brings load modules into memory, makes final
relocations, and transfers control to your program.
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.
origin
A starting value assigned by you (or by the Assembler) needed to calculate offsets and displacements in your program. Because most programs are relocated, its rarely necessary to
specify an origin.
mnemonic
A convenient shorthand for the name of an instruction. For example, the Branch and Save
instruction has mnemonic BASR.
macro instruction
A powerful means to encapsulate groups of statements under a single name, and then generate them (with possible programmer-determined modifications) by using the macroinstruction name as an operation field entry.

Chapter III: Assembler Language Programs

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.
code
An informal term for groups of Assembler Language statements.

Programming Problems
Problem 6.1.(2) + Write, assemble, link, and execute a short program (like the one in Figure 33
on page 83) 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!

Assembler Language Programming for IBM z System Servers

Version 1.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 four44 basic types of self-defining term: decimal, hexadecimal, binary, and character. The
value of each is treated by the Assembler as a 32-bit twos 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. X123456, X FACED , and X001B7 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 X00000000 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. B110010, B0001, and B1111111100001100 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,

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 well meet it again in Chapter VI, Section 26.4.
Chapter III: Assembler Language Programs

B00000000000000001000000000000000000000000 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 contains 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 apostrophe. Thus, C A , C . . . , and C AB 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 doesnt 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 characters , giving a term with value X007D7D7D ), and and C&&&& (for the three characters
&&, giving a term with value X00507D50 ). A pair of apostrophes is entered as two characters,
and should not be confused with the quotation mark (), which is a single character.45
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)
(2)
(3)
(4)
(5)
(6)
(7)

00000012345
B10101010101010101
X0000B4DAD
X B4DAD0000
+65535
B000000000001111000011110000111101
B101011010001111000011110000111101

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?

Unfortunately, people sometimes call the apostrophe or single quote a quotation mark or single quotation mark.
Calling a quotation mark a double quote or doesnt help either, because it might be understood to mean a pair
of apostrophes.
Assembler Language Programming for IBM z System Servers

Version 1.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 4 1 , or X 7 4 , or X A1 , or even X C1 .
In z System the conventional character code is called the Extended Binary Coded Decimal Interchange Code, or EBCDIC for short. 46 Each character is represented internally by an eight-bit
number two hexadecimal digitsas indicated in Table 13. The internal bit patterns that represent
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
.

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 6 1 , the binary self-defining term B1100001, 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 5 0 . Which
type of term you choose is largely a matter of context; in some places, certain types will be more
natural than others.

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 z System.
Chapter III: Assembler Language Programs

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 X000000C1 , and the value of C ABC is X00C1C2C3 .47
The characters shown in Table 13 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 4 0 .

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)
(2)
(3)
(4)
(5)
(6)

C # @$
C
C AB
C RUD
C 1 2
C 12

(one leading blank)

(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 7 5 , (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 characters in Table 13 on page 89.
7.2.4.(2) + Give (in hexadecimal) the value of each of the following self-defining terms:
(1) C , (2) 1000, (3) B01000, (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) X405C , (5) X F9F9F9F9 ,
(6) B110001011101100111010001.
7.2.6.(1) What EBCDIC character would be represented by the bit pattern in the byte illustrated in Figure 6 on page 45?
7.2.7.(1) Show the hexadecimal value of each of the following self-defining terms:
(a)
(b)
(c)
(d)

B110010110000010111010110
C A&&B
54721
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 twos complement representation, give its value.
4. Write them as two EBCDIC characters.
7.2.9.(1) Give the hexadecimal value of these self-defining terms:

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.)
Assembler Language Programming for IBM z System Servers

Version 1.00

1. B110010111000010111011001
2. C R&&Z
3. 51401
7.2.10.(2) + Give the value in hexadecimal of these self-defining terms:
(a) B01110101100010
(b) C +
(c) 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 wont 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 well see in
Chapter X, Section 38), while internal symbols are used only during the assembly, and do not
appear in the object module. 48
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 arent; the differences are described in Section 7.7 on page 96.
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.49 These special characters 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
#235
James
$746295

Agent086
O0@H
KQED
Wonka

A1B2D3C4
ApoPlexy
Prurient
ZYZYGY99

_The_End
The_Utter_Final_Bitter_End
EtCetera
Close_Files

Internal symbols are added to the object module if you specify the Assemblers 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.
If theres 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 representations. Other characters usable in Assembler Language symbols those in Table 13 always have the same EBCDIC
representations.
Chapter III: Assembler Language Programs

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.50 Of these, the value and
length attributes are most important; the rest will be described as needed. The length attribute is
especially useful, and well see how its 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 attributes, 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 relocation 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.51
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 interesting. 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 80, 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

F 1 0

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.

Conditional assembly supports additional attributes: Assembler, Count, Number, Defined, Opcode, and Program.
The Assembler, Opcode, and Type attributes have nonnumeric values.
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 95. 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.
Assembler Language Programming for IBM z System Servers

Version 1.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 discarded when the assembly is complete.52

Exercises
7.3.1.(2) + Which of the following are valid symbols? If you think a symbol is invalid, explain
why.
(1)
(2)
(3)
(4)
(5)
(6)
(7)
(8)
(9)

SuperBOY
Captain Major
KillerWhale
Send400$Soon
#@$!
4Hundred$Sent
?
(Eight)
@9AM

7.3.2.(2) Some Assemblers (for processors other than z System) allow you to define a symbol
as a string of alphanumeric characters at least one of which must be a letter (it neednt 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 Assemblers task of converting a program from Assembler Language 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 doesnt know where the program will eventually be placed in memory, so it does
the next best thing:

This information can be saved in a SYSADATA side file when you specify the Assemblers ADATA option.
Chapter III: Assembler Language Programs

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 programs 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; well introduce them in Section 12.2 on page 149.
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 Assemblers 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 Assemblers assumed assembly-time starting location and the
Supervisors assigned execution-time starting address. This difference is handled by the Program
Loader when it relocates the program just before execution, so we dont have to worry about this
at assembly time. 53
To assign locations to the various parts of your program as it is assembled, the Assembler maintains 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
81); 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 Assemblers Location Counter and the
C P U 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 CPUs 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.

Exercises

The Assembler puts the assumed origin into the object module to help the Linker adjust addresses correctly.
Assembler Language Programming for IBM z System Servers

Version 1.00

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
BASR
BEGIN
L
A
ST
DUMMY
DS
N
DC
ONE
DC

X5000
6,0
2,N
2,ONE
2,N
XL22
F 8
F 1

0
2
4
4
4
22
4
4

bytes
bytes
bytes
bytes
bytes
bytes
bytes
bytes

generated
generated
generated
generated
generated
generated
generated
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 statement. When the Assembler encounters such a symbol, it enters it into a Symbol Table containing
the programs 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 doesnt 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 Assemblers 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 92) is read by the Assembler, the value of the LC is X0007B6 . Then the
symbol GETCONST would appear in the Symbol Table with value X0007B6 ; it would be relocatable; 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 instruction, so that its value will then be X0007BA .
Similarly, if the sample statement named TEN (on page 92) was encountered when the LC value
was X012D88 , then the value of the symbol TEN would be X012D88 ; it would be marked as
relocatable; and its length attribute would be 4. The LC value after incrementing would be
X012D8C .
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
ABS425

EQU

425

Chapter III: Assembler Language Programs

defines the symbol ABS425 by assigning a value of 425 (X000001A9 ), 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 91 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 languages 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 doesnt 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 were describing!54

Some of the differences in the meanings of symbols in high-level languages and Assembler Language are shown in Table 14.
Assembler Language
Used only at assembly time
Names of places in a program
Contents of memory has a value
The name has a location value used by the
Assembler to lay out and organize the program

High-Level Languages
Can be thought of as existing at execution
time
Contain execution-time values
Variable has a value
The name is thought of as naming the value of
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 175.

Terms and Definitions

The conditional assembly language does have variable symbols, but that topic is beyond what were discussing now.
Assembler Language Programming for IBM z System Servers

Version 1.00

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.
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.
EBCDIC
Extended Binary Code Decimal Interchange Code. Used to assign numeric values to characters. 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 89 are invariant across EBCDIC encodings, except for the characters $,
@, and #.
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 well see in Section 8.3).
defined symbol
A symbol is defined when the Assembler assigns values to its value, relocation, and length
attributes.
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.)
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 executiontime addresses to parts of a program.

Chapter III: Assembler Language Programs

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 separated 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 operators.

8.1. Terms and Operators

The basic elements of an expression are terms. They can be any of the following items:

a
a
a
a
a

self-defining term
symbol
Location Counter reference
literal
Symbol Attribute reference
Length
Integer
Scale

We will discuss Integer and Scale attributes later; while they arent used frequently, they can be
very helpful in certain situations.

Assembler Language Programming for IBM z System Servers

Version 1.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 Assemblers 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

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, multiplication, 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 Assembler 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:

X12+C . -B0001010001+7
Parentheses may be used, as in ordinary mathematical use (and as in familiar procedural languages) to indicate groupings. In evaluating expressions, an expression in parentheses is treated as
a term. Thus
(A+2)*(X4780-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 succession, or an addition or subtraction operator followed by a multiplication or division operator.
For example:
*+2
-A, +A
A++B, A--B,
A/+B, A/-B,
A+/B, A-/B,
A**B, A*/B,

A+-B,
A*+B,
A+*B,
A/*B,

A-+B
A*-B
A-*B
A//B

valid because * is a Location Counter reference

are valid uses of unary + and are valid (second + and second - are unary operators)
are valid (+ and - are unary operators)
are invalid
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

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 X12+C . -B0001010001+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.
b.
c.
d.
e.

A+-+-B
A*--B
A-*-B
A---B
--A-++B

8.3. Evaluating Assembly-Time Expressions (*)

The rules for evaluating expressions are familiar, with one or two minor exceptions, so its no
surprise that the Assembler evaluates 2+3 as 5.
Remember: we are describing the Assemblers evaluation of assembly-time expressions involving
the values of assembly-time symbols and other terms. This is entirely different from most highlevel 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 dont try to grasp everything on a first
reading. The examples on page 102 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 twos complement arithmetic. The resulting value is used in computing the rest of the expression. Thus in
(X100+2*(ABS425-420))+1
where ABS425 has value 425 (as defined on page 95), the subexpression (ABS425-420) would be
evaluated first. The value of the whole expression is X0000010B , 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 (X100+(2*(5)))+1 and not as
((X100+ 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 priority. 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 highorder (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 evaluating 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.

100

Assembler Language Programming for IBM z System Servers

Version 1.00

8. Negative quantities are carried in twos complement representation.

9. When the expression has been completely evaluated, the result is in 32-bit twos complement
form.
10. The relocation attribute of the result is found as follows; assume that the symbol A is relocatable:
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 relocatable expression. (Some later examples will show how complex relocatability can happen,
so dont 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
A+A, A-A, A*A, A/A

is
absolute

R+A, R-A, A+R

simply relocatable

R+R, A-R

complexly relocatable

RA, AR, 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. Well 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 100 states that the Assembler always discards remainders in evaluating
expressions. Does this mean that a program cannot compute a remainder? Explain.

Chapter III: Assembler Language Programs

101

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?

8.4. Examples
For these examples, we assume that

ABS425 is an absolute symbol of value 425 (or X000001A9 ),

the value of the Location Counter is X00011D46 ,
REL1 is a relocatable symbol of value X00010A20 ,
REL2 is a relocatable symbol of value X00012345 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 X00000002.
2. 16*16*16*16*16*16 is an absolute expression of value X01000000.
3. 6-ABS425 has value X FFFFFE5D , and is absolute.
4. (REL2-REL1)/(ABS425-B011111) is an absolute expression of value X00000010.
5. REL2+C -+*+L REL2-* is a relocatable expression of value X000123AB .
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 relocatable, and have value X00013C6A .)
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 X200.
9. *+6 is a relocatable expression of value X00011D4C .

10. (REL2-*)*L REL2 is an absolute expression of value X000023FA . Note the two distinct uses of
the asterisk!
The example of a machine instruction statement in Figure 30 on page 80 could have been written
LOAD

C 4 5 -(7X 2 A36 ) + ABS425B11111-235,18/(Q-Q)+3

though the gain in clarity is not obvious. More reasonable usage is illustrated in the following
statements.
*
R7
R3
LOAD

EXAMPLE 8_4_1
EQU 7
EQU 3
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 statement 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.)
*
ZORCH
ZILCH
LOAD

EXAMPLE 8_4_2
EQU 3
EQU 7
LR
ZILCH,ZORCH

*
R7
R3
LOAD

EXAMPLE 8_4_3
EQU 3
EQU 7
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

102

Assembler Language Programming for IBM z System Servers

Version 1.00

need a symbol NBits whose value is the number of bits in the same table. We could define the
symbols in the following way.
*
NWords
BitsWd
NBits

Example 8_4_4
EQU 75
EQU 32
EQU NWords*BitsWd

EQU with expressions

Table has 75 word entries
Number of bits per word
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
466
46A
46C
470

474

Statement
A
L
BALR
B
ST
C
SLL
USING
R6
EQU
X
DS

4,B+X 1C
R6,0
4,C-A+X-2*(R6/2)
5,2*C - -C A+2
B-2,R6-2
9
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 102. Determine the value and
relocation attributes of the following expressions.
(1)
(2)
(3)
(4)
(5)
(6)

REL1+C 2 / 2
REL1-REL2+ABS425
C 4 5 -(7*X 2 A36 ) + ABS425*B11111-235
(8/(REL2-REL1)/X107C)+3
ABS425/((REL2-REL1)/X C701+3)
*+ABS425*(*-REL1-4900)

8.4.4.(2) Assuming that the symbols REL1, REL2, and ABS425 have the attributes defined on page
102, determine the validity of each of the following expressions. Explain why you think any
expression is invalid.
(1)
(2)
(3)
(4)
(5)
(6)
(7)
(8)

-2+ABS425
((REL1))*2-2*((REL1))
REL1+C7592*B10110+ABS425
B10221+REL2
ABS425*74239661-2
+X1875
-*+REL2
**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 X00172B9E and X00173AA6 respectively. Determine the
value and relocation attributes of the following expressions.
(1)
(2)
(3)
(4)
(5)

B-A
A+C .
(A+X00FFF ) -(B-B1101011100001)
(B-A)/10
B+C B / ( B+B101-B)

Chapter III: Assembler Language Programs

103

8.4.6.(3) + The symbols SAM and JOE are simply relocatable with the same relocation attribute,
and have values X00174D0A and X0016FB63 respectively. The symbol BOB is absolute and has
value X000003E8 . First, determine the validity of each of the following expressions. Then
determine the value and relocation of each of the valid expressions.
(1)
(2)
(3)
(4)
(5)
(6)

2*BOB+2*SAM-2*JOE
BOB+(SAM+BOB)-(JOE+BOB)
2*(SAM-JOE)/5
SAM-(B10000*(X0010*(BOB-C H ) ) )
(2*SAM-2*JOE)/5
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 102?
8.4.8.(1) The symbols A and B are relocatable, and have values X00172B9E and X00173AA6
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.

104

Assembler Language Programming for IBM z System Servers

Version 1.00

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,
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 102) 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)
(2)
(3)
(4)
(5)
(6)
(7)
(8)
(9)

A+B(5)
A+(B+(5))
A+C ( ( C ) )
A(C , C )
7+(X BAD / B01101)
(C ( ) ( C ) , , ( C ( , ) ) )
0-0(0,0)
0/0(,0*0)
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.55
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 factorfactor

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:

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

105

primary

term ( expr )
5. Finally, a term in an expression is one of the following:
term

Symbol Self
Location Literal Symbol
Defining Counter
Attribute
Term
Reference
Reference

L I S
We havent 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

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.
operator
One of * (meaning multiplication), / (meaning division), + (meaning addition), or
(meaning subtraction). (The Assembler does not support **, which is sometimes used to
mean exponentiation.)
term
A symbol, self-defining term, Location Counter reference, literal, or symbol attribute reference.
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.
Symbol Attribute Reference
A term whose value is that of a symbols attribute. The three most important types of
Symbol Attribute Reference are length, scale, and integer.
Length Attribute Reference
A term whose value is the length attribute of a symbol.
simple relocatability
A property of a symbol or expression whose value changes by the same amount as a change
to the programs assumed origin.
complex relocatability
A property of a symbol or expression whose relocation attribute is neither absolute or simply
relocatable.

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 dont work? (Some test cases you might
try are L 2 , L ( *-10), L *, L ABS425, L425, L=F 1 , and L L *.)

106

Assembler Language Programming for IBM z System Servers

Version 1.00

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:
A
B
C1
C2
C3

Equ
Equ
Equ
Equ
Equ

5
3
L A*B
A*L B
L ( A*B)

Try some similar expressions and see what happens.

Chapter III: Assembler Language Programs

107

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 dont 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 abbreviations for Operation Code or Opcode, and Mnemonic.
Op
04
06
0D
0F
11
13
15
17
19
1B
1D
1F

Mnem
SPM
BCTR
BASR
CLCL
LNR
LCR
CLR
XR
CR
SR
DR
SLR

Instruction
Set Program Mask
Branch On Count
Branch And Save
Compare Logical Long
Load Negative
Load Complement
Compare Logical
Exclusive O R
Compare
Subtract
Divide
Subtract Logical

Op
05
07
0E
10
12
14
16
18
1A
1C
1E

Mnem
BALR
BCR
MVCL
LPR
LTR
NR
OR
LR
AR
MR
ALR

Table 16. Typical RR-type instructions

108

Assembler Language Programming for IBM z System Servers

Version 1.00

Instruction
Branch And Link
Branch On Condition
Move Long
Load Positive
Load And Test
AND
OR
Load
Add
Multiply
Add Logical

1. Not all of the 64 available bit combinations between X 0 0 and X 3F are used as actual operation codes. For example, IBM has promised not to use X 0 0 as an operation code. 56
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.57 (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 80, 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

X 7 , B 1 1

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 54. Table 17 shows the positions of the register specification digits.
opcode

Table 17. RR-type instruction

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 shows that the operation code corresponding to
the mnemonic LR is X 1 8 , so the two-byte instruction generated by the Assembler would be
X1873.
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.

X 0 0 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 X0000
halfword in a program to force it to stop at an exact position so the contents of registers and memory can be verified.) Also, programs like debuggers sometimes use X 0 0 as breakpoints to halt instruction tracing at a specified
place.
Some instructions have only one or even no explicit operands!
Chapter III: Assembler Language Programs

109

LR
AR
SR

0,2
0,14
0,9

Copy contents of GR2 to GR0

Add contents of GR14 to GR0
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?
(a) 0, (b) B1101, (c) X 1 1 , (d) 4*(X F2 C0)/5+X E , (e) 4*(X F2 C0)/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 4 0 and X 7F are used as actual operation
codes. Again, you neednt try to remember them here.
Op
40
42
44
46
48
4A
4C
4E
50
55
57
59
5B
5D
5F

Mnem
STH
STC
EX
BCT
LH
AH
MH
CVD
ST
CL
X
C
S
D
SL

Instruction
Store Halfword
Store Character
Execute
Branch On Count
Load Halfword
Add Halfword
Multiply Halfword
Convert To Decimal
Store
Compare Logical
Exclusive O R
Compare
Subtract
Divide
Subtract Logical

Op
41
43
45
47
49
4B
4D
4F
54
56
58
5A
5C
5E

Mnem
LA
IC
BAL
BC
CH
SH
BAS
CVB
N
O
L
A
M
AL

Instruction
Load Address
Insert Character
Branch And Link
Branch On Condition
Compare Halfword
Subtract Halfword
Branch And Save
Convert To Binary
AND
OR
Load
Add
Multiply
Add 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 54. We now look at the
parts of the instruction in Table 19 and describe Assembler Language techniques for specifying
them.
opcode

Table 19. RX-type instruction

110

Assembler Language Programming for IBM z System Servers

Version 1.00

As noted when we reviewed addressing in Section 5.3 on page 65, 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 Assembler determines the base and displacement. (Section 10 will show you how its 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: 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 104. The
instructions in examples 4, 5, and 6 of Section 5.4 on page 67 could be written as shown in Figure
34, where the assembled form is on the left, and the Assembler Language machine instruction
statement is in the center; the displacements have the same value in each instruction.
430A7468
43007468
43070468

IC
IC
IC

0,1128(10,7)
0,1128(0,7)
0,1128(7,0)

D2=1128, X2=10, B2=7

D2=1128, X2=0, B2=7
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.
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 well see!).
Explicit Address

Implied Address

Not Indexed

D 2(,B2)

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

111

than or equal to 4095=X FFF .58 The not-indexed form of 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
L
LA

0,ANSWER
0,16
2,25*40

Operand forms are R1,S2

Operand forms are R1,S2
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. 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 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
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 computes 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, 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

112

In Section 20 we will introduce instructions with signed 20-bit displacements.

Assembler Language Programming for IBM z System Servers

Version 1.00

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.
1.
2.
3.
4.
5.
6.

B+X 1C
C-A+B-2(N/2)
2*C - -C A+2(N+N)
B-A((B-A)/2,((B-A)*2))
C A+A(C , -99)
N+N(,N)

9.5.3.(2) Assume that each of the operands in Exercise 8.5.1 on page 105 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
90
92
86

Mnem Type
STM
RS
MVI
SI
BXH
RS

Instruction
Store Multiple
Move Immediate
Branch On Index High

Op
91
94
95

Mnem Type
TM
SI
NI
SI
CLI
SI

87
97
98
8A
8C
8E
BD

BXLE
XI
LM
SRA
SRDL
SRDA
CLM

RS
SI
RS
RS
RS
RS
RS

96
88
89
8B
8D
8F
BE

OI
SRL
SLL
SLA
SLDL
SLDA
STCM

ICM

Branch On Index Low or Equal

Exclusive OR Immediate
Load Multiple
Shift Right Single
Shift Right Double Logical
Shift Right Double
Compare Logical Characters
Under Mask
Insert Characters Under Mask

SI
RS
RS
RS
RS
RS
RS

Instruction
Test Under Mask
AND Immediate
Compare Logical Immediate
O R Immediate
Shift Right Single Logical
Shift Left Single Logical
Shift Left Single
Shift Left Double Logical
Shift Left Double
Store 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

Table 22. Typical RS-type instruction

Chapter III: Assembler Language Programs

113

The operand fields of Assembler Language instructions specifying RS-type instructions are shown
in Table 23. 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.
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
SLDL
LM
STM
BXLE

11,2
6,N
14,12,12(13)
14,12,SaveArea+12
4,1,Loop_3

Explicit
Implied
Explicit
Implied
Implied

address
address
address
address
address

(RS-1
(RS-1
(RS-2
(RS-2
(RS-2

form)
form)
form)
form)
form)

SI-type instructions are different. The I2 operand is contained in the second byte of the instruction, as in this figure:
opcode

Table 24. Typical SI-type instruction

Table 25 gives the operand fields of Assembler Language statements involving SI-type
instructions:
Explicit Address

Implied Address

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
CLI

0(6),C *
Buffer,C 0

Explicit S1 address
Implied S1 address

Exercises
9.7.1.(2) The following are operand fields 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 components of
the instruction to which each expression applies. State which expressions specify explicit
addresses and which specify implied addresses.
(a)
(b)
(c)
(d)
(e)
(f)

114

1(2),3
4,5(6)
7,8,9
10,11
14,15(16)
100,101

Assembler Language Programming for IBM z System Servers

Version 1.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
D1
D2
D3
D4
D5
D6
D7
DC
DD
DE
DF

Mnem
MVN
MVC
MVZ
NC
CLC
OC
XC
TR
TRT
ED
EDMK

Len
1
1
1
1
1
1
1
1
1
1
1

Instruction
Move Numeric
Move
Move Zone
AND
Compare Logical
OR
Exclusive O R
Translate
Translate And Test
Edit
Edit And Mark

Op
F0
F1
F2
F3

Mnem
SRP
MVO
PACK
UNPK

F8
F9
FA
FB
FC
FD

ZAP
CP
AP
SP
MP
DP

Len
2
2
2
2
2
2
2
2
2
2

Instruction
Shift And Round
Move With Offset
Pack
Unpack
Zero And Add
Compare
Add
Subtract
Multiply
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. Well 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 well see many examples.
This is the format of instructions with a single length field.
opcode

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

115

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). Well 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
CLC
TR
XC

0(80,4),40(9)
Name(24),RecName
OutCh(,15),0(12)
Count,Count

Explicit length and addresses

Explicit length, implied addresses
Implied length, explicit addresses
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

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. Well see these again in Chapter VIII.
Some examples of SS-type instructions with two length fields are:
PACK
ZAP
AP
UNPK

0(8,4),40(5,9)
Sum(14),OldSum(4)
Total(,15),Num(,12)
String,Data

Explicit lengths and addresses

Explicit lengths, implied addresses
Implied lengths, explicit addresses
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.)
(a)
(b)
(c)

116

1(2)
4(5,6)
A(L B)

Assembler Language Programming for IBM z System Servers

Version 1.00

(d)
(e)
(f)

Line
Line(80)
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

explicit address
An address in which you specify the base register specification digit and the displacement as
absolute expressions.
implied address
An address where you expect the Assembler to assign a base register specification digit and a
displacement to an addressing halfword.
explicit length
A length field that you specify explicitly.
implied length
A length field completed by the Assembler based on its analysis of the operand.
mnemonic
A character string representing an instruction, intended to be easier to remember than the
operation code of the instruction.
operation code
The z/Architecture definition of an instructions bit pattern to be decoded by the CPU to
determine what actions it should take.
opcode
An abbreviation for operation code. Occasionally used when the term mnemonic is actually
meant.
Length Expression
A value you write in an SS-type instruction specifying the length of the operand(s).
program length
A Length Expression.
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).
machine length
An Encoded Length.

Chapter III: Assembler Language Programs

117

10. Establishing and Maintaining Addressability

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

00000000
0000000000
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
0000000000
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.59 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 instructions 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. (Well 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, the assembled contents of memory will be hexadecimal machine language data, as
shown in Figure 36 on page 120. Suppose the Program Loader has relocated the program so
that the first instruction (the BASR) was placed at memory address X5000.

118

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 addressing mode.
Assembler Language Programming for IBM z System Servers

Version 1.00

Address

Name

Operation Operand

Remarks

5000
5002
5006
500A
5024
5028

Fragment of a simple program

BASR
6,0
Establish base address
BEGIN L
2,N
Load contents of N into GR2
A
2,ONE
Add contents of ONE
ST
2,N
Store contents of GR2 into N
--twenty-two (X16) additional bytes of instructions, data, etc.-N
DC
F 8
Word integer 8
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 contents 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, well 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 X00005002. (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 subsequent addressing halfwords should be 6.
We can determine the proper displacement in the L instruction at X5002 by using two important
values: the known contents of register 6 (X00005002) and the address of the word area named N.
Using these values, we can now compute a displacement:
X00005024 X00005002 = X022
Then, the assembled machine language instruction (using opcode X 5 8 for the mnemonic L) will
be X58206022. When this instruction is executed, its Effective Address is
X022 + X00005002 = X00005024,
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

Chapter III: Assembler Language Programs

119

is complete, we want the memory areas starting at address X5000 to contain the (hexadecimal)
machine language data shown under Assembled Contents in Figure 36.
Address

Assembled Contents

Original Statement

5000
5002
5006
500A

0D60
58206022
5A206026
50206022

5024
5028

00000008
00000001

BASR
6,0
L
2,N
A
2,ONE
ST
2,N
---------------------------------N
DC
F 8
ONE
DC
F 1
BEGIN

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 0 D60 , 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, lets suppose the same program segment
begins at memory address X84E8 , as in Figure 37.
Address
84E8
84EA
84EE
84F2
850C
8510

Statement
BASR
6,0
BEGIN L
2,N
A
2,ONE
ST
2,N
--- the same 22 bytes of odds and ends --N
DC
F 8
ONE
DC
F 1

Figure 37. Same program segment, at different memory addresses

After executing the BASR, register 6 contains X000084EA . To address the contents of the word
named N using register 6 as a base register, the necessary displacement is
X0000850C X000084EA = X022
Similarly, the displacement necessary in the A instruction is
X00008510 X000084EA = X026
After completing the three addressing halfwords, the assembled machine language program would
appear in memory as shown in Figure 38.
Address
84E8
84EA
84EE
84F2
850C
8510

Assembled Contents
0D60
58206022
5A206026
50206022
----------------00000008
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

120

Assembler Language Programming for IBM z System Servers

Version 1.00

could be placed anywhere in memory and still execute correctly. That is, the program is relocatable.
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 X00000002, 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: were describing locations at assembly time, not the execution time addresses we saw
in the previous examples.)
Location
0000
0002
0006
000A
0024
0028

Name

Operation Operand

BASR
L
A
ST
--------- 22 bytes
N
DC
ONE
DC
BEGIN

6,0
2,X022(0,6)
2,X026(0,6)
2,X022(0,6)
---------F 8
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 (especially 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 displacements.
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 95, 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 X0002, X0024, and
X0028, respectively.
The key to this example is that when the program is executing, the base register (register 6) contains the address of the instruction named BEGIN. We use this observation to rewrite the program
segment, as shown in Figure 40.
Location
0000
0002
0006
000A
0024
0028

Name

Operation Operand

BASR
6,0
L
2,N-BEGIN(0,6)
(N-BEGIN = X022)
A
2,ONE-BEGIN(0,6) (ONE-BEGIN = X026)
ST
2,N-BEGIN(0,6)
(N-BEGIN = X022)
------- the usual 22 bytes ------N
DC
F 8
ONE
DC
F 1
BEGIN

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 displacements 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).
Chapter III: Assembler Language Programs

121

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.

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 displacements.
We now rewrite the sample program segment of Figure 40 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 X0002, and the values of the
symbols N and ONE will be X0024 and X0028 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:
X0024 X0002 = X022
and this is the required displacement.
Similarly, the implied address of the operand ONE of the A instruction has value X0028; when
the base_location value is subtracted, we find the displacement is X026, as before. We say that
the Assembler has resolved the implied addresses of the L, A, and ST instructions into basedisplacement 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 displacements 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.60

122

Section 20 describes long-displacement and relative-immediate instructions with a larger range of displacement values.
Assembler Language Programming for IBM z System Servers

Version 1.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 122 should be noted.
1. The USING instruction does absolutely nothing about actually placing an address into a register; it merely tells the Assembler what to assume will be there when the program is executed.
That is, your USING statement is a promise to the Assembler that if it computes displacements for you, everything will work properly when the program is executed. (It is very easy
to mislead the Assembler, as well see in Section 10.11 on page 131.)
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). 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 programs, specifying and using base registers is very easy.
Its 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

123

10.6. Destroying Base Registers

Suppose an error was made in writing the statement with the L instruction, such that it became
BEGIN

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

0002
0006
000A

58606022
5A206026
50206022

0024
0028

00000008
00000001

BASR 6,0
USING BEGIN,6
BEGIN L
6,N
Wrong register!
A
2,ONE
ST
2,N
--------------------------N
DC
F 8
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
X5000, so that when the L instruction is executed, register 6 contains X00005002. Now, the L
instruction copies a word from memory at the address given by the second operand into the register 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 X00000008 and not X00005002,
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
X026 + X00000008 = X0000002E
and not X00005028, 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 2s initial (and unknown) contents.
Finally, the ST instruction will attempt to store a word at X0000002A , 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 X5000, what
would be in that area of memory after the ST instruction is executed?

124

Assembler Language Programming for IBM z System Servers

Version 1.00

10.7. Calculating Displacements: the Assembly Process, Pass One

Now, well 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 Assemblers
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 95. (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 programs 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, 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

125

Read statement
and save it

yes

END ? to Pass 2

no
yes
comment?

Instruction symbol in is it in

statement? yes name field?yes symtbl?

no
no no
yes

enter it

Undefined

nodoes it
mnemonic:

have a

note error

value?

set value
yes

from LC

enter in
note error

table, Ysymbol(s) in

no valueoperand field?

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 basedisplacement form, and fill in the four blank fields.
Loc
5000
5002
5002
5006
500A
500E
512C
5174
5178
51A0

126

Object Code

Statement

05A0
41D0____
4110____
4DE0____
50______
SAVE
PARM
TBL
SUB

BASR
USING
LA
LA
BAS
ST
- - DS
DC
DS
STM

Assembler Language Programming for IBM z System Servers

10,0
*,10
13,SAVE
1,PARM
14,SUB
0,TBL(15)
18F
A(TBL)
10F
14,12,12(13)

Version 1.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 126 describing the first pass of the assembly, this is a very abbreviated description, so dont attach great significance to the precise sequence of processing actions
implied by the diagram.

Read, Print
statement

yes

comment?

yes

USING ? enter data in USING Table

yes

DROP ? delete entry from USING Table

yes

END ? Create object module;

return to Supervisor

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 attributes of the first operand expression (the base_location), and the value of the second expression
(the base_register number), into a USING Table.

Chapter III: Assembler Language Programs

127

Figure 45 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 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 122. 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 X00000002, the value of the symbol
BEGIN illustrated in Figure 45.
When the third statement in Figure 41 is processed, the value of the implied address is the value
of the symbol N, or X00000024. The computed displacement is
X00000024 X00000002 = X022
as we saw previously, so the completed addressing halfword is X6022.
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.

128

Assembler Language Programming for IBM z System Servers

Version 1.00

Loc
10A20
10A20
10A24
10A28
10A2A
10A2E
10A32
- - 10A76
10A78
10A80
10A84

Object Code

Statement

5830____
4A30____
10__
9034____
4240____
4770____
W
Z
Y
X

USING
L
AH
LPR
STM
STC
BC
- - DS
DS
DC
DC

*,11
3,X
3,Y
4,3
3,4,Z
4,W
7,*+24
X
2F
H -72
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

0000

Operation Operand

BASR
6,0
USING
*,6
BEGIN L
2,N
USING
*,7
A
2,ONE
ST
2,N
--------------------------N
DC
F 8
ONE
DC
F 1

0002
0006
000A
0024
0028

Remarks

Original USING statement

Added USING statement

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 X00000006, 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

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
X00000028 X00000002 = X026
and the addressing halfword would be X6026 (as in Figure 42).
Chapter III: Assembler Language Programs

129

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
X00000028 X00000006 = X022
and the addressing halfword would be X7022. (Similarly, the ST instruction could have an
addressing halfword X701E .)
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.

Choose the base register that leads to the smallest displacement.

If more than one base register provides the same smallest displacement, choose the corresponding highest-numbered register.

Thus, the assembled program would appear as shown in Figure 48 below:

Location

Assembled Contents

00000
00002
00006
0000A

0D60
58206022
5A207022
5020701E
----------------00000008
00000001

00024
00028

Based on register 6
Based on register 7
Based on register 7

Figure 48. Assembled contents when two USINGs are active

At this point, you could (correctly) observe that this program is seriously flawed, because the contents of GR7 at execution time could be anything. When the A and ST instructions are executed, 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 information 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, the initial
USING Table entry for register 6 would be deleted, and the USING Table would appear as in
Figure 49:

130

Assembler Language Programming for IBM z System Servers

Version 1.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, its 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 X4000.
BASR
USING
L
BASR
USING
L
DROP
L
DROP
L

9,0
*,9
4,*+54
10,0
*,10
3,*+52
9
2,*+48
10
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 X002468. This
means that the value of the operand *+5000 is
X002468 + X1388 = X0037E0
and that the calculated displacement (for register 6) would be

Chapter III: Assembler Language Programs

131

X0037E0 X002468 = X1388

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 X002468:
BASR 6,0
USING *,6
L
2,*-32
In this case the operand value is X002448, 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, 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

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; absolute 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 Assembler 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:

132

Assembler Language Programming for IBM z System Servers

Version 1.00

basereg base_location RA

0
00000000 00 Assembler s hidden USING-Table entry

etc.

Thus, an implied address such as

Implied address = 1000 = X 3 E8

3,1000

would be resolved to the addressing halfword X03E8 , with base register zero.
In the example in Figure 34 on page 111, we saw an instruction with an absolute implied S2
operand:
43000468

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
LA
3,1000

Base Address = 400 = X190

Implied address = 1000 = X 3 E8

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 X03E8 and X9258. Since the latter provides the smallest displacement, 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.61

Section 20 shows how to use a much larger range of displacement values with long-displacement instructions.
Chapter III: Assembler Language Programs

133

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 relocatable, 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 register whose base_location is relocatable, since a valid displacement cannot be computed from
(absolute) displacement = (absolute base_location) (relocatable operand) (??)
It is possible (but not recommended!) to specify USING statements with register zero as the base
register,62 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 specified 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.63
USING Resolution Rules
1. The Assembler searches the USING Table for entries with a relocation 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 displacement 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 absolute, 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.

134

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.
Some programmers note that USING is part of confusing.
Assembler Language Programming for IBM z System Servers

Version 1.00

The relocatability attribute of any given symbol almost always has a single value; it wont matter
if we ignore complex relocatability situations for now, because they dont 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.

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
z System. The Assembler determines the needed base and displacement so that correct Effective Addresses will be computed at execution time.
2. Rather than remembering that operation code X 4 3 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
A

Equ 6
- - Equ 32
- - -

Define a value for A

Write statements using A s value
Define a new value for A
Statements using A s new value

How would the assemblers treatment of the Symbol Table be changed? What would happen if
any symbol could be redefined?

Terms and Definitions

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.
USING Table
An internal table used by the Assembler to hold information provided in USING
instructions.
DROP assembler instruction
An instruction telling the Assembler to eliminate one or more entries from its USING Table.

Chapter III: Assembler Language Programs

135

base_location
The first operand of a USING instruction at assembly time.
base_register
The second operand of a USING instruction at assembly time.
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.
Symbol Table
A table used by the Assembler to hold the names, values, and attributes of all symbols in a
program.

Programming Problems
Problem 10.1.(1) Write and assemble a program segment like the one in Figure 41 on
page 122, with the following additional statements:
1. Following the last DC statement, place an Assembler instruction statement with the mnemonic 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 X5000 in the operand field.
Assemble the program, and save the Assemblers listing. Then, replace the X5000 operand in
the START statement with the X84E8 , 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.

136

Assembler Language Programming for IBM z System Servers

Version 1.00

Chapter IV: Defining Constants and Storage Areas

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

VV
VV
VV
VV
VV
VV
VV
VV
VV
VV
VV
VV
VV
VV
VV
VV
VV
VV
VV VV
VVVV
VV

The three sections of this chapter treat the DC (Define Constant) and DS (Define Storage) assembler instruction statements, and methods used to define data and storage areas in Assembler Language programs.
Section 11 describes the Assemblers basic data definition instruction, DC.
Section 12 discusses the most often-used data types, introduces the powerful constantreferencing 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

137

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, well describe basic rules for defining constants of any type.
z System 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 (twos 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. 64
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)

138

Well investigate some non-EBCDIC character data types in Section 27.

Assembler Language Programming for IBM z System Servers

Version 1.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 doesnt really define an unchangeable constant value,
because you can change it at execution time. (Its only constant if you
dont change it!) The instruction might better be called Define Data
with Initial Value. Well see that literals can help you define what
appear to be true constants In Section 13.9 on page 176.
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, operation, operand, and remarks field entries; the operation and operand field entries are required.

11.1. Defining Constants

Well start with the F-type constant we saw in several earlier examples. The assembler instruction
statement
F 8

creates a word binary integer constant (X00000008), placed on a word boundary. In this statement, 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 twos 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:
H 8
C /
X 6 1
B01100001

DC
DC
DC
DC

halfword binary integer

character constant
hexadecimal constant
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 selfdefining 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

B11010001,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

139

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 F8 ?

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 letters65) 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. 66 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 F110 and B110 are quite different.
The constant type also determines what conversion from external to internal representation should
be performed: the internal representations of F110 (binary word), X110 (hexadecimal constant), E110 (short floating-point), Z110 (zoned decimal), and P110 (packed decimal) are different, 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

F12345678

F12 345 678

or
Well see more examples as we investigate various data types.

65
66

140

Well discuss type extensions in Section 12.8.

HLASM supports another constant modifier and attribute, Program. It is used almost entirely in conditional
assembly macro-instruction statements.
Assembler Language Programming for IBM z System Servers

Version 1.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 dont have a natural alignment; Tables 32 and 33 in
Sections 12.5 and 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.67 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. 68 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 X00012E
(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 X00012E
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 X000130 (now wordaligned) before the word constant is assembled. The LC has value X000134 after the constant is
processed; it would be X000132 if automatic alignment was not done.
Automatic alignment is not performed (bytes are not automatically skipped) if:
1. it isnt needed: that is, the LC happens to fall on the desired boundary; or
2. the type of constant specified doesnt 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.69

Well 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.
HLASM provides the SECTALGN option to let you specify even more restrictive boundaries. See the High Level
Assembler Programmer s Guide for details.
For details, consult the High Level Assembler Programmer s Guide for the NOALIGN option. However, few programs use this option.
Chapter IV: Defining Constants and Storage Areas

141

11.4. Length Modifiers

Length modifiers let you specify (within limits) a constants exact length in bytes.70 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

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 constants 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.71 For example, the statements
DC

FL3 8

FL(2*4-5) 8

and
both cause the three-byte constant X000008 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

FL4 8

and
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 symbols value. Suppose the value of the LC is X00012E when each of the
statements in Figure 51 is encountered.
Explicit DC
Implied DC

FL4 8
F 8

Explicit length = 4 bytes, not aligned

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 X00012E . 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, X000130.
Symbol definition
When a symbol is defined, it is given its value after bytes are skipped for
boundary alignment.

142

It is also possible to specify a constants length in bits, using a bit-length modifier. They have specialized uses; we will
describe them in Section 17.5 on page 257.
Sometimes the Assembler will let you define symbols after they are used in length modifier expressions, but its safest
to make sure theyre defined before theyre used in length modifiers.
Assembler Language Programming for IBM z System Servers

Version 1.00

As a general rule, the Assembler never automatically assigns the location of skipped bytes as the
value of a symbol.72 This includes cases where a byte must be skipped to ensure that an instruction 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)
(2)
(3)
(4)

DC
DC
DC
DC

FL1 -127
FL2+128
FL3 -99,+99
FL1+127

11.4.2.(1) + For these constants:

(1)
(2)
(3)

DC
DC
DC

F 1 1 , FL3 1 2 , FL3 1 3
F 2 1 , FL2 2 2 , FL2 2 2
F 3 1 , FL4 3 2 , FL3 3 3

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 immediately preceding the letter specifying the constant type. It may be either an unsigned decimal selfdefining 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.73 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
DC
DC

F 8
F 8
F 8

Three statements

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

You can find ways to do it if you like, but theres no real value in doing so. (Why refer to something so uninteresting?)
Sometimes the Assembler will let you define symbols after they are used in duplication factor expressions, but its
safest to make sure theyre defined before theyre used in duplication factors.
Chapter IV: Defining Constants and Storage Areas

143

F 7 , 2 F 4 , 3 F 9

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

0F,FL4 -1

or even

Zero duplication factors are discussed further in Section 13.2 on page 162.

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
F 8 , 8 , 8

Three8s DC

One operand, 3 nominal values

This is equivalent to
Three8s DC

3F 8

One operand, duplication factor 3

F 8 , F 8 , F 8

Three operands

and
Three8s DC

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

F 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9 , 1 0

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

F1,000,000,000

What would be generated? What would you recommend?

11.6.2.(1) What will be generated by this constant?
DC

144

2F 1 , -1

Assembler Language Programming for IBM z System Servers

Version 1.00

11.7. Length Attributes

Although its many benefits will become clear later, we noted in Section 7.3 on page 91 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

R7,R3

(from Example 8_4_1 on page 102 in Section 8.4.)

is 2, and the Length Attribute of the symbol BEGIN in

BEGIN

2,N

(from Figure 35 on page 119)

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
Explicit DC
Three8s DC

F 8
FL4 8
3F 8

(from Figure 51 on page 142)

all have Length Attribute 4.

3. If the symbol names a DC statement whose first operand contains multiple values, the symbols 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

F 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9 , 1 0

(from Figure 52 on page 144)

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

(from Example 8_4_2 in Section 8.4.)

has Length Attribute 1. (The EQU assembler instruction is described further in Section 13.3
on page 164.)

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
F100B
F1000
FBillion

DC
DC
DC
DC

F 1 E2
F1000E-1
F 1 E3
F 1 E9

Generates
Generates
Generates
Generates

X00000064
X00000064
X000003E8
X 3 B9ACA00

Chapter IV: Defining Constants and Storage Areas

145

11.8.2. Exponent Modifiers

An exponent modifier is written following the constants type, and following any other modifiers.
For example:
F100A
F100B
F100C
F1000A
F1000B
FBillion

FE2 1
FE-11000
FL4E2 1
FE3 1
FL3E3 1
FE9 1

DC
DC
DC
DC
DC
DC

Generates
Generates
Generates
Generates
Generates
Generates

X00000064,
X00000064,
X00000064,
X000003E8 ,
X0003E8 ,
X 3 B9ACA00 ,

aligned
aligned
unaligned
aligned
unaligned
aligned

You can write constants with both an exponent modifier and a decimal exponent

Assembler Language Programming For IBM Z System Servers

Uploaded by

Assembler Language Programming For IBM Z System Servers

Uploaded by

Assembler Language Programming

IBM Silicon Valley Lab

First Edition (January 2015)

Use, duplication or disclosure restricted by GSA ADP Schedule

Assembler Language Programming for IBM z System Servers

Outline and Overview . . . . . . . . . . . . . . . . . . .

Chapter I: Getting Started

Chapter II: z System

3. Conceptual Structure of z System . . . . . . . . .

1. Some Basic Items . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.1. The Addressing Halfword . . . . . . . . . . .

Chapter III: Assembler Language Programs

Assembler Language Programming for IBM z System Servers

Chapter IV: Defining Constants and Storage Areas

11. Defining Constants . . . . . . . . . . . . . . . . . . . . .

Chapter V: Basic Instructions

14. General Register Data Transmission . . . . . . . . . . . . . . . . . . . . . .

15.8. A Design Oversight and a Modern Correction (*) .

Chapter VI: Addressing, Immediate Operands, and Loops

20. Address Generation and Addressing Modes . . . . . . . . . . . . .

Assembler Language Programming for IBM z System Servers

21.2.2. Arithmetic-Immediate Compare Instructions

Chapter VII: Bit and Character Data

23. Bit Data and Instructions

25.5. Move String Instruction . . . . . . . . . . . . . . . . . . . .

Chapter VIII: Zoned and Packed Decimal Data and Operations

Assembler Language Programming for IBM z System Servers

29.9. Decimal Shifting Using MVO (*)

Chapter IX: Floating-Point Data and Operations

Assembler Language Programming for IBM z System Servers

34.8. Binary Floating-Point Division . . . . . . . . . . . . . . . . . . . . . . . . .

Chapter X: Large Programs and Modularization

Assembler Language Programming for IBM z System Servers

37. Subroutines and Linkage Conventions . . . . . . . . . . . . . . . . . . . . . .

38.4. Control Sections . . . . . . . . . . . . . . . . . . . . . . . . .

Chapter XI: Dummy Sections, Enhanced USINGs, and Data Structures

39. Dummy Control Sections and Enhanced USING Statements . . . . . . .

Chapter XII: System Services, Reenterability, and Recursion

Appendix A: Conversion and Reference Tables

Hexadecimal Digits in Decimal and Binary . . . . . . . . . . . . . . .

Appendix B: Simple I/O Macros

Assembler Language Programming for IBM z System Servers

Glossary of Terms and Abbreviations

Suggested Solutions to Selected Exercises and Programming Problems

Example of numbering and notation

Assembler Language Programming for IBM z System Servers

USING Table after second DROP statement . . . . . . . . . . . . . . . . . . .

Using shift instructions for a 6-byte data item . . . . . . . . . . . . . . . . . . . . . . . 246

Assembler Language Programming for IBM z System Servers

Sketch of a Do-While loop . . . . . . . . . . . . . . . . . . . . . . .

Execution of the MVST instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Assembler Language Programming for IBM z System Servers

All sixteen floating-point registers, showing register pairings . . . . . . . .

Assembler Language Programming for IBM z System Servers

Examples of binary integer to binary floating-point instructions . . . . . . . . .

Constructing an argument address list . . . . . . . . . . . . . . . . . . .

Assembler Language Programming for IBM z System Servers

Simple example of LOCTR (1) . . . . . . . . . . . . . . . . . .

Assembler Language Programming for IBM z System Servers

Retrieving a specified element of an array efficiently

Generated statements from a Standard-form macro with arguments in registers

Binary, decimal, and hexadecimal . . . . . . .

Assembler Language Programming for IBM z System Servers

Punched-card image of a RETURN statement

CC settings after logical comparisons . . . . . . . . . . . . . . . . . . . . . . . . .

Assembler Language Programming for IBM z System Servers

Instructions for moving numeric and zone digits . . . . . . . . . . . . . . . . . .

Assembler Language Programming for IBM z System Servers

Convert binary to hexadecimal floating-point instructions . . . . . . . . . .

DFP Test Data Class second-operand bits . . . . . . . . . . . . . . . . . . . .

Assembler Language Programming for IBM z System Servers

Length modifiers of floating-point constants . . . . . . . . . . . . .

Assembler Language Programming for IBM z System Servers

Outline and Overview

Levels of Difficulty (*)

Exercises and Programming Problems