9 Feb
2022
9 Feb
'22
1:24 a.m.
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(a)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.