Re: Question about CPUs

Nope. I give up. You are of course free to believe whatever you wish. Just please do not write any kernel code. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Keven Hall Sent: Monday, July 31, 2017 8:51 PM To:

Re: Question about CPUs

Other than for SIGP I can't off the top of my head think of a suituation where one processor interrupts another explicitly during instruction execution. Can you provide some specific details as to what "interruptible" means here? Keven > On Jul 31, 2017, at 21:45, Charles Mills

Re: Question about CPUs

People are confusing single processors with multiple processors. On a single processor, almost all instructions are atomic. The exceptions are the obvious ones like MVCL, which are obviously designed to take an interrupt and resume. Yes, all interruptions are at an instruction boundary, and the

Re: Question about CPUs

On 2017-07-31, at 18:41, Robin Vowels wrote: > >> I think (TS) Test and Set was/is atomic and AFAIK was the earliest >> implemented >> atomic instruction. > > I think that the entire /360 user instruction set would have been of that > kind. > > AFIK there was no provision to suspend any

Re: Question about CPUs

From: "Gary Weinhold" Sent: Tuesday, August 01, 2017 12:16 AM I think (TS) Test and Set was/is atomic and AFAIK was the earliest implemented atomic instruction. I think that the entire /360 user instruction set would have been of that kind. AFIK there was no provision to

Re: Question about CPUs

On the first multiple processors (360/40 and [360/65 later called? - fuzzy old memory] 360/67) in a multitasking program, TS was the only ATOMIC instruction. You obtained lock to a block of storage using whatever lock was setup for that block of storage by either the operating system or by

Re: Question about CPUs

On 2017-07-31, at 09:50, Robin Vowels wrote: > From: "Charles Mills" > Sent: Monday, July 31, 2017 2:57 PM > > >> 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

Re: Question about CPUs

From: "Charles Mills" Sent: Monday, July 31, 2017 2:57 PM 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

Re: Question about CPUs

On 7/30/2017 9:57 PM, Charles Mills wrote: 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

Re: Question about CPUs

When venturing into multi-tasking code, learning just how non-atomic OI and NI are (were) is (was) a hard lesson. Now it's going to be so easy ;-). I guess in a few decades when all pre-z13 machines are retired I can simplify a bunch of code. sas On Mon, Jul 31, 2017 at 10:16 AM, Gary Weinhold

Re: Question about CPUs

I agree TS was first "atomic". Second afaicr was CS and CDS for queue maintenance. Used extensively in session manager for sending and receiving messages in an object oriented multi-task environment. I remember that the explanation given previously on one of these lists was that TS was done

Re: Question about CPUs

I think (TS) Test and Set was/is atomic and AFAIK was the earliest implemented atomic instruction. I think it addressed the requirement to allow interruptible code to fetch, test, and modify a single byte on a single CPU machine with integrity. An external or I/O interrupt could undermine

Re: Question about CPUs

@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

Re: LOC=64 executable code?

Would this new feature help out with caching on the back end? The CPU now can determine that portions of storage will always (if referenced) fill the data cache and never will be loaded into the instruction cache. -Original Message- From: IBM Mainframe Assembler List

Re: Question about CPUs

Phil Smith wrote: >Mmm...I'm pretty sure a single instruction is still atomic. I'm sure Peter >Relson or one of the other IBMers will chime in, but it there has to be some >sort of interlock at some level. And I've debugged plenty of concurrency >problems, never seen a mixture from a single

Re: Question about CPUs

There was no performance cost to of making NI, OI, and XI atomic. The implementation of the newer machines already happened to work that way, and the engineers were willing to commit to maintaining that behavior on future machines, so the behavior was added to the architecture. Jim Mulder

Re: Question about CPUs

Such questions are best answered by reviewing the topic "Block-Concurrent References" in Principles of Operation. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY > From: Phil Smith > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Date: 07/31/2017

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