Path: utzoo!dciem!array!colin
From: colin@array.UUCP (Colin Plumb)
Newsgroups: comp.arch
Subject: Re: MIPS R[236]000 interrupts (was Workstation Data Integrity)
Message-ID: <604@array.UUCP>
Date: 27 Aug 90 21:27:16 GMT
References: <1990Aug3.204358.330@portia.Stanford.EDU> <40694@mips.mips.COM> <1990Aug25.014235.6894@mozart.amd.com> <26200@mimsy.umd.edu>
Organization: Array Systems Computing, Inc., Toronto, Ontario, CANADA
Lines: 29

In article <26200@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes:
> (Surely the 29000 has some places where the architecture book says `if
> you do this, you lose'?)

In the 29000's stack cache, there are four pointer registers: the base
stack pointer (which all local register references are relative to)
and three indirect registers, which are most often used to pass
register addresses to trap handlers.  For example, all the defined-but-
unimplemented opcodes do local register mapping and protection checking
on the register operand fields and, if all is well, bung the results
into the three indirect pointer registers for use by the emulator.

If you set any of these registers, and then try to use it implicitly
(by accessing a local register or register 0, which means "wherever the
indirect pointer indicates) the next instruction, you may get the old
value (if nothing intervened) or the new one (stall or interrupt).
After one cycle, it's safe.

This could be interlocked (you just have to stall the instruction in
decode/register fetch), but I think the designers felt it wasn't
worth the bother.  If you promised a big enough order, though...

There are also a couple of things that are supervisor-only and pretty
low level that have some latency.  But that's the only user-visible
one.

Has anything changed on the 29050, guys?
-- 
	-Colin