From mboxrd@z Thu Jan  1 00:00:00 1970
From: random832@fastmail.com (Random832)
Date: Mon, 19 Mar 2018 11:32:38 -0400
Subject: [TUHS] PDP-11 DIV instruction lossage
In-Reply-To: <20180319140359.2204C18C088@mercury.lcs.mit.edu>
References: <20180319140359.2204C18C088@mercury.lcs.mit.edu>
Message-ID: <1521473558.1945631.1308301672.0CD3ACAD@webmail.messagingengine.com>

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.