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: <1691@amdahl.UUCP>
Date: Tue, 18-Jun-85 12:13:31 EDT
Article-I.D.: amdahl.1691
Posted: Tue Jun 18 12:13:31 1985
Date-Received: Thu, 20-Jun-85 20:46:55 EDT
References: <557@hou2b.UUCP>
Organization: Amdahl Corp, Sunnyvale CA
Lines: 37

The implementation for Amdahl's large S/370 compatible processors
might be of interest to this discussion.  While Amdahl has no choice
about the instruction-set architecture (defined by IBM), there is
considerable latitude in implementation.  The primary emphasis in the
machine is fast execution of the common instructions (load, store,
branch, etc.). These can be executed at a sustained rate of one per
cycle (no interlocks or misses) and are effectively implemented
in hardware. 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. Any operation can be defined (including
one already supported in the machine) as being implemented in macrocode.
Loadable tables in the CPU control the effective architecture.
Hardware support for macrocode includes a second register file, and
private memory. When a macrocode-supported operation is detected,
the second register file is set up with the decoded instruction and
operands, and a vectored branch to the software routine is stuffed into
the pipe. This costs very few cycles. The software routine uses the second
register file, avoiding save/restore, and has special support to set up
the return conditions.  This allows new instructions to be readily
added with good performance.  The software routines to support new
instructions can be written using special tools to generate essentially
interlock-free code, which will keep the functional units as busy as
microcode could.  The only real additional cost is cache misses caused
by the software routine which would not happen from microstore.
This ability to redefine the instruction set architecture dynamically
is used to support the simultaneous operation of SCP's requiring different
architectures, for example MVS/370 and MVS/XA (or UTS!). Other facilities
(addressing, I/O message and interrupt routing, timers, etc.) combined
with the above provide a kind of hardware virtual machine support
called the "Multiple Domain Facility (MDF)."  Switches between domains
simply cause the architectural controls to be reloaded - the cost of this
is only slightly higher than any other state switch.
-- 
Mike Taylor                        ...!{ihnp4,hplabs,amd,sun}!amdahl!mat

[ This may not reflect my opinion, let alone anyone else's.  ]