Jerome H. Fine wrote: Please be aware there is no one "PDP-11 microcode". The internals and microflows of each machine are different, except for the 11/45-55 and 11/70 which are very closely related implementations (same basic core CPU). Some of the VLSI CPUs also tend to behave the same as they are based on the same core CPU (F11, J11, etc). How the DIV instruction behaves in boundary conditions (ie, when the true quotient can not be represented in 16b) can, but may not, be CPU specific. Some CPUs may generate the correct 16 LSB of the 32b quotient. Others may not. The PDP-11 programmers guide for various CPUs indicates that the only affect one can count on is that the 'V' bit is set. In practice, given the standard shift/subtract algorithms for binary division, it is probably the case that the 16b quotient is a true subset of the 32b quotient. However, there is no easy way to prove this without examining the microcode on each machine, or writing a test program and running it on each machine. SIMH implements PDP-11 DIV as: case 1: /* DIV */ if (!CPUO (OPT_EIS)) { setTRAP (TRAP_ILL); break; } src2 = dstreg? R[dstspec]: ReadW (GeteaW (dstspec)); src = (((uint32) R[srcspec]) << 16) | R[srcspec | 1]; if (src2 == 0) { N = 0; /* J11,11/70 compat */ Z = V = C = 1; /* N = 0, Z = 1 */ break; } if ((src == 020000000000) && (src2 == 0177777)) { V = 1; /* J11,11/70 compat */ N = Z = C = 0; /* N = Z = 0 */ break; } if (GET_SIGN_W (src2)) src2 = src2 | ~077777; if (GET_SIGN_W (R[srcspec])) src = src | ~017777777777; --> dst = src / src2; N = (dst < 0); /* N set on 32b result */ if ((dst > 077777) || (dst < -0100000)) { V = 1; /* J11,11/70 compat */ Z = C = 0; /* Z = C = 0 */ break; } --> R[srcspec] = dst & 0177777; ->> R[srcspec | 1] = (src - (src2 * dst)) & 0177777; Z = GET_Z (dst); V = C = 0; break; which would appear that the 16b quotient returned is the 16 LSB of the correct 32b quotient.

