IBM 610 workstation computer 3467

I've oft claimed that the non-cache coherency for 801 (from the mid-70s) between the I and D caches for the same processor ... in addition to no provisions for coherency between caches buttociated with different processors ... was reaction to the enormous overhead paid by 370s with their store-thru caches and very strong memory consistency model.

of course, i've also oft claimed that basic 801-risc, extreme hardware simplification was a re-action to the failed effort of FS (from the early 70s) with its significant hardware complexity

there was this internal advanced technology symposium in POK, around the spring of 77. we were presenting 16-way smp design with significantly simplified cache operation ... and the 801 group was presenting their stuff. our presentation included how we were going to modify a standard kernel to operate the 16-way smp machine. one of the 801 group criticized the presentation, claiming that they had examined the standard kernel code and couldn't figure out how it could possibly support 16-way smp operation ... our reply was we were going to modify the code ... i estimated that i could get the initial operation up and running with possibly 6k of code changes and corresponding data structure modifications. people in the 801 group somewhat expressed skepticism that we could make such software code modifications ... even tho we had done it before ... for example misc. postings about VAMPS, a 5-way smp project and more general smp postings

the 801 group then presentation the 801 hardware and CP.r software design. Somewhat as a result of their earlier remarks, I made some number of critical remarks about the significantly simplified 801 hardware. their response was that the 801 design represented hardware-software trade-offs ... that had migrated a lot of hardware features into software ... at the cost of software complexity. for instance, 801 had provisions for a limited number of memory sharing objects (16) and no kernel protection mechanism. the response was that only correct code would be generated by the compilers and that the cp.r system loader had special provisions for loading only correctly generated code. as a result applications programs would have full access to all hardware features including the virtual memory hardware operations ... and could change virtual memory hardware control as easily as applications could change general registers on more familiar hardware designs.

with respect to 370 (as well as separate I & D cache operation), there were other ways of implementing cache consistency ... for instance the reference in this recent post to a 370 clone that implemented separate I & D caches and other improved cache consistency efficiencies

going into the late 80s ... you had LANL taking a COTS version of CRAY high-speed parallel copper hardware channel as hippi standard, LLNL taking a serial coppoer non-blocking switch in a fiber form as FCS (fiber channel) standard, and the guy from SLAC doing a cots-standard version of fiber for latency compensation (including memory and smp cache consistency) as SCI (scallable coherent interface) standard.

we were fortunate enuf to participate in all of the activities.

SCI-cots numa memory consistency was a 64-port design and fundamental SCI issue was moving from a syncronous bus operation (for memory as well as other operations) to a asyncronous bus operation ... somewhat leveraging underlying fiber interconnect that involved dual-simplex operation (i.e. pairs of fiber, with dedicated fiber cable for signals in each direction). since the underlying fiber technology implementation involved dedicated hardware for communication in each direction ... take advantage of the technology that decoupled signals going in one direction with signals going in the other direction to move to an asyncronous protocol and also use the hardware and protocol change to break from syncronous bus operation and use it to address the ever increasing latency delay with syncronous bus operations.

in the early 90s, you saw convex using a HP board with two HP SMP processors in an SCI (64-port) implementation to do the 128-way examplar. You also had both sequent and data general taking a four intel SMP processor board in an SCI (64-port) implementation to do 256-way numa implemenations (we got to do some consulting with both convex and sequent). these were essentially cots implementations with essentially commodity components. sequent had been using their modified dynix (unix) system to support 32-way smp ... using a more convential snoopy bus. part of SCI limitation to 64-port design was being able to have a really cots-commodity standard and off-the-shelf chips. there were a number of efforts in the valley in the mid-90s that looked at custom numa implementations that involved thousands of processor chips. part of the business issues in the 90s was trading off the size of the market for systems involving thousands of processors (needing custom designed proprietary chips), against the much larger market for systems with tens or hundreds of processors (and being able to use off-the-shelf chips).

when we were doing ha-cmp

the executive we reported to moved over to head up somerset ... the joint ibm, motorola, apple, at all effort that i've somewhat characterized to take 801-rios with aboslutely no provisions for cache consistency and redo the whole cache operation (as well as create single chip version) ... and mqarry it with motorola's 88k smp memory bus operation. a little after we left to do other things ... he also left somerset to be president of MIPs (this was after SGI had already bought MIPS) and we did some work with him.

this is somewhat the long-standing joke in the valley about there actually only being 200 people in the industry ... it is just that the same people keep moving around.

--