If HALT IO (HIO) was 9E00, and HALT DEVICE (DV) was 9E01, why did they
skip from 9E01 to 9EFI for HFIRE (HALT, SET FIRE)?
(Ok, just being a smart ass today.)
Tony Thigpen
Dan Greiner wrote on 8/4/25 2:04 PM:
As to my original query, I was wondering to what extent anyone might use EX (or
EXRL) to alter the actual target instruction. Yves gave an intriguing reply
where a value of 0, 1, or 2 in the R1 field of EX could alter its target
instruction from SAM24, SAM31, or SAM64. In this case, it's clever and
efficient. However, perhaps a more understandable technique might be to use EX
with an index register that identified the actual instruction to be executed.
The CPU designers have a long love/hate relationship with execute-type
instructions (tending towards hate). As to whether they and the architects
envisioned that EX could be used to modify the target opcode ... undoubtedly
they did. Perhaps they could have designed it such that if the R1 field
modified a target opcode, an exception could be recognized ... but they didn't.
I'm just trying to understand whether anyone (other than Yves) actually uses
this.
As to the history of opcodes stretching beyond the first 8 bits: the original
S/360 architecture had about 150 instructions defined, so there was room for
another 100-or-so one byte opcodes to be defined without going beyond one byte.
The first instance of opcodes creeping beyond bits 0-7 of the instruction
showed up later in the S/360 architecture. Originally, the HALT IO (HIO)
instruction was defined as opcode 9E hex, with bits 8-15 reserved. Its opcode
was subsequently redefined as 9E00 hex, and HALT DEVICE (HDV) was defined as
9E01 hex.
It wasn't until the S/370 architecture (circa 1970) that major infestation of
bits 8-15 occurred with the advent of the RRE-, S-, SSE-format instructions.
The vast majority of these were privileged or semi-privileged instructions,
with a few exceptions like SET SYSTEM MASK (SSM), STORE CLOCK (STCK), and TEST
AND SET (TS) that were unprivileged. (SSM and TS were reclassified to S format
from their original SI format in S/360).
370/XA (circa 1983) introduced the E-format instruction – an instruction format
with just 16 bits of opcode and nothing else – for the UPDATE TREE (UPT)
instruction (as if UPT was going to be coded so frequently that it warranted a
special format to save code space ... not the brightest architecture IMHO).
Somewhere between ESA/370 and ESA/390, the immediate-and-relative-instruction
facility came along that introduced the RIL format in which the opcode was
split between bits 0-7 and 12-15. This provided significant enhancements with
relative (to the PSW instruction address) storage operands and 16-bit immediate
operands.
A bit later in the ESA/390 time frame came the RXE and RXF formats, a 6-byte instruction
where the opcode was split between the first and last byte (i.e., bits 0-7 and 40-47).
These were used for binary floating point instructions and for some z/Architecture ops
that were retrofit to ESA/390. Also in later ESA/390 time frame came RSE and RSL formats
with similar opcode split. These provided such "features" as COMPARE LOGICAL
LONG UNICODE (CLCLU), MOVE LONG UNICODE (MVCLU), and ROTATE LEFT SINGLE LOGICAL (RLL).
z/Architecture flooded the architecture with gobs more instructions in which
the opcode extended beyond bits 0-7. For a great overview of the instruction
formats, see Figure 5-1 in the latest PoO.
