The double (70 bit signed) arithmetic is probably the easiest conceptual way to deal with unsigned 36 bit numbers on a PDP-10.

For example, because you know the maximum value of an unsigned word will be signed double word, a DDIV will never blow up because the high order double word of the signed quad word (the dividend) can not be larger than the divisor; those two words must always be zero--no cast could set them.

There is the matter of efficiency, which is perhaps important if you are doing a great big bunch of numbers or you otherwise have to get something over with pretty quickly.  Instead of double arithmetic, you might do one of the following:

  1. You can compare the high order of the dividend with the divisor beforehand,
  2. You can check bits (with a JFCL) after the operation or
  3. You can trap.

They all have their pro's and con's, yet they wouldn't be necessary if PDP-10 had an unsigned compare.  That was one of the things I really appreciated when I had to hack the PDP11 DN65 code.

The problem is partly because numbers that are defined as unsigned in Tops-10, TENEX and Tops-20 really aren't because you have to handle them specially, which I have yet to see done in Tops-20, Galaxy or any of the CUSP's I have had occasion to remediate.  Why?  Well, clearly in the vast majority of cases, it doesn't matter, so a CAM is plenty good enough.

Unless you happen to be me having fun.

I carefully looked at the divide overflow conditions when I made changes to UPTIME to make it count years, (decades, centuries and millennia) and gave it microsecond resolution (the maximum a DK10 with external clocking could do), viz:

TOMMYT up for 1 Year, 3 Weeks, 2 Days, 22 Hours, 19 Minutes, 35 Seconds, 50 Milliseconds and 160 Microseconds

UPTIME's general divide routine which peels all these numbers off of the signed 46 bit number determines which is the most efficient divide instruction to use: DDIV, DIV or IDIV, which will not risk an overflow.  I  JFCL the bits anyway, but that is mostly to assure myself that I still haven't gotten it wrong or a micro-engine hasn't hiccoughed. 

As to why I find this fun is anyone's guess.

On 2/7/22 6:16 PM, Robert Armstrong wrote:

  ... and the KL had double precision integer math instructions (DADD, DSUB, DMUL, DDIV) as well as double word integer MOVEs, so you could get 72 bit integer arithmetic without needing to deal directly with the carry flag anyway.  I can't remember about the KI - I think it had DMOVE, but not any of the arithmetic instructions.

  As a practical matter the PC flags were not very useful to the average user mode programmer.

  And JFCL, with no flag bit specified, was the traditional NOP.  I believe on a KL something like TRNN was actually faster to execute, but by then nobody was willing to switch.

Bob  

Thomas DeBellis <tommytimesharing@gmail.com> wrote:
  
And then I said, "When was the last time I actually used a JFCL and JOV".� Well, yeah if you are doing big math, but that just doesn't happen in day to day systems programming.� There wasn't any in all of Galaxy, even when I fixed to to calculate dates properly.