GoogleCodeExporter
commented
9 years ago Source to reproduce the problem is in project SVN repo r325 and r326, less the
control cards:
? COMPILE FORTRAN/COMP WITH ALGOL LIBRARY
? ALGOL STACK = 2000
? DATA CARD
$ CARD LIST SINGLE
:::
? END
Problem occurs near line 3374 in the FORTRAN source file (sequence 00304400),
at the declaration of stream procedure DCMOVE, not line 3774 as Fausto reported.
Problem occurs around line 02509000 in the Algol compiler (S=14, A=380).
"DCMOVE" has a scramble modulus of 66. STACKHEAD[66] has the value 2, which
addresses the first row in INFO[*,*]. The STACKHEAD value should be much
higher, and in any case greater than 256. So somehow that STACKHEAD cell is
getting stepped on. Odd that we only see this bug if the source is read from a
pseudoreader.
From email to Fausto on 2013-06-26 at 11:24 PDT:
Progress report -- I managed to reproduce this problem, but only if I use
LDCNTRL/DISK to spool the FORTRAN compiler deck to disk and then compile using
a pseudo-reader. The Algol compiler is looping at the label ROSE (line
02509000). It is attempting to look up the token DCMOVE in the symbol table,
but one of the hash heads for the symbol table has a bad value, and the look-up
routine is using link values from the wrong words. I think this is an emulator
bug, but the problem occurs some time before we see its effect, and it may be
difficult to track down.
The system is still running, it is just that the Algol compiler is in a very
tight processor loop (the A NORMAL light was on continually). When you DS the
compiler, the MCP reads the rest of the cards, looking for the ?END card that
signals the end of the deck. Any cards after that should then be processed
normally.
Paul
-------- Original Message --------
Subject: Re: Emulator version 0.07
From: Fausto Saporito <fausto.saporito@gmail.com>
To: Paul Kimpel <paul.kimpel@digm.com>
CC: Nigel Williams <nw@retrocomputingtasmania.com>
Date: Tue, 25 Jun 2013, 3:34 am
Just another bit... if I abort the JOB (with 1 DS),the CRA starts to process
cards again...
2013/6/25 Fausto Saporito <fausto.saporito@gmail.com>
Hello,
I modified the printer setting, but I have always the same problem. And I noticed it happens after the same line (3774).
Attached there's the file I'm using.
regards
Fausto
PS
I reduced also the stack size.
2013/6/25 Fausto Saporito <fausto.saporito@gmail.com>
Hello Paul,
I reduced the number of lines to 60000, maybe this could help a bit.
The utility you found is very useful, I corrected a lot of typos.
I'll try to compile with less stack, too, just to check. According to the original source the stack size should be 100 (?). Is it possible ? The default is 512, if I remember well, so maybe it's too small...
regards,
Fausto
2013/6/25 Paul Kimpel <paul.kimpel@digm.com>
Fausto,
I have tried a couple of times on a couple of different systems to reproduce the card reader stop you have described, and have not yet seen the problem. Perhaps it is due to some accumulative condition that takes a while to develop in the emulator before it becomes noticeable. I'll keep trying.
That made me think about the line printer implementation. At present, the line printer works by appending text nodes within an <iframe>. It will accumulate 150,000 lines (about 18MB) before it starts to discard nodes from the front of the listing. If you are compiling the FORTRAN compiler many times in succession, perhaps the accumulation of these DOM nodes in memory is causing a lot of garbage-collection activity inside the browser, and that is causing the system to appear to be unresponsive. That is just a theory, however.
If you want to explore this theory, you could try changing the value of B5500DummyPrinter.maxScrollLines in the file webUI/B5500DummyPrinter.js.
Also, I noticed that you had a ?STACK=3000 control card in the compile deck. The Algol compiler should not require that much stack space to compile FORTRAN -- it can compile itself with the default stack size, and Algol is a bigger compiler than FORTRAN. I think the reason you are getting a stack overflow is that there are so many syntax errors, the compiler gets lost and is having difficulty recovering. The B5500 compilers used recursive descent techniques, and did not have particularly good error recovery.
<snip>Original comment by paul.kimpel@digm.com on 6 Jul 2013 at 1:50
- Changed state: Accepted
Original issue reported on code.google.com by
paul.kimpel@digm.comon 6 Jul 2013 at 1:13