Documentation for the New Instructions for the z9 Processor

recent discussion of one of the original efforts along this line

description of selection process

there were two types of buttists ...

1) those that changed the rules for privileged instruction end ... so it recognized virtual machine mode ... and didn't have to interrupt into the kernel (with the buttociated state-switching overhead) for simulation

2) the new type in ECPS ... which took sections of kernel code and dropped them into the 138-148 microcode ... replacing them with new op-code.

the big issue in the low and mid range machines was that the vertical microcode implementation of 370 was running an avg. of about ten microcode instructions per 370 instruction. the ecps effort got close to 1:1 move of 370 instructions to microcode for a performance speed up of 10:1.

things were a little different in the high-end machines which tended to have horizontal microcode and later direct hardware implementation. rather than avg. microcode instructions per 370 instruction ... things tended to be measured in avg. machine cycles per 370 instruction. 370-165 avg. 2.1 machine cycles per 370 instructions. hardware & microcode enhancements for 370-168 reduced that to avg. 1.6 machine cycles per 370 instruction. further optimization on the 3033 got it down to around one machine cycle per 370 instruction (i.e. 370 instructions were effectively running at almost hardware speed, closing the performance difference between direct microcode instructions and 370 instructions).

things got more complicated on 3081. other than hardware directly executing privilege instructions using virtual machine rules (and eliminating all the state save-restore stuff involved with interrupting into the kernel) ... one-for-one movement of 370 kernel instructions to microcode could be really embarresing ... to expand 3081 capability even with limited microcode store, the 3081 would page some microcode ... using a FBA piccolo disk drive managed by the service processor. if the new microcode happened to be of the paged variety, it would be significantly slower than the kernel 370 instruction implementation.

in this time-frame, amdahl introduced a new mechanism for addressing the opportunity. high-end (acutally most) microcode tended to be difficult to code and debug (besides having less & less performance differential vis-a-vis 370 instructions). one of the few remaining performance differentials in high-end pipelined machines between 370 and microcode was the 370 architecture allowing self-modifying instructions (some amount of pipeline degradation checking to see if the previous instruction had modified the current instruction). amdahl introduced "macrocode" which was essentially the 370 instruction set with 1) restriction eliminating self-modifying instruction support and 2) its own registers and end environment. Amdahl used macrocode to implement its hypervisor end environment (effectively an optimized subset version of what might be found in hypervisor kernel) ... which IBM evneutally responded to with PR-SM ... precursor to the current LPAR support.

lots of collected m'code posts

--