Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/17/84; site think.ARPA Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!ihnp4!think!rose From: rose@think.ARPA (John Rose) Newsgroups: net.arch Subject: Re: RISC cache vs CISC u-code Message-ID: <4521@think.ARPA> Date: Fri, 7-Mar-86 12:53:00 EST Article-I.D.: think.4521 Posted: Fri Mar 7 12:53:00 1986 Date-Received: Sat, 8-Mar-86 23:33:37 EST References: <136@pyramid.UUCP> <570@imag.UUCP> Reply-To: rose@think.UUCP (John Rose) Organization: Thinking Machines, Cambridge, MA Lines: 30 In article <136@pyramid.UUCP> dan@.UUCP (Dan Sobottka) writes: > >... The space that is freed up on a RISC chip by having >little if any u-code ROM can be used for more cache. ... > In article <570@imag.UUCP> berger@imag.UUCP (Gilles BERGER SABBATEL) replies: >OK, but what when the system is multiprogrammed? Frequent swaps between >processes aren't likely to break the cache efficiency? Interesting: To maintain the functional correspondence between CISC ucode ROM and RISC fast memory, we'd need something like shared libraries for low-level routines. The Unix practice of copying library code into every executable image would cause gratuitous flushing of cached "milli-code", only to bring in nearly-identical code for the next process. That hard-to-change ROM or WCS has its good points :-). What's needed for a RISC is a slowly-changing set of libraries at well-known addresses, and--more broadly-- software engineering practices which discourage re-invention! The CISC's have context-switch problems too--look at how the stack-frame formats have grown in the 68k family (although they seem also to be paying for early design bugs). (Co-)processor registers are a cached data memory which must be flushed (saved) and reloaded (restored). -- ---------------------------------------------------------- John R. Rose, Thinking Machines Corporation, Cambridge, MA 245 First St., Cambridge, MA 02142 (617) 876-1111 X270 rose@think.arpa ihnp4!think!rose