The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
[EMAIL PROTECTED] (Paul Gilmartin) writes: > o Page faults? How are page faults handled for resumable > instructions? Is a fault generated for any page in the > range of either operand, with the OS attempting to stage > both, or does a fault possibly for each resumption. the resumable instructions were storage-to-storage operations with address and length specified in registers for both source and destination. requirement was that the registers be appropriately updated as the instruction proceeded ... so that on any interrupt, all registers will have been appropriately updated (and therefor on restart, the instruction would resume from the appropriate position). the problem wouldn't so much the psw address being correct on the interrupt ... the issue was that all registers actually reflecting the correct values (i.e. working copies of the values weren't squirreled away in other hardware location). prior to mvcl/clcl ... instructions would pretest start and end location for both (2k) storage protection and 4k page fault. with mvcl/clcl, the testing had to be done incrementally for every byte processed (although there were later optimizations that would do it in larger blocks, and then fall back to per byte mode ... for any residual). highly pipelined machines gets into lots of issues with what are the current (visable) register contents at any point in time (lots of different parallel executing circuits with possibly their own register values). newer machines also have extensive hardware ras with status checkpoint and instruction retry (to mask various kinds of transient hardware glitches) ... instructions that execute incrementally aggrevate status checkpointing overhead (and instruction retry logic). i actually ran into early problem with 370/125 implementation on vm370. at vm370 boot (on real machine), it would load maximum values into mvcl (initialized to clear storage) and kick it off, it would zero all of real storage ... interrupting when it hit the end of real storage. early 370/125 microcode had a "bug" where it was still "pretesting" origin & end for mvcl/clcl and aborting the instruction before starting ... which to vm370 made it appear like there was no real storage. vm370 was originally targeted at supporting 256kbyte machines ... prior to announce of 370/125 ... and was never announced for 370/125. at this point, a customer had requested assistance in getting vm370 running on 370/125. while vm370 had non-swappable kernel support ... the amount of fixed kernel had somewhat bloated between the original announce ... and this point ... which also significantly aggrevated vm370 operation in 256k real storage. recent post referring to having done lots of work in 60s as undergraduate on cp67 ... much of which got picked up and shipped in the product: http://www.garlic.com/~lynn/2008c.html#65 No Glory for the PDP-15 one of the other things that i had done for cp67 in the 60s was making portions of the kernel pageable ... which wasn't shipped in cp67 product ... but was picked up for vm370 product. however, since the initial release ... things had gotten lax between what was in the fixed kernel and what was in the pageable kernel. by the time of the customer vm370 370/125 request to the science center http://www.garlic.com/~lynn/subtopic.html#545tech I had moved much of the cp67 work (that had been dropped in the cp67 to vm370 morph) as well as adding lots of new stuff ... and was supplying highly modified vm370 systems to large number of internal datacenters. some old email references: http://www.garlic.com/~lynn/2006v.html#email731212 http://www.garlic.com/~lynn/2006w.html#email750102 and part of getting vm370 up and running on 370/125 also involved going thru lots of kernel infrastructure and significantly reducing the fixed storage footprint for running in 256kbyte real storage machine. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
