Closed atsampson closed 4 years ago
I think this might be a bug. It looks like the AC is written back in the ET cycle, that is followed by the Store cycle. At least this appears to be how the KA and KI do it. I will have to study the KL microcode to see how it did it.
No I was wrong, my simulator is correct. I changed the code to store back P before the write, this broke KA diags, and kept KL diags from loading. I am not sure how the KS handled this.
Note this is an instruction which you probably should not use, since the results can depend on how the hardware is implemented.
I have seen a comment that the MIT KA10s were modified to have POP P,P work differently. Presumably the ITS KL10 microcode comment is a reference to that.
Diags failed if I modified POP to save the stack register then the popped value. KA diags got errors where there was no errors in later diags. KL would not start DIAMON properly with this change in place. I suspect all were modified to do store of value then store of stack pointer.
Is the comment on the JFCL line (P is now -3,,205 - do a load of work, then later...) really correct? I get -4,,204 after the last PUSH (PUSH P,B) and JFCL. Seems to me that as of the POP P,P instruction (before executing it), P contains -4,,204.
I tried this out under KLH10, and as I said in previous post before the POP P,P instruction, P contains -4,,204. After the POP P,P instruction, P contains -5,,203.
Oops - the comment was right but the code was wrong - my test program actually had four PUSH P,As. Fixed.
101$g
$1B; 101>>MOVE 17,100 17/ -4,,204 ^N
102>>MOVE 2,17 17/ -10,,200 ^N
103>>MOVEI 1,42 17/ -10,,200 ^N
104>>PUSH 17,1 17/ -10,,200 ^N
105>>PUSH 17,1 17/ -7,,201 ^N
106>>PUSH 17,1 17/ -6,,202 ^N
107>>PUSH 17,1 17/ -5,,203 ^N
110>>PUSH 17,2 17/ -4,,204 ^N
111>>JFCL 17/ -3,,205 ^N
112>>POP 17,17 17/ -3,,205 ^N
113>>0 17/ -4,,204
Looks like the MIT KL microcode was indeed modified to swap the stores. SAIL's version:
pop1: ARX_AR-1,INH CRY18,SKP CRY0 ;ADJUST POINTER, CHECK TRAP
=0 AR_MEM,TRAP2 ;PDL OVFLO, CAUSE TRAP
AR_MEM,SR_#,#/100 ;SET DEST CONTEXT FLAG
VMA_BR,STORE,SR_0,J/STMAC ;PUT RESULT AWAY, THEN AC
MIT's version:
POP1: AR_AR-1,INH CRY18,SKP CRY0 ;ADJUST POINTER, CHECK TRAP
=*1***0
ARX_MEM,TRAP2 ;PDL OVFLO, CAUSE TRAP
ARX_MEM,SR_#,#/100 ;SET DEST CONTEXT FLAG
AR_ARX,AC0_AR, ;FIRST STORE AC
VMA_BR,STORE,J/STMEM ;THEN MEMORY
;PUT RESULT AWAY, THEN AC
If I switch the simulator to store AC, then memory it breaks diags.
I don't think it's worth changing this in the emulator - as far as I can see early Muddle is the only thing that uses it, and it's easy enough to patch by hand. (The only other POP P,P
in the ITS tree at the moment is in a bit of error-handling code in SUDS, where it wants the regular behaviour.)
I searched all my extracted ToTS tapes for occurrences of POP P,P. I think I saw the one in SUDS, but most are in TENEX. I see some email discussion that the "buggy" behaviour of POP P,P was fixed, but not exactly how. Or why it would be important. If indeed it's only Muddle and nothing else in ITS, I agree it's not worth the trouble.
What's really bothering me is that I think that I saw something written by Tom Knight about how they modified POP P,P on their PDP-10s, but I can't find it now.
Date: 6 JUL 1977 1540-EDT
From: GLS at MIT-MC (Guy L. Steele, Jr.)
We fixed this so long ago I had forgotten about it,
but you may want to be aware that
POP P,P
doesn't work on a KL10. On a KA10 it puts the popped word
into P, but on a KL10 it just subtracts 1,,1 from P
and throws away the popped word. This wasn't in the
document on KL10 differennces I dragged over from SU-AI,
so I thought I'd mention it. (MacLISP uses such an instruction
some, so I will have to fix it up for losing KL10's, I guess.)
RMS@MIT-MC (RMS1) 05/27/76 03:05:12
To: BUG-UCODE at MIT-MC
POP P,P DOES NOT WORK ON THE KL! IT ACTS LIKE SUB P,[1,,1]
GLS@MIT-MC 05/27/76 17:17:38
To: BUG-UCODE at MIT-MC
CC: RMS at MIT-MC
I HAVE A PATCH FOR THE "POP P,P" PROBLEM. IT COSTS ONE
EXTRA CRAM LOCATION, BUT I DON'T THINK IT WILL SLOW POP
DOWN TO ANY GREAT EXTENT. I CHECKED THE KA/KI REFERENCE
HANDBOOK, AND THE DESCRIPTION OF POP EXPLICITLY STATES
THAT "POP P,P" IS SUPPOSED TO WORK AS RMS WANTS, SO MAYBE
WE SHOULD TELL JUD OR WHOEVER AT DEC.
When I changed pdp10-ka to replace the stack pointer with the popped word, it broke diags.
The comment in ucode/define.31 suggests that MIT changed the KL microcode to act like a KA with respect to POP P,P. In other words, confirming that the updated KL behavior matched the KA behavior.
;MAKE POP P,P EXECUTE SAME WAY AS ON KA (STORE AC FIRST, THEN MEMORY)
From the 1969 PDP-10 System Reference Manual, page 2-13:
Because of the order in which the operands are stored, the instruction POP AC,AC would load the contents of the location addressed by AC right into AC on top of the pushdown count, destroying it.
The fix to make POP P,P store the stack pointer before the result breaks emacs here:
M-X generate Library$emacs;babyl$emacs1;babyl$babylm Compressing file DSK: EMACS1; BABYL 783 SFL Search failed?
The last command timed out.
@rcornwell, the build is prone to hang around there for unknown reasons. Did you try several times?
Yes I tried several builds... always hung at exact same spot.
That's quite strange, considering TECO (and therefore EMACS) doesn't use POP P,P. And neither does ITS. I will do some testing when @rcornwell sends me his patch.
Indeed. I went looking for the POP P,P in TECO and didn't find it. Maybe it is in some loaded (library) code? Or some self-modifying code?
Checking the patch on my computer, I can confirm that generating the BABYL library hangs the build. Now to investigate why...
Suspicious instructions found in TECO:
Under SLPN0W: HRLI D,(POP TT,(TT))
This is later run out of the accumulators.
Under NEWFRK: POP P,(P)
inside a literal.
Under ITRPOP: POP A,(A)
POP P,(P)
is quite frequently used in ITS programs.
My verilog simulation confirms that POP P,P writes the popped value to P and not the decremented PDL ptr on a KA10. On the PDP-6 the opposite is the case.
Sorry, POP AC,(AC) is probably a red herring. It was probably a coincidence I ^Z'ed Emacs when it seemed hung and I saw a POP TT,(TT) near PC.
After loading the IVORY library, I run M-X Generate Library$lars;babyl$emacs1;babyl$emacs1;babylm
. Emacs is in deep thought for about ten seconds, and then aborts with the message SFL Search failed?
. Typing ? at this point says we're at <ci~DOC~ $ s:^Q!$ .-z;>
in & Compress Buffer in IVORY, specifically the s
search command. The argument to s
is :^Q!
, where ^Q just quotes the next character. So it should be searching for :!
, but failing.
I tracked this down to being caused by a page fault. On a KA10, POP will now decrement the stack pointer before making a memory reference. So if the write faults, the instruction will be restarted and decrement the pointer a second time.
I verified that page faults do happen when the problem is observed in EMACS. I also made a band aid fix by temporarily saving the decremented pointer and restoring it before "goto last" if there was a fault.
Fixed in current patch.
I've run into an interesting problem with Muddle 54, which originally ran on MIT's DM KA-10. Here's an example of the kind of thing it's doing:
In pdp10-ka, this leaves P as
-4,,204
- i.e. the POP didn't overwrite P at all. On LCM+L's TOAD-2, this leaves P as-11,,177
- i.e. the POP overwrote P, then decremented the pointer as usual. And the Muddle 54 code expects it to just restore P without decrementing it - it's replaced withMOVE P,(P)
in later versions.DEC's June 1982 Processor Reference says "Do not use the instruction
POP AC,AC
as its result is indeterminate." But what did the real machines do? There's a comment in the ITS KL microcode saying that it will "MAKE POP P,P EXECUTE SAME WAY AS ON KA (STORE AC FIRST, THEN MEMORY)"...