[Simh] PDP7/DECsys bug

[J. David Bryan]

On 4 Jun 2007 at 22:01, Daniel Baum wrote:

> >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.
> 
> Thanks. I'll try what you suggested.

Anecdote: I had a problem early on with the HP simulator wherein a program 
that printed the time of day printed 0:00:00.000 instead.  Was it a problem 
with the system clock?  No, as it turned out, it was a problem with a 
somewhat obscure machine instruction that the program used to format the 
time string.  An address register wasn't incrementing for a "store byte" 
instruction, so all of the time-string characters were written to the first 
character location instead of sequentially through the string.

The clock on the system had a ten-millisecond resolution, so the last time 
digit was always "0".  So after all of the characters overwrote the first 
location, the last character ("0") matched what was there originally, and 
it looked as though the system clock was stuck at zero.

Fortunately, I had the source to the program and independent confirmation 
that the system clock was, in fact, working properly.  Otherwise, I would 
have spent a lot of time chasing the wrong problem.

Anyway, if you don't have a FP diagnostic, I'd try the C = A + B test next, 
and maybe some other simple math tests.  If you can determine whether the 
FORTRAN formatter is correctly formatting a bad value, or whether it's 
improperly formatting a good value, that's half the battle.


> I would never have found that on my own.

Thirty-four years ago, I used an HP database product called QUERY/2100.  It 
required data entry in that overpunched sign format, so, for example, the 
value -137 had to be entered as 13P.  Hideously prone to operator error, 
which is probably why I remember it today.  ;-)  Later versions did away 
with that and went to conventional leading-sign format, but that "J for 1, 
etc." pattern stuck with me.


> However, I still don't understand why it's showing negative values.
> pic S99 shows the sign to be negative, as does the overpunching itself.

Again, writing an extremely simple program and following the execution at 
the machine level may help to point to the source of the error.  Cobol-74 
may be generating different instructions than Cobol-68, possibly using 
instructions that manipulate packed decimal numbers directly.  A bug in the 
latter might explain the difference.


> Thanks again,

You're welcome.  Good luck.

                                      -- Dave