Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site fortune.UUCP
Path: utzoo!linus!philabs!seismo!harpo!eagle!mhuxl!houxm!ihnp4!fortune!lee
From: lee@fortune.UUCP
Newsgroups: net.arch
Subject: (Re: x 5) Risc registers vs. cache
Message-ID: <1948@fortune.UUCP>
Date: Tue, 13-Dec-83 13:32:28 EST
Article-I.D.: fortune.1948
Posted: Tue Dec 13 13:32:28 1983
Date-Received: Thu, 15-Dec-83 01:28:19 EST
Organization: Fortune Systems, Redwood City, CA
Lines: 19


	actually, I would think that you would still want a "register" type 
	opcode, even if external memory was a fast as internal memory
	since register specification takes fewer opcode bits than direct
	(or pc relative?) specification...or what?

All register references eventually lead to memory accesses.
The data must be saved somewhere.  For many HHLs, stack pointer
and frame pointer relative addressing can do most of the job,
unless you consider SP and FP as registers also.  The problem
is that you have to copy data in/out of stack frames from/to 
registers, and many compilers assume that registers are faster.

If you think I am in favor of RISC, don't get the wrong idea.
I am merely trying to point out the differences.  RISC compilers
generate larger codes to do the same thing, and somebody has to
do the dirty job of interfacing the machine dependent part.

	Ed Lee
	{amd70, ihnp4, harpo}!fortune!lee