Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site sdcsvax.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!whuxlm!harpo!decvax!ittvax!dcdwest!sdcsvax!deel
From: deel@sdcsvax.UUCP (Don Deel)
Newsgroups: net.arch
Subject: Re: risc, cisc, and microprogramming
Message-ID: <933@sdcsvax.UUCP>
Date: Mon, 17-Jun-85 02:21:59 EDT
Article-I.D.: sdcsvax.933
Posted: Mon Jun 17 02:21:59 1985
Date-Received: Tue, 18-Jun-85 20:53:43 EDT
References: <557@hou2b.UUCP>
Organization: EECS Dept. U.C. San Diego
Lines: 18

>> A reasonable approach to producing CISC machines, then, would be to have the
>> compiler writers design the instruction set; and to have the instruction set
>> be changeable for different languages.
> 
> funny how things come full circle.  one way to implement the above is to
> have dynamically loaded microprogrammed instruction sets.  but as dave
> paterson mentions in his paper (i think), the difficulty of writing
> and supporting microprograms along with the time penalty in using
> microprogrammed logic (versus hardwired logic) led to the RISC idea.

Actually, there's a well-known large company that's already been around
this dynamically-changing-instruction-set bush....  Anyone from Burroughs
care to comment on how the B1700 worked out after all these years?  For
the uninitiated, the B1700 made (makes?) extensive use of its ability to
dynamically change its mind about which instruction set it was executing.
The operating system used one instruction set, the COBOL machine emulation
used another, etc.  The idea was that different languages have different
needs as far as instructions sets are concerned.