>> >> >Jerome H. Fine wrote: >> >>> >Johnny Billquist wrote: >>> >>>> >"Jerome H. Fine" wrote: >>>> > I have noticed what may be an interesting result when I use the >>>> > PDP-11 Integer Divide Instruction "Div". Since I have noticed >>>> > at least one individual who worked on the microcode for the >>>> > PDP-11, perhaps there is an explicit "Yes / No" answer to my >>>> > question: >>>> Since this actually have nothing to do with the microcode, and >>>> actually is nothing specific with the PDP-11 DIV instruction, just >>>> about anyone should be able to answer definitely. >>> >>> Jerome Fine replies: >>> I suggest that you might not be aware of the exact implementation >>> of the PDP-11 integer "Div" instruction when an overflow occurs. >> >> Please be aware there is no one "PDP-11 microcode". The internals and >> microflows of each machine are different, except for the 11/45-55 and >> 11/70 which are very closely related implementations (same basic core >> CPU). Some of the VLSI CPUs also tend to behave the same as they are >> based on the same core CPU (F11, J11, etc). >> >> How the DIV instruction behaves in boundary conditions (ie, when the >> true quotient can not be represented in 16b) can, but may not, be CPU >> specific. Some CPUs may generate the correct 16 LSB of the 32b >> quotient. Others may not. The PDP-11 programmers guide for various >> CPUs indicates that the only affect one can count on is that the 'V' >> bit is set. >> >> In practice, given the standard shift/subtract algorithms for binary >> division, it is probably the case that the 16b quotient is a true >> subset of the 32b quotient. However, there is no easy way to prove >> this without examining the microcode on each machine, or writing a >> test program and running it on each machine. >> >> SIMH implements PDP-11 DIV as: >> >> case 1: /* DIV */ >> if (!CPUO (OPT_EIS)) { >> setTRAP (TRAP_ILL); >> break; >> } >> src2 = dstreg? R[dstspec]: ReadW (GeteaW (dstspec)); >> src = (((uint32) R[srcspec]) << 16) | R[srcspec | 1]; >> if (src2 == 0) { >> N = 0; /* J11,11/70 >> compat */ >> Z = V = C = 1; /* N = 0, Z = >> 1 */ >> break; >> } >> if ((src == 020000000000) && (src2 == 0177777)) { >> V = 1; /* J11,11/70 >> compat */ >> N = Z = C = 0; /* N = Z = 0 */ >> break; >> } >> if (GET_SIGN_W (src2)) src2 = src2 | ~077777; >> if (GET_SIGN_W (R[srcspec])) src = src | ~017777777777; >> --> dst = src / src2; >> N = (dst < 0); /* N set on >> 32b result */ >> if ((dst > 077777) || (dst < -0100000)) { >> V = 1; /* J11,11/70 >> compat */ >> Z = C = 0; /* Z = C = 0 */ >> ====>> break; >> } >> --> R[srcspec] = dst & 0177777; >> --> R[srcspec | 1] = (src - (src2 * dst)) & 0177777; >> Z = GET_Z (dst); >> V = C = 0; >> break; >> >> which would appear that the 16b quotient returned is the 16 LSB of >> the correct 32b quotient. > > Actually I read the C code wrong. If overflow is detected, the > 'break;' jumps out of the code and no registers are modified. > So SIMH does NOT modify any registers if the V-bit has been set. > > I checked the 11/34 MAINDEC EIS diagnostic. For the DIV tests, the > result registers are NOT checked if the Vbit is set. > The diagnostic does not verify that the registers are unchanged; it > assumes the registers are UNDEFINED if V is set. > > I ran some simple DIV tests on a real 11/44: > > >>>s 1000 > > (Program) > > DIV Test of 'div r2,r0' > > ..R0.. ..R1.. ..R2.. ....NUM... ..DEN.. => ..R0.. ..R1.. ..R2.. NZVC > ..QUO.. ..REM.. > > 000003 000004 000003 196612. 3. => 000003 000004 000003 > 0010 3. 4. > 000000 000000 000000 0. 0. => 000000 000000 000000 > 0011 0. 0. <-- Zbit clear > 000001 000001 000000 65537. 0. => 000001 000001 000000 > 0011 1. 1. <-- Zbit clear > 000000 001000 000010 512. 8. => 000100 000000 000010 > 0000 64. 0. > 000000 001234 000021 668. 17. => 000047 000005 000021 > 0000 39. 5. > 000010 001234 005432 524956. 2842. => 000270 003754 005432 > 0000 184. 2028. > 012345 012345 054321 350557413. 22737. => 036071 051134 054321 0000 > 15417. 21084. > 012345 012345 000005 350557413. 5. => 012345 012345 000005 > 0010 5349. 5349. > 000000 040000 000002 16384. 2. => 020000 000000 000002 > 0000 8192. 0. > 000000 100000 000002 32768. 2. => 040000 000000 000002 0000 > 16384. 0. > 000001 000000 000002 65536. 2. => 100000 000000 000002 0010 > -32768. 0. <-- R0 changed, Vbit set > 000002 000000 000002 131072. 2. => 000002 000000 000002 > 0010 2. 0. > > Goodbye > > (Console) > Halted at 165146 > > and an 11/44 under the latest SIMH: > > local[625] pdp11 divtest.ini > > PDP-11 simulator V3.5-0 > > DIV Test of 'div r2,r0' > > ..R0.. ..R1.. ..R2.. ....NUM... ..DEN.. => ..R0.. ..R1.. ..R2.. NZVC > ..QUO.. ..REM.. > > 000003 000004 000003 196612. 3. => 000003 000004 000003 > 0010 3. 4. > 000000 000000 000000 0. 0. => 000000 000000 000000 > 0111 0. 0. <-- Zbit set > 000001 000001 000000 65537. 0. => 000001 000001 000000 > 0111 1. 1. <-- Zbit set > 000000 001000 000010 512. 8. => 000100 000000 000010 > 0000 64. 0. > 000000 001234 000021 668. 17. => 000047 000005 000021 > 0000 39. 5. > 000010 001234 005432 524956. 2842. => 000270 003754 005432 > 0000 184. 2028. > 012345 012345 054321 350557413. 22737. => 036071 051134 054321 0000 > 15417. 21084. > 012345 012345 000005 350557413. 5. => 012345 012345 000005 > 0010 5349. 5349. > 000000 040000 000002 16384. 2. => 020000 000000 000002 > 0000 8192. 0. > 000000 100000 000002 32768. 2. => 040000 000000 000002 0000 > 16384. 0. > 000001 000000 000002 65536. 2. => 000001 000000 000002 > 0010 1. 0. <-- R0 unchanged, Vbit set > 000002 000000 000002 131072. 2. => 000002 000000 000002 > 0010 2. 0. > > Goodbye > > HALT instruction, PC: 000010 (000012) > Goodbye > local[626] > > the interesting case is the (65536. / 2.) computation where the real > 11/44 generates the correct unsigned quotient in R0, but also sets the > Vbit. > > In most cases however it appears that if DIV overflows the quo and rem > registers are unaltered and the Vbit is set. > > SIMH and a real 11/44 (mostly) behave this way. The behavior below > found by Jerome may be an anomaly seen in E11. Jerome Fine replies: I normally attempt to delete anything from previous posts which is not essential. Here, I can't find anything that can easily be omitted from the previous record. FIRST - I want to apologize for misleading Johnny when I sort of stated that I had obtained the results by running on a PDP-11 when in fact the most recent activity was ONLY under E11. I had previously made a number of tests on a real DEC PDP-11/73 (KDJ11-AB) and found results (IF I REMEMBER CORRECTLY) which seem to agree with the results on the real DEC PDP-11/44, SPECIFICALLY the second last test of 65536. / 2. => -32768. QUO / 0. REM In general, I remember that as long as the value in R0 was LESS than the divisor, then the quotient was correct even if overflow did occur. Then meant that for both values initially being positive, the quotient can be greater than 32767. which appears to be negative but which is actually an unsigned 16 bit integer. So, the best example if you can do the test again on both systems is: 196607. / 3. => 65535. QUO / 2. REM OR in OCTAL R0 = 2, R1 = 177777, R2 = 3 produces R0 = 177777, R1 = 2, R2 = 3 likely the v bit and n bit will be set, but the key point is that as long as R0 is initially LESS than the divisor in R2, then the divide operation is attempted. THEN, the full 16 bit unsigned integer result seems to appear in R0 even if the v bit is set when the QUO exceeds 32767. Right now, my system is in parts and it will take a while before I can repeat the test. Again, I apologize for misleading Johnny in respect to my recent tests under E11 where I agree that the full 32 bit result is computed and the low order 16 bits placed in R0 for the QUO before the v bit is determined. I have been in touch with John Wilson and he confirmed that this is what his code does - or at least this is what I seem to understand from his e-mail. BUT, AND THIS IS THE MOST IMPORTANT PART!!!!!!!!! Johnny agrees that my original code (please respond Johnny to this assumption whether or not I am correct or incorrect, i.e. an actual response) that my original code suggestion of first dividing R0 by itself (Mov R1,-(SP) and Mov R0,R1 and Clr R0) by the divisor is the correct method as it appears just below these lines. If anyone thinks this through, then 393215. / 3. has register values of R0 = 5, R1 = 177777, R2 = 3 should (if my brain is not still asleep) qualify using my code below (in which I use TWO divide instructions to first reduce R0 < R2), but STILL produce the v bit SET (v = 1) on the second divide which has R0 = 2, R1 = 177777, R2 = 3 as per my previous example with, of course the same results of the quotient R0 = 65535. and v = 1. I will check this ASAP on my own PDP-11/73, but not today. If Don North can check and Johnny as well, it would be appreciated. IF MY ASSUMPTIONS are correct, then I would assume that the microcode (or hardware) essentially does the same check as essentially my code below does when my code ensures that R0 is LESS than the divisor by first dividing R0 by itself by the divisor. Obviously the remainder in R1 MUST be smaller than the divisor. BUT that still allows the low order 16 bits of the quotient (when all original values are positive) to be larger than 32767. as per my example as long as all of the bits fit into 16 bits which will be the case as long as R0 is less than the divisor. If what I have just stated in the above two paragraphs is confusing, please disregard. I think my examples speak for themselves if you verify what happens on a real DEC PDP-11 system with "Div". AGAIN (ONCE MORE), then there is a HUGE (???) problem if when R0 is less than the divisor that the "Div" instruction can NOT be depended upon to produce a valid quotient in every case. My code below (which Johnny agreed would work) actually will not and I am at a loss now to figure out how to handle the calculation, although I am sure I will figure some way to get the result I require. One the other hand, if SIMH is attempting to duplicate the real DEC PDP-11 hardware, it will also NEED to note when the PDP-11/44 (and maybe other chips as well) do produce a valid 16 bit quotient even when the v bit is set so long as the upper 16 bits of the 32 bit quotient are all zero. I left the rest of the post by Don North intact since it contains the code I suggested the first time AND the second time. ALSO, thank you Don for the actual tests on both systems. It would seem that although E11 does set the v bit when there is an overflow, the low order 16 bits of the quotient are calculated FIRST and placed into R0 even if the high order 16 bits of the quotient are non-zero. I am not sure if John Wilson will "correct" this on future versions of E11, i.e. make the actual results conform with the DEC hardware, but I guess I should NOT depend on the current situation. My code is MUCH faster at this point, but better to be safe than have it break later when I don't expect the current E11 code to be changed to the "correct" results which agree with real DEC hardware. Sincerely yours, Jerome Fine -- If you attempted to send a reply and the original e-mail address has been discontinued due a high volume of junk e-mail, then the semi-permanent e-mail address can be obtained by replacing the four characters preceding the 'at' with the four digits of the current year.

