[TUHS] PDP-11 DIV instruction lossage

[TUHS] PDP-11 DIV instruction lossage

[Noel Chiappa]

    > I'll have to redo my kludgy fix to gmtime() ... I guess I'll have to fix
    > it for real, instead of my kludgy fix (which extended it to work for
    > 16-bit results). :-)
    > ...
    > And on the -11/23:
    > Note that the returned 'quotient' is simply the high part of the dividend.

Heh. I had decided that the easiest clean and long-lived fix was to just to do
it right, using the long division routine used in the V7 C compiler runtime:

  http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/libc/crt/ldiv.s

and I vaguely recalled reading a DMR story that talked about that, so just for
amusement I decided to re-read it, and looked it up:

  https://www.bell-labs.com/usr/dmr/www/odd.html

(the section "Comments I do feel guilty about"), and it's lucky I did, because
I found this:

  Addendum 18 Oct 1998

  Amos Shapir of nSOF (and of long memory!) just blackened (or widened) the
  spot a bit more in a mail message, to wit:
 
  'I gather the "almost" here is because this trick almost worked... It has a
  nasty bug which I had to find the hard way!

  The "clever part" relies on the fact that if the "bvc 1f" is not taken, it
  means that the result could not fit in 16 bits; in that case the long value
  in r0,r1 is left unchanged. The bug is that this behavior is not documented;
  in later models (I found this on an 11/34) when the result does fit in 16
  bits but not in 15 bits ... which makes this routine provide very strange
  results!'

So this code won't work on an 11/23 either (which bashes the low register of
the pair; above). I'd have been groveling in buggy math, again...

Caveat Haquur (if you're trying to run stock V7 on a /23 or /34)!

       Noel

[TUHS] PDP-11 DIV instruction lossage

[Random832]

On Mon, Mar 19, 2018, at 10:03, Noel Chiappa wrote:
>     > I'll have to redo my kludgy fix to gmtime() ... I guess I'll have to fix
>     > it for real, instead of my kludgy fix (which extended it to work for
>     > 16-bit results). :-)
>     > ...
>     > And on the -11/23:
>     > Note that the returned 'quotient' is simply the high part of the dividend.
> 
> Heh. I had decided that the easiest clean and long-lived fix was to just to do
> it right, using the long division routine used in the V7 C compiler runtime:

I did a version of gmtime a few months ago that divides by 86400 using the V6 ldiv function (by shifting by 7 to divide by 128 first, then dividing by 675). My main interest was in getting it to treat timestamps as unsigned (despite the V6 compiler having neither an unsigned type nor a long type) in order to push back the 2038 problem. After adding an overflow warning to apout, it looks like mine manages to avoid hitting the overflow until September of 2059.

[TUHS] PDP-11 DIV instruction lossage

[Noel Chiappa]

So, I have discovered, to my astonishment, that the double-word version of the
DIV instruction on the PDP-11 won't do a divide if the result won't fit into
15 bits. OK, I can understand it bitching if the quotient wouldn't fit into 16
bits - but what's the problem with returning an unsigned quotient?

And, just for grins, the results left in the registers which hold the quotient
and remainer is different in the -11/23 (KDF11-A) and the -11/73 (KDJ11-A).
(Although, to be fair, the PDP-11 Architecture Manual says 'register contents
are unpredictable if there's an overflow'.)

Oh well, guess I'll have to redo my kludgy fix to gmtime() (the distributed
version of which in V6 qhas a problem when the number of 8-hour periods since
the epoch overflows 15 bits)! I guess I'll have to fix it for real, instead of
my kludgy fix (which extended it to work for 16-bit results). :-)


I discovered this when I plugged in an -11/73 to make sure the prototype QSIC
(our RK11/etc emulator for the QBUS) worked with the -11/73 as well as the
-11/23 (which is what we'd mostly been using - when we first started working
on the DMA and interrupts, we did try them both). I noticed that with the
-11/73, the date printed incorrectly:

  Sun Mar 10 93:71:92 EST 1991

After a certain amount of poking and prodding, I discovered the issue - and
on further reading, discovered the limitation to 15-bit results.


For those who are interested in the details, here's a little test program that
displays the problem:

       r = ldiv(a, b, d);
       m = ldivr;

       printf("a: 0%o %d.  b: 0%o %d.  d: 0%o %d.\n", a, a, b, b, d, d);
       printf("q: 0%o %d.  r: 0%o %d.\n", r, r, m, m);

and, for those who don't have V6 source at hand, here's ldiv():

        mov     2(sp),r0
        mov     4(sp),r1
        div     6(sp),r0
        mov     r1,_ldivr
        rts     pc

So here are the results, first from a simulator:

  tld 055256 0145510 070200
  a: 055256 23214.  b: 0145510 -13496.  d: 070200 28800.
  q: 0147132 -12710.  r: 037110 15944.

This is _mathematically_ correct: 055256,0145510 = 1521404744., 070200 =
28800., and 1521404744./28800. = 0147132.

And on the -11/23:

  a: 055256 23214.  b: 0145510 -13496.  d: 070200 28800.
  q: 055256 23214.  r: 037110 15944.

Note that the returned 'quotient' is simply the high part of the dividend.

And on the -11/73:

  a: 055256 23214.  b: 0145510 -13496.  d: 070200 28800.
  q: 055256 23214.  r: 037110 15944.

Note that in addition to the quotient behaviour, as with the /23, the
'remainder' is the low part of the dividend.

	    Noel