[Simh] PDP7/DECsys bug

[J. David Bryan]

On 4 Jun 2007 at 8:59, Daniel Baum wrote:

> Everything else appears to work as normal, except the floating point
> values.

Let me preface my remarks with the caveat that I have no experience with 
the systems you're using.  However, from extensive experience with 
debugging SIMH for the HP 2100 simulator, here are a couple of approaches I 
would try:

 1. If there's a floating-point diagnostic available for the hardware
    machine, run it.  I found and fixed a lot of SIMH bugs that were
    immediately indicated by failing CPU diagnostics.

 2. Set a SIMH breakpoint to trip when your program begins execution and
    step through the instruction codes one by one to check that the CPU
    registers are changing as expected.  For instance, if a
    floating-point instruction is to be executed, check that the result
    register has the expected value.  If your FORTRAN compiler has an
    option to list the generated machine code, that will help identify
    what's executing.

 3. Separate the issues of floating-point execution from the formatter
    output by stepping through a simple program, e.g.:

      A = 1.0
      B = 2.0
      C = A + B

    If floating-point is working, then examining the result of the
    addition at the machine level should show the value 3.0 is being
    stored in C.  Should be only a couple of instructions if FP hardware
    is being used.

As Bob said, the problem could be in the simulation or in the software.  
The FORTRAN formatter is a pretty complex beast, so determining whether 
floating-point is working outside of the formatter would help narrow the 
scope quite a bit.  Might turn out to be a bug in a non-floating-point 
instruction that's used by the formatter to produce the print 
representation of FP numbers, rather than an actual FP instruction error.


> I'd also like to draw your attention to a problem with TOPS-10 Cobol.
> 
> Under Cobol-74, a simple numerical variable, declared with "PIC 99",
> will print out as "0J" if its value is 1, "0K" if its value is 2, and
> "0L" if its value is 3. 

This sounds very much like "overpunched signed" representation of negative 
numbers.  Google for "overpunched sign" or see, for example, this extract 
from the HP 3000 Cobol manual:

  http://invent3k.external.hp.com/~MGR.LROM3K/docs.cgi/BV740.136/53

Scroll down to the section titled "USAGE IS DISPLAY" and specifically to 
Table 7-6, "Overpunch Characters for Rightmost Digit in ASCII Coded Decimal 
Numbers."  The associated text says, in part:

  Zone signs cause the signed digit to have the same punch configuration
  as certain other characters.  This is the purpose of the S symbol in
  the PICTURE clause; it informs the compiler that the last digit in the
  field is to be interpreted as a number and a sign, and not as the
  character that it would otherwise represent.

                                      -- Dave