Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!tut.cis.ohio-state.edu!pt.cs.cmu.edu!MATHOM.GANDALF.CS.CMU.EDU!lindsay
From: lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: Workstation Data Integrity
Keywords: interrupts
Message-ID: <10307@pt.cs.cmu.edu>
Date: 23 Aug 90 21:49:51 GMT
References: <1990Aug3.204358.330@portia.Stanford.EDU> <40694@mips.mips.COM> <2399@crdos1.crd.ge.COM> <1990Aug10.171744.9639@zoo.toronto.edu> <14623@drilex.UUCP> <1990Aug20.151438.27121@ecn.purdue.edu>
Organization: Carnegie-Mellon University, CS/RI
Lines: 26

In article <1990Aug20.151438.27121@ecn.purdue.edu> 
	hankd@dynamo.ecn.purdue.edu (Hank Dietz) writes:
>Ignoring interrupts used to be the norm back when polled I/O was
>common.  Many micros ran with interrupts disabled because they could
>interfere with the activities of some "dumb" floppy disk controllers,
>etc., which depended on timing of memory accesses (e.g., the old
>NorthStar floppy disk controller and their BCD floating point board).

When a feature is unused, it often doesn't actually work.  At one
time, Unix was the toughest diagnostic for PDP-11 MMU's...

When my company built one of the first IBM PC clones, we had
mysterious software crashes.  It turned out that no one else was
sending non-maskable interrrupts (NMIs) to their 8088s.  So, we got
to be the people who noticed the NMI hardware bug.  Recall that the
8088 has prefix instructions, which change the addressing of the
following instruction.  An NMI could be honored between the two, but
the interrupt return would "forget" the prefixing.

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?
-- 
Don		D.C.Lindsay