Two years ago, Bob Armstrong pointed out that the 1620 emulators fails
diagnostic CU01. The failing instruction is a compare that lacks a flag
closing the P field, and the comparison wanders off into territory that
includes a record mark. The simulator stops if an arithmetic operation
is attempted with an invalid digit. Bob hypothesized that record marks
were treated as zeroes. Adding that change made the diagnostic run.
Yesterday, Tom McBride wrote to me and said that this hypothesis was not
correct; the 1620 does stop on invalid digits in arithmetic operations,
including compare. The reason the peculiar compare worked is that the
1620 did not use the standard subtract flows for compare; it used
specialized flows. In the unlike signs case (which is what the
diagnostic was testing), the compare was abandoned as soon as a non-zero
digit was seen in either field, and the indicators were set from the
signs. The record mark was never reached.
I will be revising the 1620 CPU to implement compare correctly, with its
own separate, specialized flow. This will allow removal of the record
mark tests. It will also simplify the add_field routine, which will no
longer need the "don't store" parameter.
There's another mystery in the 1620 add_field routine - why is returns a
"sign changed" status indicator. This can only occur on an effective
subtract with a recomplement cycle. It is not used anywhere else in the
simulator. I am concerned that it screws up the model 2 instructions
that look at "no carry" as part of their status setting. The model 2
extensions have not been tested much, so it's easy to believe this case
was overlooked.
/Bob
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
