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.  ]