Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!glacier!mips!mash
From: mash@mips.UUCP (John Mashey)
Newsgroups: net.arch
Subject: Re: Addressing modes
Message-ID: <363@mips.UUCP>
Date: Fri, 28-Feb-86 00:09:56 EST
Article-I.D.: mips.363
Posted: Fri Feb 28 00:09:56 1986
Date-Received: Sat, 1-Mar-86 18:32:58 EST
References: <187@anwar.UUCP> <1441@gitpyr.UUCP> <700@minster.UUCP>
Organization: MIPS Computer Systems, Mountain View, CA
Lines: 26

>M C Atkins, ukc!minster.uucp!martin writes:
> 	It is interesting to note that Acorn removed delayed branches when
> virtual memory support was added to the processor, because it wasn't clear
> how to restart the instruction following a branch! Perhaps some of the
> other RISC machines have solved this, if they have I wonder if it was simple
> enough to be worth it, or not? Does anyone know?

1) Other RISC machines have solved this.
2) Careful design is needed, but it turns out that the same careful design
is needed to make heavily-pipelined machines work efficiently anyway,
with clean exception handling, i.e., the virtual memory problem is just
one example of a general class. 
3) This can be done fairly simply:
	a) On an exception caused by an instruction in a branch-delay slot:
	b) suppress the branch & the following instruction.
	c) Point a register at the branch, not at the instruction following.
	d) Set a magic bit that says that's what happened (a convenience).
	e) Take the exception.
	f) on returning from the exception, re-execute the branch.
4) Was it worth it? Yes.  With current technology, if you want to do 
heavily-pipelined, high-performance designs, delayed branches are Good Things.
-- 
-john mashey
UUCP: 	{decvax,ucbvax,ihnp4}!decwrl!mips!mash
DDD:  	408-720-1700
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086