[Simh] 1620 compare implementation

[Bob Supnik]

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