Misuse of word "microcode" 101

Peter Flbutt I

note also in the low-end 360s, not only was 360 instruction set implemented using the instruction set (microcode) of the native processing engine ... but they also had integrated channels ... which had separate microcode and the processing engine was time-shared between the 360 processing code and the channel processing code. the 360-65-67 and above had separate channel processing boxes.

the other issue was that the channel program interface was syncronous. there was a language & sequence of instructions called channel programs that could do things like conditional and looping. the 360 processing had the start i-o (SIO) instruction that tell the channel processer to initiate a channel program. the channel would indicate when a channel program was finished with an i-o interrupt to the processor.

couple issues in 370 addressed was

1) introduced siof ... start i-o fast, in 360 the sio instruction went all the way out to the controller and device and came back ... which could be a couple hundred feet away ... which worst case could be tens of microseconds. siof would handshake with the channel and return ... with the initial contact of the controller and device proceeding asyncroncrounsly

2) DASD CKD operation defined a syncronous outboard record search operation that dedicated the channel and controller while the disk revolved. A new "sector" disk operation was defined that would disconnect the device from the controller and channel during rotation until a specific sector location had been reached ... at which time it (attempted) reconnect. mist posts about CKD disk operational characteristics

3) there could be a (relative) large amount of latency between the time the device signaled completion, the processor accepted the interrupt, handled any interrupt processing and finally got around to redriving the device with any queued channel program. the new 2305 fixed-head disk introduced the concept of multiple device addresses. the 2305 fixed-head disk had eight separate device address .... each could have a pending channel program initiated; helping mask the standard device redrive latency delay.

the low-end 370s continued the implementation of integrated channels ... i.e. the same native processor having different set of time-shared native programming ... one implementing channel processing and one implementing 370. for some processors there was even integrated controller implemention ... where there was additional native processor programming that also implemented device controller function.

for 303x line, the 370-158 was taken and a dedicated processor was configured that only contained the integrated channel processing programming. this was called a channel director. the 3031 was a 370-158 processing engine with only the native processing engine programming support for the 370 instruction set. there was a second native 370-158 processing engine that was dedicated channel processing programming (aka, a default 3031 uniprocessor was actually a pair of 370-158 processors sharing the same memory, one dedicated to executing the channel processing native code and one dedicated to executing the 370 processing native code). a 3032 was a 370-168 repackaged to use a channel director (370-158 native engine with only channel processing native code). A 3033 processor started out being a 370-168 wiring diagram remapped to faster chip technology (and configured to utilize 303x channel director).

the avg. 3031 mip processing benchmarks showed significant 370 processing thruput because the native engine was no longer being time-shared between executing the 370 native programming and the channel native programming.

some past 158 & 3031 comparison postings mainframe?" machine was it? machine was it? machine was it? powerful a machine was it? 11-750)

while 303x channel processing was outboard to dedicated processing, there was still additional latency involved in handling the SIOF instruction and there was all sorts of syncronous latency with handling i-o interrupts and redriving queued device i-os (general case, not just 2305 fixed-head disk) as well as the effects on cache hit ratios of having asyncronous i-o interrupts.

as part of rewritting i-o subsytem for the disk engineering lab to significantly improve the reliability and availability ... essentially in an extremely hostile i-o environment attempting to test devices under development;

i had also highly optimized the pathlength for device i-o redrive latency ... however there still some latency and there was still the cache hit effects of asyncronous i-o interrupts.

370-xa ... besides introducing 31-bit addressing mode and expanding on the dual-address space architecture also introduced a queued i-o interface. it was now possible to define a queued interface of pending channel programs and queued interface completed i-o operations .... this was an attempt to mitigate the the cache effects of having asyncronous i-o interrupts as well as the latency in getting around to redriving a device with pending channel program. this required a more sophisticated and more powerful channel subsystem operation. among other things ... since a lot of the low-level processing activity was masked from the main processor ... there was a lot more administrative, timing, and capacity planning information that had to be kept by the channel subsystem processor ... and available for sampling-interrogating by the main operating system.

misc. past posts related to benchmarking, performance tuning and the early days of capacity planning:

misc. past posts on multi-address space addressing architecture? workstation? why the machine word size ...) Adventure) Parity - why even or odd) to Fix about z900 from IBM for small clusters interconnect addressing addressing survey virtualization in general