[email protected] (Paul Gilmartin) writes: > It began nearly a half century ago with microcode implementation of S360 > models, and only slightly later, W. M. Waite's Mobile Programming System. > Nowadays: > > microcode->millicode->PR/SM->VM->JVM->byte code > > How many layers have I neglected? Hercules is a confluent branch.
note that the original hypervisor was done by Amdahl in something called macrocode ... which was a layer above microcode and very close to standard 370. In the mid-70s, I had been sucked in by Endicott to help with microcode assists for 138/148 ... vertical microcode machine that avg. 10 microcode instructions per 370 instruction (not that different from the various intel based simulators). Was told that there were 6kbytes available for microcode and kernel instruction sequences dropped into microcode on nearly byte for byte ... so was to identify the top 6kbytes worth of kernel instruction sequences ... that would be moved to microcode for a 10:1 performance improvement. Old post with results of analysis ... turns out top 6kbytes of instruction sequences accounted for 79.55percent of kernel time. http://www.garlic.com/~lynn/94.html#21 In any case, I was giving presentations on the effort at the monthly bay area user group meetings (BAYBUNCH) held at SLAC ... and the Amdahl people were pumping me for additional details at the get togethers held at local watering holes after the meetings (this was before hypervisor was announced). After hypervisor was announced ... the 3090 was eventually forced to respond with PR/SM. Part of the issue was that 3090 was horizontal microcode machine ... which was enormously more difficult to program for than 370 instructions ... and was much more difficult. I had been told that Amdahl had original evolved macrocode to respond to the enormous number of architecture tweaks that IBM had been doing on their "high-end" (vertical microcode machines) starting with the 3033 and continued through 3081 (macrocode used to drastically reduce the effort needed to respond). I've mentioned before ... during FS period ... internal politics were killing off 370 efforts (the lack of 370 products during this period is credited with giving clone processor makers a market foothold) ... then when FS imploded there was mad rush to get 370 products back into pipeline. POK kicked off 3033 (initially 168 logic remapped to 20% faster chips) and 3081 in parallel ... more detailed account here: http://www.jfsowa.com/computer/memo125.htm since that neither 3033 or 3081 were really that competitive, the architecture tweaks would supposedly give the machines competitive advantage ... many were claimed to be performance improvements ... but folklore is that many actually ran slower (than native 370). Part of the issue is the high-end, horizontal microcode machines were profiled in terms of avg. machine cycles per 370 instruction ... by 3033, this was done to cloe to one machine cycle per 370 instruction (370 instruction move to microcode couldn't see the 10:1 improvement seen on the vertical microcode machines). In anycase, it sort of drove Amdahl into creating macrocode as a way of drastically simplifying being able to respond to the increased architecture tweaking. The other factor was that part of the mad rush after FS failure, the head of POK managed to convince corporate to kill off vm370, shutdown the development group and move all the people to POK ... or otherwise POK would be able to make mvs/xa ship schedule several years (Endicott managed to save the vm370 product mission, but had to reconstitute a development group from scratch). Part of the POK activity was creating a XA vritual machine VMTOOL (to support MVS/XA development) that was never intended to be made available to customers. After initial introduction of 370/xa and MVS/XA ... there was very slow uptake ... customers continued to run 3081s in 370 mode with MVS (or vm370). The decision then was to release the VMTOOL as the "migration aid" ... allowing customers to run both MVS and MVS/XA concurrently on the same machine as aid to migration. Amdahl solution was the hypervisor which provided the same capability ... but much more efficiently. IBM eventually responded with PR/SM on the 3090 ... but it was much greater effort because it required being all done in native horizontal microcode. The POK(/Kingston) group then pushed very hard to have migration aid morph into standard VM/XA product. The problem was that VMTOOL had only been developed for MVS/XA development and lacked lots of function and performance features (especially compared to vm370 of the period) and was going to require lots of resources, effort and time to bring up to compareable level of vm370. Somebody at an internal datacenter had made the changes to vm370 to provide full function 370/XA support ... which would have been trivial to release. In the internal politics between POK and Endicott, POK managed to prevail and the vm370 370/xa was shelved (never to be heard of again) and the significant effort to bring VMTOOL (migration aid) up to vm370 product level, was launched. -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
