rfg@ics.uci.edu (Ron Guilmette) (11/13/89)
In article <223@m1.UUCP> dave@m1.UUCP (Dave Cline) writes: > >WELCOME: to comp.sys.m88k > > >Here are some proposed topics (partial list) to be covered by this group: > > g) Future forthcoming standards activities (e.g. 88k ABI for V.4, etc.) Ok. I'll bite. Is there (or will there be) an ABI for SysV.4? >2) Discussions of the 88k architecture > a) Programming tricks OK. Here is a harder one. I noticed in the 88100 hardware manual that there is a control bit (in one of the control registers) that is said to be the "SERIALIZATION" bit. The manual (cryptically) sez that setting this bit "serializes" the processor. This terse note then sez to "see section so-and-so for further information". Well, I looked in section "so-and-so" (sorry, I don't have the book right here just now) and guess what! There is *no mention* of the serialization bit in there! What gives? What I *really* want to know (besides *all* of the details) is whether or not this bit could be useful to debuggers (i.e. does it disable the otherwise confusing effects of pipelining).
marvin@oakhill.UUCP (Marvin Denman) (11/13/89)
In article <1989Nov12.173826.19296@paris.ics.uci.edu> Ron Guilmette <rfg@ics.uci.edu> writes: >OK. Here is a harder one. I noticed in the 88100 hardware manual that >there is a control bit (in one of the control registers) that is said to >be the "SERIALIZATION" bit. The manual (cryptically) sez that setting >this bit "serializes" the processor. This terse note then sez to "see >section so-and-so for further information". > >Well, I looked in section "so-and-so" (sorry, I don't have the book right >here just now) and guess what! There is *no mention* of the serialization >bit in there! What gives? The lack of discussion of the SERIALIZATION bit in the manual confuses me also. I have no excuses for the manual, but I will try to explain how it works. The serialization bit in the PSR causes all out standing operations to be completed before the next instruction is issued. This is identical to what happens when a tb1, tb0, tcnd, rte, or xmem instruction is issued except the serialization bit causes it to happen for all instructions. The processor will still prefetch the next instruction but will go no further in the instruction stream. >What I *really* want to know (besides *all* of the details) is whether >or not this bit could be useful to debuggers (i.e. does it disable the >otherwise confusing effects of pipelining). This bit is useful for debuggers if nothing else because it simplifies the problem greatly. 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. Marvin Denman Motorola 88000 Design -- Marvin Denman Motorola 88000 Design
mark@bnr-rsc.UUCP (Mark MacLean) (11/14/89)
In article <1989Nov12.173826.19296@paris.ics.uci.edu> Ron Guilmette <rfg@ics.uci.edu> writes: >there is a control bit (in one of the control registers) that is said to >be the "SERIALIZATION" bit. The manual (cryptically) sez that setting >this bit "serializes" the processor. > >What I *really* want to know (besides *all* of the details) is whether >or not this bit could be useful to debuggers (i.e. does it disable the >otherwise confusing effects of pipelining). 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.
rfg@ics.uci.edu (Ron Guilmette) (11/14/89)
In article <2610@yogi.oakhill.UUCP> marvin@yogi.UUCP (Marvin Denman) writes: >In article <1989Nov12.173826.19296@paris.ics.uci.edu> Ron Guilmette <rfg@ics.uci.edu> writes: >>OK. Here is a harder one. I noticed in the 88100 hardware manual that >>there is a control bit (in one of the control registers) that is said to >>be the "SERIALIZATION" bit. The manual (cryptically) sez that setting >>this bit "serializes" the processor... > >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. 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? Shouldn't that bit be "protected" in some sense? //rfg
andrew@frip.WV.TEK.COM (Andrew Klossner) (11/15/89)
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]