d10jhm1@[EMAIL PROTECTED] (Jim Mulder) writes: > "Military secrets are the most fleeting of all." -- > Spock, The Enterprise Incident, stardate 5027.4, Episode 59 > > The second most fleeting might be the marketing advantage > provided by microcode assists. What one vendor can do in > microcode, another usually can replicate in short order. So > any such advantage from these assists would have run its course > a few decades ago. > > On horizontally microcoded machines, it was possible > to obtain a performance benefit in some cases by providing > microcode which could implement a frequently used code sequence > faster by using some hardware parallelism that was not available > to the general instruction set. That is not the case on IBM processors > of the past decade, and in fact using the lock assists had become > slower than not using them. there were some comments at the time that the mvs/se microcode assists were part of the motivation for amdahl's macrocode ... allowing them to track various fluctuations in hardware architecture (much simpler than it took to do the original by using a slight variation on 370 assembler) .... w/o having to resort to the difficulty and complexity of low-level horizontal microcoding. this then contributed to amdahl being able to relatively easily implement hypervisor sup****t ... much easier than it took to create pr/sm response on the 3090. the "original" (vm/370) microcode assists were in two forms ... those things that implement the "virtual machine" rules for execution of supervisor instructions ... avoiding the interrupt and context switch overhead interrupting into the vm370 supervisor. the other big benefit was on the "vertical" microcode machines .... initially 138/148 ... where there as an avg. of 10 microcode instructions executed for every 370 instruction ... and vm370 kernel pathlengths was dropped into microcode on nearly a 1-for-1 instruction basis (obtaining a 10:1 performance improvement). old post on selecting the parts of vm370 kernel that were moved into the kernel (criteria was that 148 had 6k bytes of available microcode space ... so the objective was to select the highest used 6k bytes of vm370 kernel instructions): http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assit the issue with the high-end horizontal microcode machines was that various optimizations by the time of 3033 achieved nearly 1:1 parity between horizontal microcode and 370 instructions (370 instruction execution had gotten so efficient that there was nearly no difference between implementing the function in 370 instructions vis-a-vis implementing in microcode) ... aka for the "ECPS" class of things done originally for virgil/tully (138/148) would see no difference on 3033 (and later horizontal microcode) machines. that mostly left doing things in microcode/(macrocode) that could avoid overhead if implemented in straight machine instructions (like adding "virtual machine rules" to the execution of supervisor state instruction execution) ... aka things like hypervisor and pr/sm. misc. past posts mentioning macrocode: http://www.garlic.com/~lynn/2002p.html#44 Linux paging http://www.garlic.com/~lynn/2002p.html#48 Linux paging http://www.garlic.com/~lynn/2003.html#9 Mainframe System Programmer/Administrator market demand? http://www.garlic.com/~lynn/2003.html#56 Wild hardware idea http://www.garlic.com/~lynn/2005d.html#59 Misuse of word "microcode" http://www.garlic.com/~lynn/2005d.html#60 Misuse of word "microcode" http://www.garlic.com/~lynn/2005h.html#24 Description of a new old-fa****oned programming language http://www.garlic.com/~lynn/2005p.html#14 Multicores http://www.garlic.com/~lynn/2005p.html#29 Do***entation for the New Instructions for the z9 Processor http://www.garlic.com/~lynn/2005u.html#40 POWER6 on zSeries? http://www.garlic.com/~lynn/2005u.html#43 POWER6 on zSeries? http://www.garlic.com/~lynn/2005u.html#48 POWER6 on zSeries? http://www.garlic.com/~lynn/2006b.html#38 blast from the past ... macrocode http://www.garlic.com/~lynn/2006c.html#7 IBM 610 workstation computer http://www.garlic.com/~lynn/2006c.html#9 Mainframe Jobs Going Away http://www.garlic.com/~lynn/2006c.html#24 Harvard Vs Von Neumann architecture http://www.garlic.com/~lynn/2006c.html#40 IBM 610 workstation computer http://www.garlic.com/~lynn/2006e.html#15 About TLB in lower-level caches http://www.garlic.com/~lynn/2006h.html#30 The Pankian Metaphor http://www.garlic.com/~lynn/2006j.html#32 Code density and performance? http://www.garlic.com/~lynn/2006j.html#35 Code density and performance? http://www.garlic.com/~lynn/2006m.html#39 Using different storage key's http://www.garlic.com/~lynn/2006p.html#42 old hypervisor email http://www.garlic.com/~lynn/2006t.html#14 32 or even 64 registers for x86-64? http://www.garlic.com/~lynn/2006u.html#33 Assembler question http://www.garlic.com/~lynn/2006u.html#34 Assembler question http://www.garlic.com/~lynn/2006v.html#20 Ranking of non-IBM mainframe builders? http://www.garlic.com/~lynn/2007b.html#1 How many 36-bit Unix ****ts in the old days? http://www.garlic.com/~lynn/2007d.html#3 Has anyone ever used self-modifying microcode? Would it even be useful? http://www.garlic.com/~lynn/2007d.html#9 Has anyone ever used self-modifying microcode? Would it even be useful? http://www.garlic.com/~lynn/2007j.html#84 VLIW pre-history http://www.garlic.com/~lynn/2007k.html#74 Non-Standard Mainframe Language? http://www.garlic.com/~lynn/2007n.html#96 some questions about System z PR/SM http://www.garlic.com/~lynn/2007o.html#42 mainframe performance, was Is a RISC chip more expensive? http://www.garlic.com/~lynn/2008c.html#32 New Opcodes http://www.garlic.com/~lynn/2008c.html#33 New Opcodes http://www.garlic.com/~lynn/2008c.html#42 New Opcodes http://www.garlic.com/~lynn/2008c.html#80 Random thoughts
