Anne & Lynn Wheeler <[EMAIL PROTECTED]> writes: > they were looking at doing things on a chip. I don't know if it is > conflict or complement. Some of the people worked on Vamps and would > like to do CMS but I don't think thier chips are that large (yet?). > xxxxxx (who used to be at Cambridge) and yyyyyy (who was in > Burlington). Burlington is still a strategic MVS shop with no VM.
ref: http://www.garlic.com/~lynn/2006b.html#xx another blast from the past note, i've been redacting names to protect the guility From: wheeler at sjrlvm1 Date: 9/16/82 13:57:14 Subject: bounce lock re: bounce lock; The VAMPS design had only one processer (at a time) executing CP code ... all the other processors would be executing virtual machines. CP processor would execute microcode dispatcher instruction to add virtual machine to runnable list. CP would then see if there was anymore work to do & then execute dispatch instruction. Dispatch instruction would either pull 1st available virtual machine off the dispatch queue & execute it or enter wait state. All the other enginess, when not executing a virtual machine would sit idle waiting for something to be placed on the dispatching queue. When a CP service was required that could not be handled by the extended microcode assist, control would attempt to enter CP. If there was already processor in CP, this resulted in a CPEXBLOK being queued for the CP processor and control transferring to execute another virtual machine on the dispatch list. The microcode queuing of this CPEXBLOK would cause a special interrupt in the CP processor to dequeue it. VAMPS was effectively killed in Sept. of 1975. In Nov. of 1975, I began adapting the VAMPS design to a non-microcode Lexington (168AP). The concept of a CP processing interrupt, I replaced with the 'single system lock' design. The innovation that I contributed to the single system lock design, was that a processor requiring CP services that were not equivalent to the extended microcode function (i.e. those things that potentially required global resources) ... would go for the single system lock ... rather than spinning on that lock ... like other single system lock designs did ... it would "bounce" off the lock, queue the CPEXBLOK and go off to the dispatcher to find another virtual machine to execute. From: wheeler at sjrlvm1 Date: 9/16/82 14:07:34 Subject: bounce lock "bounce lock" .... My term for the design is a bounce lock reflecting what happens in the processor executing the instruction (i.e. the processor bounces off the system lock and goes looking for something else to do). The development team eventually began to refer to it as a "defer" lock ... reflecting their orientation as a process/tread (rather processor) orientated system program ... i.e. the virtual machine (or process) request was queued for latter execution. I believe "defer" lock is an incorrect name since the single system lock is a processor orientated function (i.e. it prevents a processor from entering "protected" cp code). It does not directly affect the state of the virtual machine ... My orientation when I created the design was to solve a processor execution problem ... and therefor a nomenclature orientation representing what the processor has to do ... not what is happening in. ... snip ... some VAMPS (& SMP) background. a lot of the stuff that i had "fastpathed" in cp67 was targeted to microcode in VAMPS (interrupt handling, dispatching, and some process specific stuff that didn't affect global system resources). in the translating VAMPS to a software implemention, a minimal amount of kernel code was parallelized ... leaving the vast majority of kernel code "protected" by the single kernel lock. the majority of the code was not parallelized ... but high-performance, critical parts of the kernel was parallelized somewhat drawing on experience gained by doing ecps. the trade-off was to get nearly all of the thruput from a highly parallelized kernel with only slightly more work than doing a kernel spin-lock implementation (which was common in the period). one of the emails is specifically about the semantic appropriateness referring to the single lock as a "bounce lock" (my original nomenclature) or a "defer lock" (used later). various collected postings mentioning vamps http://www.garlic.com/~lynn/subtopic.html#bounce note that charlie had done quite a bit of work at the science center http://www.garlic.com/~lynn/subtopic.html#545tech on fine-grain locking and highly parallelized smp. that is where the invention of compare&swap instruction came out of (mnemonic chosen because CAS are charlie's initials). http://www.garlic.com/~lynn/subtopic.html#smp -- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
