Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site amdahl.UUCP Path: utzoo!watmath!clyde!bonnie!akgua!whuxlm!harpo!decvax!decwrl!sun!amdahl!mat From: mat@amdahl.UUCP (Mike Taylor) Newsgroups: net.arch Subject: Re: risc, cisc, and microprogramming Message-ID: <1710@amdahl.UUCP> Date: Mon, 24-Jun-85 11:46:03 EDT Article-I.D.: amdahl.1710 Posted: Mon Jun 24 11:46:03 1985 Date-Received: Wed, 26-Jun-85 06:17:44 EDT References: <557@hou2b.UUCP> <1691@amdahl.UUCP> <344@spar.UUCP> Organization: Amdahl Corp, Sunnyvale CA Lines: 61 > > >> More complex instructions are implemented by microcode > >> sequences, using a so-called nanostore which maps short microwords > >> into long control words. The most complex instructions are implemented > >> in software, called macrocode. > > It sounds like the macrocode is user-definable, how 'bout the microcode? > In principle, yes. As a matter of policy, customers are discouraged from changing either simply because of the maintenance and diagnostic implications. However, both macrocode and microcode are stored on a hard disk which is part of the console (service processor) subsystem, and loaded during the system initialization sequence. > Does microcode reload (or switch) as well? No. All microcode is loaded all the time. If a particular instruction is not part of the architecture for a given domain, it is logically disabled, but the microcode is still there. > > The cited architecture sounds neat: It looks to me as if, in principle, > users have access to the machine at four levels (assuming the microcode is > rewritable): > > (ordinary) code eg, call a library routine > macrocode eg, execute "machine instruction" FOO, > where FOO traps to a macrocode routine > microcode/hardware eg, execute "machine instruction" BAR, > which actually IS a machine instruction > hardware eg, change some microcode > > Have I got that right? Yes. > > Clever programming software ought to be able to look at an algorithm to > be implemented, and perform an optimization that included moving code > (should we call that "metacode") across all of these level boundaries. > -- > Jay Reynolds Freeman (Schlumberger Palo Alto Research)(canonical disclaimer) Probably. However, in practice, the biggest hits come from optimizing pipeline performance by removing interlocks (i.e. reordering instructions so that they don't interfere) and optimizing cache performance. The 580 has a 5-stage pipeline, so that execute/generate interlocks such as: l 5,4(3,4) a 6,0(5) where the result of the first instruction is needed to calculate the EA of the second, cost three cycles and therefore fixing this common sequence by doing something else helps a lot. Also the 580 has dual caches (Instruction and Operand). The instruction cache is read-only, so that stores to lines in the I-cache are very expensive. Also good code will know how to use the background prefetching properly to reduce cache misses dramatically. Good macrocode software will mostly achieve the theoretical maximum rate of execution (41 MIPS on RX-type instructions) whereas something like 12 MIPS would be more normal when the MVS operating system is running. -- Mike Taylor ...!{ihnp4,hplabs,amd,sun}!amdahl!mat [ This may not reflect my opinion, let alone anyone else's. ]