🚀 go-pugleaf

In article <44908@bbn.COM> dswartz@BBN.COM (Dan Swartzendruber) writes:
>	[ ... ]		The PDP-11 had
>the same problem.  I seem to recall they solved it by having a diagnostic
>register in which the CPU wrote which registers had been incremented or
>decremented and by how much.

In article <2812@masscomp.UUCP> dennis@westford.ccur.com (Dennis Rockwell) writes:
>Some PDP-11s had this register, some did not.  It turns out
>that the only time this was a problem was when an
>auto-[in|de]crement *floating*point* instruction caused the
>fault.  Unfortunately, DEC left this register out of the
>PDP-11/60 (or was that the 11/44?), which implemented the
>standard floating point instruction set.  Thus, for this

The handbooks tell me that this register was implemented on all but one
of the memory-managed PDP-11s.  On the old PDP-11/45, it was called
Segment Status Register #1 (SSR1) and had the format:

	Bits 11..15 : amount changed
	Bits  8..10 : register changed
	Bits  3.. 7 : amount changed
	Bits  0.. 2 : register changed

On the later PDP-11s (11/44, 11/70) it was called Memory Management
Register #1 (MMR1).

The basic reason for doing it this way was to allow the fault handling
code to undo the side effects that might have occurred.  At most two
registers could have been changed, and at most by 8.  Note that the
register didn't tell you which register SET was currently in force:
you had to work that out for yourself using the various mode bits
scattered about the place.  You then restored the registers, reset the
PC to point to the start of the instruction (this value was squirrelled
away in MMR2 since you can't decode PDP-11 instructions backwards),
and off you went again.

If I recall aright, the fix on the PDP-11/24 was to keep the stack
double-word aligned.  A floating-point operation could then never
cause a memory-management abort halfway through.