@Gil, yes, good point. "Interrupt" in the general sense of the word, like a co-worker interrupting your work, not in the specific zArchitecture sense of "an interrupt." NI's sequence of fetch, AND, store might have been interleaved with the storage accesses of another CPU.
What was the performance impact? Nothing is free, but in the brave new world of 3 levels of caches, SMT and out-of-order execution, what is the performance of any instruction? On the S/360 the memory data path was 8, 16, 32 or 64 bits, depending on the model. Why was there never such an issue with MVI to different bytes of the same storage "chunk"? I don't know. The S/360's were pretty serial in how they did things. Multi-processors with common memory came along at a tiptoe pace. Charles -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Paul Gilmartin Sent: Sunday, July 30, 2017 11:01 PM To: [email protected] Subject: Re: Question about CPUs On 2017-07-30, at 22:57, Charles Mills wrote: > Nay. Many, many instructions are not atomic. On a single CPU, yes. For > multiple CPUs, not atomic. Until the z13 (?), for example, NI, OI and > XI were interruptible within a reference to a single byte. NI is > actually fetch, AND, store. It could be interrupted between the fetch and the store. > So two processors doing NI or OI on the same byte could get "logically > impossible" results. > Be careful with your use of "interrupt". To some readers it may mean a context switch by loading a new PSW, not what I believe you intend. What was the performance cost of making NI, OI, and XI block-concurrent? I suspect many programs will never rely on this behavior, and have never used tne NIL and OIL macros, yet will bear the burden of any overhead. I understand that even in the S/360 the data path to memory was 16 bits or more, so MVI must also do a fetch, update, store. Why was there never a similar hazard when two processors MVI to different bytes of the same halfword?
