3 Dec
2020
3 Dec
'20
9:55 a.m.
Hi everyone,
The Nostalgic Computing Center <http://www.nostalgiccomputing.org/> has a
virtual PDP-8 running TSS/8
<http://www.nostalgiccomputing.org:8080/aterm.html?m=pdp8&t=PDP-8&r=24&c=80>
in its collection. We use the SIMH PDP-8e emulator to support the machine,
and we recently updated the machine to run the TSS/8 distribution created
by LCM+L, found here on GitHub
<https://github.com/livingcomputermuseum/cpus-pdp8>. The LCM+L distribution
is slightly different from other TSS/8 distributions available on the web
in that it provides some additional goodies such as ALGOL and LISP.
The NCC demonstrates how various classic computers worked by providing
automated scripts that interact with the machines in the collection.
For example, to demonstrate each of the programming languages supported by
a machine, scripts are provided to create, compile, and run a simple
Fibonacci sequence generator. We've done this for the TSS/8 system, but the
scripts aren't working for FORTRAN or ALGOL, and we're wondering if anyone
on this list might know why.
Specifically, in the case of FORTRAN, the compiler exits with an error code
6204. This occurs even when trying to compile trivial "hello world"
programs, and it appears to occur in all other TSS/8 distributions we've
tried as well (i.e., this particular problem is not unique to the LCM+L
distribution). We haven't found error code 6204 specifically documented in
the TSS/8 user/admin manuals, but the manuals do document other error codes
in the 62xx range. Documented error codes in the 62xx range appear to
reflect file I/O errors, so we're wondering if perhaps one of the files
supporting the FORTRAN compiler is corrupt in all of these distributions.
For example, here is a transcription of a simple session demonstrating the
problem:
.R EDIT
INPUT:
OUTPUT:FTEST
A
WRITE(1,10)
10 FORMAT(5HHELLO,/)
END
E
^BS
.R FORT
INPUT:FTEST
OUTPUT:
6204^BS
.
We tried enabling the floating point processor to see if lack of FPP might
cause FORT to abort, but enabling the FPP did not solve the problem. The
SIMH configuration file for the machine currently looks like:
set throttle 800K
set df disabled
set rf disabled
set rk enabled
set dt enabled
att rk0 tss8_rk_lcm.dsk
set cpu 32k
attach ttix 4000
load boot.bin
run 200
Note that BASIC, FOCAL, and LISP all seem to run very nicely on the machine.
The problem we're experiencing with ALGOL appears to be a glaring compiler
bug, but the compiler was distributed widely through DECUS, and it is
difficult to imagine that it would have been released with an obvious bug,
so we are wondering if perhaps we're not interpreting the user manual
<http://svn.so-much-stuff.com/svn/trunk/pdp8/src/decus/8-213/decus-8-213.pdf>
correctly. Here is a transcription of a session that exhibits the problem:
.R EDIT
INPUT:
OUTPUT:ATEST
A
'BEGIN'
'INTEGER' I;
I := 1;
WRITE(1, I); SKIP
'END'
$
E
^BS
.R ALGOL
INPUT:ATEST
OUTPUT:
*TOO MANY UNDEFINED [UEXPRESSION*
^BS
.
The compiler seems to be complaining that the simple assignment statement
on line 3 of the program is somehow incorrect. If we change the statement
to "I := 1 + 0;", the error message goes away, and the program runs, but
it prints "0" instead of the expected "1". Also, if we change the
program
to:
'BEGIN'
'INTEGER' I;
'FOR' I := 1 'STEP' 1 'UNTIL' 10 'DO'
'BEGIN'
WRITE(1, I); SKIP
'END'
'END'
$
it compiles successfully and it prints what is expected, the numbers 1
through 10.
Does anyone have experience with the ALGOL/8 compiler? If so, does this
behavior make sense, and can you let us know what we're doing wrong?
Note that the same ALGOL60 program compiles and runs as expected on the CDC
mainframes and the TOPS-20 system at the NCC.
thanks!
Kevin