XREF/JONES stops processing, idle in mix

[GoogleCodeExporter]

Attempted to run the XREF/JONES program from the SPO, equating the CARD file to 
SYMBOL/XREF. Program appeared to start fine, then got open messages for a 
printer-backup file. After several seconds, I/O activity in the emulator 
ceased, and XREF/JONES appeared to be idle. Program could be DS-ed 
successfully, and system seemed to operate normally otherwise.

Line number at which the program was DS-ed is immediately after a write to the 
printer file. Suspect the problem is something in I/O, or possibly a dropped 
interrupt.

Original issue reported on code.google.com by paul.kimpel@digm.com on 16 Apr 2013 at 4:17

[GoogleCodeExporter]

Sure enough, the Program Release (PRL) syllable was not isolating the 
Continuity bit [20:1] from the I/O Descriptor properly, so it was probably 
signaling a Program Release interrupt rather than a Continuity Bit interrupt. 
Fixing that allowed XREF/JONES to run significantly longer, but subsequent 
tests either failed with an system-halting Invalid Address error, or the 
program never completes, even after 20+ minutes of elapsed time.

Original comment by paul.kimpel@digm.com on 17 Apr 2013 at 5:00

[GoogleCodeExporter]

There have been several fixes in Processor that could have fixed this, but it 
does now appear to be fixed. There was a problem with stack adjustment in BRT 
(Branch Return). There was also a problem with C-register restoration in RCA 
(Character-Mode Recall Control Address).

Subsequently, when trying to compile XREF/JONES with Algol, things got very 
nasty, and took a long time to track down. The character of the problem changed 
somewhat after I reworked the code for SFI (Store for Interrupt/Test) and IP1 
(Initiate Processor), but the usual result was still Invalid Address. I finally 
trapped an instance while Firebug was running, and was able to manually record 
the contents of the registers and stack. The invalid address was occurring on 
exit from an in-line stream statement that formatted the disk address for a 
call on DISKWAIT out of FORGETUSERDISK, which in turn was being called by COM5 
to terminate the compiler task, mix#1. 

FORGETUSERDISK was returning overlay space to the available pool, and 
DALOC[1,0].[33:15] had a bad value for the index to the last entry in that 
DALOC row. That resulted in an Integer Overflow condition in Control State, 
which left bad parameters in the stack for the call to FORGETUSERDISK (the 
index and descriptor, rather than the result of indexing the descriptor), which 
in turn caused the stack frame for FORGETUSERDISK to be corrupted, and things 
just went downhill from there. 

I never did find out how DALOC[1,0] got the bad value, but just by accident, 
discovered that the MSCW traversal during procedure exit to restore the MSCW at 
R+7 was not terminating correctly -- it was checking both the MSFF and SALF 
bits in MSCWs instead of just MSFF. After that was fixed, XREF/JONES compiles 
successfull, as well as the Algol compiler with itself. I am confident the 
problem as we were seeing it is fixed, but can't prove it.

Original comment by paul.kimpel@digm.com on 27 May 2013 at 2:08

• Changed state: Fixed

[GoogleCodeExporter]

Confirmed.

Original comment by paul.kimpel@digm.com on 29 Dec 2013 at 4:33

• Changed state: Verified