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] writes: > I just noticed this thread today. I see there is a lot of speculation > and incorrect statements, so let me try to clarify. > > First, from a processor implementation point of view, there is no > problem with the old-style MVCL/CLCL interruptible instructions. At > appropriate points based on pending interrupts and potential page > crossings leading to an access exception, the millicode exits from > their execution and sets the GRs and PSW appropriately to continue > later. There is no risk of checkstops and it is perfectly well > architected to handle a page fault in the middle, as some have > speculated. > > The reason for the new CC3-style interruptible instructions is very > simple. It was requested by software developers (both internal and > external to IBM). It allows more flexibility in handling other system > activity that is not interrupt driven. So for example, software can > go off and perform some housekeeping while a long running MVCLE is > executing. Note that POPS requires the processor to exit with a CC3 > every (approximately) 4KB processed. So for a multi-page move, the > overhead of starting and stopping can actually slow down the > throughput of the move very slightly. > > I would expect that all future interruptible ops be of the CC3-style. > That said, there will be at least one new interruptible version of an > existing instruction announced soon, however, it is an instruction > never used by the vast majority of software developers. re: http://www.garlic.com/~lynn/2008c.html#67 What happened to resumable instructions? long storage-to-storage operations with lots of accesses back to real storage ... is costing ever increasing number of processor cycles (as mismatch between processor speed and memory speed increases) ... recent reference http://www.garlic.com/~lynn/2008c.html#92 CPU time differences for the same job one could claim that nearly the same effective results (cc3-style) could be achieved for old-style interruptable instructions under program control ... but requiring a few more registers for loop control ... i.e. actual length is kept in other registers and the lengths used for mvcl/clcl instructions being limited (to 4096). there are other thruput issues associated with long storage-to-storage operations; even back to working on original mainframe tcp/ip product implementation. at the time, some of the competitive tcp/ip implementations were looking at 5k pathlength and five buffer copies ... and there was comparison with something like 150k instruction pathlength and 16 buffer copies for lu6.2. at that time, assuming 8kbyte NFS size buffer ... the processor overhead for the 16 (LU6.2) 8kbyte storage-to-storage buffer copy operations exceeded the processor time for the rest of the pathlength. the other factor that some processors provided was cache-bypass, storage-to-storage instructions. Large number of significant sized storage-to-storage operations ... not only has ever increasing significant overhead in terms of processor cycles ... but can have an extremely detrimental effect on cache occupancy (the actual data in most of the buffers has little probability of ever being needed in the cache, but replacing data that would be needed). ---------------------------------------------------------------------- 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
