Your thoughts are like mine on "why?". I am wondering if it is simply "easier" to make a possibly long running instruction stop and set a CC=3, like MVCLE, than it is to make it stop and checkpoint in such a way as to be restartable "automagically" like MVCL. Or perhaps it is easier to validate in some sort of simulator/emulator that IBM uses before "commiting to silicon".
-- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * [email protected] * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -----Original Message----- > From: IBM Mainframe Assembler List > [mailto:[email protected]] On Behalf Of Steve Marak > Sent: Friday, January 06, 2012 11:16 AM > To: [email protected] > Subject: Re: z/Arch design question. > > John, > > Good luck. I've asked the same question before and never > gotten an answer > I felt stood up to logical scrutiny. The dogma seems to be > that it allows > you to come up for air and see if you wish to continue, as some of the > instructions could be very long-running. > > To me, that's somewhat analagous to having a phone that > disconnects calls > after a phone-determined number of minutes, so that I can > determine if I > wish to continue the conversation, or a car that turns itself > off after a > car-determined number of miles so that I can decide if I wish > to continue > driving. > > But I've never had a situation in which it was helpful to > have the work I > had coded stop at some processor-determined (and to me > random) point so I > could look around and see if I wanted to continue it. I've > also never seen > any code that did anything other than check the condition code and > immediately branch back to the restartable instrucction on a CC=3. > > Steve > > > On Fri, 6 Jan 2012, McKown, John wrote: > > > This may be a bit off topic, I'm not sure. But I'm curious about the > > design decision on some of the instructions. Basically, the > ones like > > MVCLE which can complete with a CC=3 to indicate that they didn't > > process all the data. This versus "Interruptable > Instructions" such as > > MVCL, which can also be stopped before processing all the > data. In the > > first case, you can simply JO back to the instruction to > continue. In > > the second, things such as the registers are set up > properly and the PSW > > is not updated so that when the system redispatches the work, the > > instruction PSW points to the interrupted instruction and > no branching > > in the user code is required. I hope I'm making sense. > > > > My curiosity is why MVCLE sets the CC, thus forcing user > code to branch > > back. Why not just not update the PSW instruction address > until all the > > data is processed? Still allow the interrupt like MVCL > does, of course. > > I understand why the interrupt is necessary, especially in > a single CP > > environment. Does anybody know? Is it a "millicode" thing? > > > > John McKown > > Systems Engineer IV > > IT > > > > -- Steve Marak > -- [email protected] > >