Jerome Fine replies: I also did similar tests again on the PDP-11/73. Specifically, a KDJ11-AB (M8192-YB) board. I would imagine that all of the J-11 chips are the same. I thought that I had different results the last time, but I did not write them down and my memory was not correct. This time I checked exactly and when the quotient result is supposed to be > 32767., the overflow bit is set and the registers are unchanged. The subroutine that takes advantage of E11's results uses BASE 10000 values to ENCODE a 512 byte variable (32 words of 16 bits). Each of the 32 words has its own entry consisting of up to 40 BASE 10000 values which are easily calculated as required using the values from the entry for the previous word. The code simply does a multiply by 65536 (actually just a word shift) and a divide by 10000. to each value in the entry and carries the overflow up the values. Anyone who wants more details, please ask. For example, the first three entries (a zero specifies the end of the entry) are: 1, 0 = 2**0 5536, 6, 0 = 2**16 7296, 9496, 42, 0 = 2**32 Obviously, no value can be larger than 9999., but even then, an overflow will occur - UNLESS I first subtract 327680000. from the dividend (or 5000. instructions to handle the problem, it seems worthwhile to do so(* is for an extra instruction): Clr -(SP) ;* Set flag value for no overflow Cmp #4999.,R2 ;* Branch if no overflow will Bhis 10$ ;* occur on the divide ; Sec ;* Carry bit is already set Ror (SP) ;* Set up extra 32768. for quotient Sub #5000.,R2 ;* Remove excess dividend 10$: Div #10000.,R2 ; Perform the divide without overflow Add (SP)+,R2 ;* Increment quotient by 32768. as required Can anyone suggest a better solution? NOTE that the above solution is VERY specific to the values that can be generated in this specific situation. Thank you to Don North and Johnny for your interest! Sincerely yours, Jerome Fine -- If you attempted to send a reply and the original e-mail address has been discontinued due a high volume of junk e-mail, then the semi-permanent e-mail address can be obtained by replacing the four characters preceding the 'at' with the four digits of the current year.

