I've observed the branch behaving differently if the WTO is placed after comparison. I understand WTO is an SVC request. That
is, it is an interrupt, which should preserve the original PSW. But I have no other explanation to the change in the behavior, but
modification to condition code..
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
You are correct in your observation that the WTO macro invokes an SVC.
However -
The CLC instruction updates an internal (to the hardware) two bit register called the condition code. Many other instructions also update the condition code. In theory, since the condition code is part of the PSW, the interrupt generated by the SVC instruction should preserve the condition code. I've never tried to observe if this is correct. I just go by the rule that all macros destroy the condition code, usually because most macros have other instructions. The WTO in your code fragment, for example, generates
LA 1,MYMSG
SVC 35
The LA instruction does not alter the condition code.
Two more observations.
Your one byte CLC would be better coded using the CLI instruction.
CLI is a 4 byte instruction, CLC is a 6 byte instruction.
The =X'FF' in your CLC references storage. The X'FF' in the equivalent CLI is part of the instruction. Assembler programmers try to avoid unnecessary storage references. The hardware design engineers have finally deduced this is good; we see many newer instruction introduce data as part of the instruction. CLI, on the other hand, has been in the hardware since System/360.
Registers 2 through 13 are generally not altered by any IBM macro; it is not necessary to save and restore them yourself. On the other hand, registers 0, 1, 14 and 15 are altered by most IBM macros. As noted before, the macro code in WTO alters register 1, and MVS Programming: Assembler Services clearly states registers 0, 1, 14 and 15 are altered somewhere in WTO macro processing.
Thank you for your points - there is really no need to unnecessarily bloat literal pool or text, that example was
sloppy. What document better explains the interrupt mechanics on zOS? I've been mostly reading Operation
Basics so far, then there is also Systems Programming redbook. What sources would you recommend?
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
Technically, Principles of Operation, but its very hard going and it's incomplete as it does not discuss what happens after the interrupt completes as that's not hardware, it's software. Here is a summary for an SVC interrupt.
The current PSW is stored at a fixed location in the PSA.
A new PSW is loaded from a different, fixed location in the PSA. This PSW starts executing a nucleus routine called a FLIH (First Level Interrupt Handler). The SVC FLIH saves the registers, saves the interrupt PSW, retrieves the interrupt code (the code from the SVC instruction), uses the interrupt code to retrieve additional information about the requested SVC from the SVC table, and runs the code for the SVC. After the SVC routine completes, the SVC FLIH restores the registers and resumes the program.
It's actually more complex than that, but that's a pretty good very high level summary. I wanted to retrieve more info, but as I'm writing this the IBM manuals web page appeared to be broken.
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
Catz wrote:
Thank you for your points - there is really no need to unnecessarily bloat literal pool or text, that example was
sloppy. ...
Personally, I won't comment on "bloating" the literal pool. I better not, since I'm often guilty of doing just that! But a storage reference is another matter. It can be very expensive. In the early 1980s I developed a performance analyzer targeted at JES2. One thing the analyzer did was note JES2 waits caused by a page fault. There were very few, but one that did stand out was one instruction in HASPPRPU that looked at one byte in a JES2 control area called a DCT. This single instruction dominated JES2 page faults! Now, by definition, PRPU is going to be using DCTs since DCTs are used to define JES2 devices like printers, though it took some research to figure out why it was getting a page fault at this one location for just the one byte. PRPU was looking at a DCT it was actively using when it executed the instruction; it was fully justified in checking the byte, but it was not using the DCT often enough to prevent MVS from paging it out. The immediate solution was a local user mod to copy the one byte to storage less likely to be paged out before effectively releasing its use of the DCT storage.