John, Of course I can't prove it, but that was my exactly my conclusion also: it was easier to implement that way. (Though not, in my opinion, desirable.)
Steve On Fri, 6 Jan 2012, McKown, John wrote: > 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] > > > > > -- Steve Marak -- [email protected]
