Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site spar.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!whuxlm!harpo!decvax!decwrl!spar!freeman
From: freeman@spar.UUCP (Jay Freeman)
Newsgroups: net.arch
Subject: Re: risc, cisc, and microprogramming
Message-ID: <344@spar.UUCP>
Date: Thu, 20-Jun-85 12:50:38 EDT
Article-I.D.: spar.344
Posted: Thu Jun 20 12:50:38 1985
Date-Received: Sun, 23-Jun-85 01:37:38 EDT
References: <557@hou2b.UUCP> <1691@amdahl.UUCP>
Reply-To: freeman@max.UUCP (Jay Freeman)
Organization: Schlumberger Palo Alto Research, CA
Lines: 45
Summary: 

[There's no such thing as the line-ea<*GULP*>]

In article <1691@amdahl.UUCP> mat@amdahl.UUCP (Mike Taylor) writes:

>> The implementation for Amdahl's large S/370 compatible processors
>> might be of interest to this discussion.  [concise description follows
>> -- JF]

>>               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?

>> Hardware support for macrocode includes a second register file

Interesting.  Some of these concepts crop up even in the smallest of
microprocessors, too:  The Z-80 has its "alternate" registers, and the
recently notorious 8<censored>> 86 has 256 different software interrupts,
which many people use as hooks to commonly-used library routines.

>>                                                 Switches between domains
>> simply cause the architectural controls to be reloaded - the cost of this
>> is only slightly higher than any other state switch.

Does microcode reload (or switch) as well?

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?

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)