Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!gem.mps.ohio-state.edu!usc!apple!mips!mash
From: mash@mips.COM (John Mashey)
Newsgroups: comp.arch
Subject: Re: (Im)precise exceptions
Message-ID: <28764@winchester.mips.COM>
Date: 4 Oct 89 17:34:53 GMT
References: <2353@oakhill.UUCP> <261500010@S34.Prime.COM> <34701@apple.Apple.COM> <2451@wyse.wyse.com> <477@ctycal.UUCP> <265@ssp1.idca.tds.philips.nl> <4796@orca.WV.TEK.COM> <27659@shemp.CS.UCLA.EDU> <269@ssp1.idca.tds.philips.nl>
Reply-To: mash@mips.COM (John Mashey)
Organization: MIPS Computer Systems, Inc.
Lines: 65

In article <269@ssp1.idca.tds.philips.nl> roelof@idca.tds.PHILIPS.nl (R. Vuurboom) writes:
>In article <27659@shemp.CS.UCLA.EDU> marc@oahu.UUCP (Marc Tremblay) writes:
>
>>Fortunately the 88000 provides special registers which contain the
>>necessary information for the software to complete an instruction
>>that caused an imprecise exception.
>		^^^^^^^^^
>
>Ok, this term has been bandied about on the net before. When (precisely :-)
>is an exception imprecise? When is it precise? Does it affect ones handling
>of the exception? When does one need to differentiate between the two?

I'm not sure this is a binary issue [precise vs imprecise], although

An exception is precise if:
	on entry to the exception handler, you get a program counter
	(or equivalent) that points to an instruction, such that:
		a) All instructions before that instruction have been
		successfully completed.
		b) That instruction, and all after, have had no effect
		on the state of the machine.

An exception is clearly imprecise if an exception in an earlier instruction
happens AFTER later instructions have irreversably changed the state
of the machine.  For example, on old 360/67s, addressing errors (S0C4s,
for those whose memories go back that far) caused by stores, were 
imprecise.  I.e., if you did a store to protected memory, since the
protection keys were implemented as part of the memory, in effect,
you could complete the next instruction, if it were short, before you
found out about the addressing error:
	st	r0,X
	sr	r0.r0	clear it

Of course, the most famous machine for having many of these cases was the
360/91, with all the out-of-order execution.

Many systems are in the middle somewhere, i.e., where the hardware
offers the OS
	enough information to undo side-effects (PDP-11/70)
	multiple PCs (many RISCs)
	multiple exceptions (Multiflow would be the extreme case)
and it's up to the OS to disentangle the information to present
the appearance of a precise exception back to the user process,
if appropriate.  Most people avoid interrupts that are truly
imprecise in the sense described above, but there are clearly wide variations
in the complexity and cost of code to disentangle the interrupts.
I've heard at least two interesting numbers:
	Multiflow: 1100 lines of assembler code 
		(presented at a USENIX a few years ago)
	Intel 860: (rumor: can somebody confirm): 10,000 instructions
		to disentangle and IEEE-ize floating-point exceptions.
		(this seems a bit larger than I'd expect, especially if
		Multiflow can do it in 1100.)
Also, I believe mo@prisma may have some interesting tales to tell
about exception handling in very fast machines.

Bottom line:
	Precise exceptions are precise; truly imprecise ones are rare;
	there's a wide variation in the middle of the effort needed to
	make them look precise.
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	{ames,decwrl,prls,pyramid}!mips!mash  OR  mash@mips.com
DDD:  	408-991-0253 or 408-720-1700, x253
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086