Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!samsung!uunet!zephyr.ens.tek.com!orca!frip!andrew
From: andrew@frip.WV.TEK.COM (Andrew Klossner)
Newsgroups: comp.sys.m88k
Subject: Re: SERIALIZATION bit
Message-ID: <5334@orca.WV.TEK.COM>
Date: 14 Nov 89 16:45:41 GMT
References: <223@m1.UUCP> <1989Nov12.173826.19296@paris.ics.uci.edu> <2610@yogi.oakhill.UUCP> <1989Nov13.161540.27475@paris.ics.uci.edu> <1361@bnr-rsc.UUCP>
Sender: nobody@orca.WV.TEK.COM
Reply-To: andrew@frip.wv.tek.com
Organization: Tektronix, Wilsonville, Oregon
Lines: 32

Marvin Denman (marvin@yogi.UUCP) writes, regarding the SER bit:

	"My question is whether or not this bit belongs in the BCS.
	Right now it is one of the bits controllable from a user
	program.  I realize its importance to debuggers, but is it
	really needed by applications programs."

Ron Guilmette (rfg@ics.uci.edu) replies:

	"That's awful.  How can you virtualize the processor state if
	any user program can set/clear this bit?  What if a debugger
	sets it and then the user program clears it?"

Access to the PSR from an application program is through a system call
(hence the reference to the BCS).  User code does not have direct
access to the PSR.

Mark MacLean (mark@bnr-rsc.UUCP) asks:

	"What pipeline effects are confusing for debuggers?  When you
	do a trap instruction (for a breakpoint) the processor gets
	serialized anyway, not leaving much around in the control
	registers to confuse users."

But there are lots of ways a debugger can get control other than a trap
instruction.  For example, if the application steps on a garbage
pointer then immediately takes a branch, without serialization the
faulting PC is lost by the time the DACC happens.  With serialization,
the SXIP points to the instruction which caused the problem.

  -=- Andrew Klossner   (uunet!tektronix!frip.WV.TEK!andrew)    [UUCP]
                        (andrew%frip.wv.tek.com@relay.cs.net)   [ARPA]