On Saturday 25 February 2006 20:01, Jerome H. Fine wrote: --snip-- Tried the URL and got: ------------------------------------------------------------------------ Not Found The requested URL /pub/e11/plugin/inst/ was not found on this server. ------------------------------------------------------------------------ Lyle -- Lyle Bickley Bickley Consulting West Inc. Mountain View, CA http://bickleywest.com "Black holes are where God is dividing by zero"

Jerome Fine replies: Sorry about the link. The correct link is: http://www.dbit.com/pub/e11/plugins/inst/ Has anyone actually looked and tested anything? I have sent John Wilson back an updated set of options for: UDIV16 UDIV24 UDIV32 UDIV48 UMUL16 UMUL32 to provide a few options. I hope he will post them soon, but if not they are available to anyone to use and I can send an attached file if requested or include the file in the body of an e-mail. I also want to develop a few more, especially ones that use the emulated PDP-11 memory. This would require specific information on how to use a PDP-11 memory address to read and write to the emulated PDP-11 memory. I would appreciate comments!!!!!!!!!!!!!!!!!!! Sincerely yours, Jerome Fine -- If you attempted to send a reply and the original e-mail address has been discontinued due a high volume of junk e-mail, then the semi-permanent e-mail address can be obtained by replacing the four characters preceding the 'at' with the four digits of the current year.