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]
