Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!decvax!decwrl!sun!gnu
From: gnu@sun.UUCP (John Gilmore)
Newsgroups: net.arch
Subject: Re: RISC vs. 432 - (nf)
Message-ID: <362@sun.UUCP>
Date: Tue, 29-Nov-83 16:02:00 EST
Article-I.D.: sun.362
Posted: Tue Nov 29 16:02:00 1983
Date-Received: Wed, 30-Nov-83 04:01:47 EST
References: akpcb.9253
Lines: 18

The guy who said "Where is memory management?  Finish the job!" about
the RISC should look again at the 432.  It won't even talk to standard
memory chips without a special "packet bus controller" chip.
Personally I'd rather build an MMU from standard parts than I would a
packet bus controller.  Our 68010 MMU runs 400ns cycles, drives standard
64K rams, and doesn't add any wait states.

The RISC takes a trap when its register stack gets close to full.
The trap handler saves 1/2 the stack or so in memory and resumes the
user program.  There is some tuning that can be done in the stack
management software to minimize the number of "page faults" here;
one of Patterson's papers explains in more detail.  Remember that the
registers on chip are designed to be a cache.  Stack faults occur when
the hit rate drops below 100%.

Calling a subroutine to multiply doesn't cause stack overflows, since
it returns before it calls anything else.  Only deeply nested procedure
calls cause stack faults.