Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!ptsfa!lll-lcc!pyramid!prls!mips!mash
From: mash@mips.UUCP
Newsgroups: comp.arch
Subject: Re: Interrupt vectors.
Message-ID: <438@winchester.UUCP>
Date: Fri, 5-Jun-87 03:51:23 EDT
Article-I.D.: winchest.438
Posted: Fri Jun  5 03:51:23 1987
Date-Received: Sun, 7-Jun-87 01:51:56 EDT
References: <7408@boring.cwi.nl>
Reply-To: mash@winchester.UUCP (John Mashey)
Organization: MIPS Computer Systems, Sunnyvale, CA
Lines: 30

In article <7408@boring.cwi.nl> jack@cwi.nl (Jack Jansen) writes:

>I was just wondering wether any of the fancy new machines (MIPS,
>AMD) did anything about the stupid way interrupts are done in
>most modern machines....<discussion of evils thereof>...

>Now, the sensible thing for the hardware to do seems to be to
>provide one vector, and push the interrupt number along with the
>PC, PSW and what have you.

>Is this scheme implemented on any machine?

Sure. The MIPS R2000 has 3 vectors: RESET, User TLBMISS (software handler
for TLBmisses for the most frequent case, i.e., frequency makes it
the only one worth a special case), and everything else.  It does
what you say.  See IEEE Compcon, March 1986, SanFrancisco, 138-143.
Doing an interrupt is basically (about 2 cycles):
	1) Shutdown the pipeline, canceling any write-back necessary.
	2) SAve previous kernel/user bit and interrupt-inhibit bits,
	   set current ones to kernel and inhibited.
	3) Save exception Pgm Cntr into on-chip register.
	4) Set a Cause field in another register.
	5) (In some cases) set useful values into some other special registers
	6) Transfer control to the kernel interrupt vector.

The general scheme is not uncommon in RISC designs.
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	{decvax,ucbvax,ihnp4}!decwrl!mips!mash, DDD:  	408-720-1700, x253
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086