Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!mips!decwrl!ucbvax!bloom-beacon!jfc
From: jfc@athena.mit.edu (John F Carr)
Newsgroups: comp.arch
Subject: Re: Workstation Data Integrity
Keywords: interrupts
Message-ID: <1990Aug27.014937.8802@athena.mit.edu>
Date: 27 Aug 90 01:49:37 GMT
References: <14623@drilex.UUCP> <1990Aug20.151438.27121@ecn.purdue.edu> <10307@pt.cs.cmu.edu>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: Massachusetts Institute of Technology
Lines: 20

In article <10307@pt.cs.cmu.edu> lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay) writes:

>While we're on the subject, RISC machines with branch delay slots
>have a similar problem.  Of course, the easy instruction decoding
>means that they can push some of the work into the interrupt
>handlers.  Does anyone want to describe how their favorite machine
>did this?

The IBM RT doesn't allow interrupts between a branch-and-execute and the
following instruction.  This seems to me the best solution (doesn't require
any special logic in the interrupt handling software or in the hardware to
restart after an interrupt).

The new IBM RISC machine avoids problems with branch delay and interrupts
by not having delay slots.  Instead, instruction prefetch follows branches.
I think the 68040 also does this.


--
    --John Carr (jfc@athena.mit.edu)