Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!decvax!harpo!seismo!hao!hplabs!sri-unix!scs@mit-math@mit-mc From: scs@mit-math@mit-mc@sri-unix.UUCP Newsgroups: net.unix-wizards Subject: long integer division on pdp11's Message-ID: <3314@sri-arpa.UUCP> Date: Thu, 21-Jul-83 22:16:23 EDT Article-I.D.: sri-arpa.3314 Posted: Thu Jul 21 22:16:23 1983 Date-Received: Sat, 23-Jul-83 17:51:30 EDT Lines: 22 Anyone who uses any version of unix or one of its derivatives on pdp11's should be aware of a machine dependency in the c run-time long integer division routines. Although the result of the pdp11 div instruction is officially undefined after an error, these routines (ldiv, lrem, aldiv, and alrem) all use the result at one point. The problem crops up at a point where the quotient just computed is expressible in 16 bits, but is greater than 32767 and so not a proper two's complement number. Apparently most 11's put the divisor in the first destination register and leave the second alone, but the 11/23 clears it. A fix is to put a mov r2, r1 before the second div instruction in each of the four routines (ldiv.s, lrem.s, aldiv.s, and alrem.s). They are usually kept in /usr/src/libc/crt . Of course they will have to be re-assembled and put in /lib/libc.a to take advantage of the fix. I haven't tested this fully, but it definitely helps. It would be safest to re-set r0 as well, but I haven't figured out what the algorithm assumes. Steve Summit