System360 Hardwired vs. Microcoded 395

an unrelated 195 story ... the 195 had 64 instructions in the pipeline and no branch prediction ... a branch (that wasn't to an instruction already in the pipeline ... aka loop) would cause the pipeline to draine. unless it was very specialized looping codes ... normal instruction stream ran the 195 at about half peak ... because of the frequence of branches.

i got somewhat involved when the 195 product engineers were looking at adding two processor 195 support ... actually the original hyperthreading (that intel processors have recently gone thru a phase); basically a second set of registers and psw and the pipeline would have red-black flag ... indicating which instruction stream stuff was buttociated with. it looked like SMP to software ... but to the hardware it was hyperthreading two instruction streams (dual i-stream). the idea was that if avg. software only kept the pipeline half full because of branches ... that two instruction streams had a chance of keeping the pipeline full ... and achieving peak instruction processing rates (these machines had no caches ... and so were much more sensitive to memory latencies).

however, it was never announced and shipped.

sjr-bld28 still had a 195 in the late 70s ... running heavy batch workload. palo alto science center had an application that they submitted ... but because of the processing queue ... it only got run about once every three months. pasc finally did some work on the application for checkpointing and running under cms batch in the background on their 370-145 vm-cms system. it would soak up spare cycles on the machine offshift and weekends. the elapsed time was slightly better than the 3month turnaround at the sjr 195 (because of the long work queue).

gpd was also running an application on the 195 that was getting excessive long turn arounds ... air bearing simulation ... for design of the new disk floating heads.

we had done this work over in the disk enginnering lab (bldg 14) and product test lab (bldg 15) so that they could run under operating system environment. prior to that, they were running dedicated stand-alone ... they had tried MVS at one time and were getting about 15minutes MTBF when running a single test cell. bullet proofing the operating system I-O subsytem allowed them to operate half-dozen or so test cells concurrently w-o failing.

in any case, the disk product test lab in bldg. 15 tended to get something like the 3rd machine model ... after the first two that cpu engineers were testing with. because of the operating system work for the disk guys ... i would have access to these new machines. when endicott was building the 4341 ... the endicott performance people asked me to do benchmarks on the bldg. 15 4341 (because i had better access to a 4341 than they did in endicott).

anyway, bldg. 15 also got an early 3033. 3033 ran about half the speed of 195 peak ... but about the same as the 195 for most normal workloads. while the disk regression tests in bldg. 15 were i-o intensive ... they bairly blimped the cpu meter. so one of the things we thought would be useful was get the air bearing simulation application up and running on the bldg. 15 3033 ... where it could soak up almost the complete cpu with little compebreastion ... much better than a couple turn-arounds a month on 195 across the street in sjr-28.

minor past posts mentioning the air bearing simulation application:

some past posts mentioning 195

--