As Mr. Gilmartin has reminded me, SPM was part of the original S/360
instruction set. (I actually did know that, but having been retired for almost
3 years now, I'm getting a little rusty ... thanks Gil for slapping me upside
the head.)
As Mr. Metz points out, there are countless ways of non-destructively setting
the condition code (i.e., without changing registers or memory). A challenge to
do this in extremely high-performance code is to do it without a
storage-operand reference ... i.e., dragging some operand into the data cache.
CC0 is easy (e.g., compare a register to itself). SPM can help with CC1-CC3,
but you need a register handy.
As Mr. Weinhold notes, VM functions have returned a CC for ages. This is
something that is necessary when simulating instructions that are either (a)
not part of the machine, or (b) intercepted by the hypervisor and managed by
the VM host. (However, in such cases, VM simply modifies the guest's PSW before
resuming guest execution.)
With regards to Kevin's question, "Are you suggesting the use of SPM/IPM as an
alternative to actually setting the condition code?" SPM actually sets the
condition code (from bits 34-35) and the program mask (from bits 36-39) of the
first-operand register. For example, let's say that you have a value in the
rightmost two bits of R0 that you want to become the new CC (and that you don't
mind if the program mask gets zeroed):
SLL 0,28 Shift bits 62-63 to bits 34-35.
SPM 0 Set the CC (PM becomes zeros).
IPM simply captures the CC and PM (from bits 18-23 of the current PSW) into
bits 34-39 of the first-operand register.
Why these weird bit positions in the register? In original S/360 architecture,
BAL and BALR put the instruction-length code (ILC), CC, and PM in bits 0-7 of
the first-operand (32-bit) register, and SPM restored the CC and IPM from the
same bit positions. In z/Architecture, these became bits 32-39 of the register,
but BAL/BALR does this only in the 24-bit addressing mode in XA and Z.
