home *** CD-ROM | disk | FTP | other *** search
/ minnie.tuhs.org / unixen.tar / unixen / PDP-11 / Documentation / PUPS_Html / v7_longdivide_bug.txt < prev   
Encoding:
Text File  |  1998-03-17  |  2.9 KB  |  74 lines
  1. The enclosed will probably be of interest to anyone who wants to run V7
  2. on semi-modern hardware. It comes from Henry Spencer <henry@spsystems.net>
  3.  
  4. --------
  5. >From decvax!harpo!utah-cs!lepreau Thu Oct 21 09:32:40 1982
  6. Subject: Re: 11/24 and 11/44 printf problems
  7. Newsgroups: net.unix-wizards
  8.  
  9. I expect this is the solution.  It gave me a hell of a time one night a
  10. year or so ago when some date conversion routines suddenly started
  11. breaking.  This one is worth saving... it is wrong in 2.8 bsd too. Kudos
  12. to Henry and the folks in Canada.
  13. -Jay Lepreau
  14.  
  15. >From harpo!mhtsa!ihnss!ucbvax!decvax!utzoo!henry Tue Dec  1 06:46:23 1981
  16. Subject: ldiv bug fix
  17. Newsgroups: net.v7bugs
  18. The ldiv bug reported by watmath!egisin seems to be yet another bit of
  19. bad behavior in ldiv that is fixed by the div-abort bugfix I put out on
  20. net.v7bugs in May.  At least, his example works fine here.
  21.  
  22. >From randvax!decvax!utzoo!henry  Fri Dec 11 04:37:29 1981
  23. Subject: ldiv bug
  24.  
  25. Following are the two articles I sent describing the bug and the fix.
  26. It also seems to fix yet another bug:  (unsigned)32768/1 supposedly
  27. used to screw up.
  28.  
  29.                         Henry Spencer
  30.  
  31. Autzoo.643
  32. NET.v7bugs
  33. utzoo!henry
  34. Thu May 21 20:22:51 1981
  35. ldiv/lrem on 44,23
  36. The V7 long-int divide and remainder routines, as distributed by Bell,
  37. make an invalid assumption about the DIV instruction on the 11.  DIV
  38. aborts if the quotient is too big for a signed 16-bit number;  the
  39. routines assume that the dividend register pair is untouched afterwards.
  40. This was generally true on early 11's, but Dec has never guaranteed it
  41. and it is NOT TRUE on the 11/44.  111111111 [that's nine 1's] % 10 yields 11.
  42.  
  43. The fix is fairly easy;  it's the same fix for all six occurrences: the 
  44. libc ldiv, lrem, aldiv, and alrem, and the kernel ldiv and lrem in mch.s .
  45. Look for a DIV followed by a BVC.  If the BVC falls through, r0 and r1
  46. must be put back as they were before the DIV.  Specifically:
  47.  
  48.     1. Before DIV, add "mov r0,-(sp)".
  49.     2. After BVC, add "mov r2,r1" and "mov (sp),r0".
  50.     3. After label "1", about 6 lines down, add "tst (sp)+".
  51.  
  52. The fixed-up routines function properly whether the particular cpu manifests
  53. the problem or not, so this fix can be universally applied.
  54.  
  55. This also may have cured the largest-negative-dividend bug that the
  56. V7-addenda-tape README alludes to;  at least, I can't reproduce said bug.
  57.  
  58. Another local installation has discovered that similar divide anomalies
  59. occur on the 11/23 and can be cured with the same fixes.  I do not have
  60. a test case for the 23;  111111111%10 works fine on it.
  61.  
  62. Autzoo.681
  63. NET.v7bugs
  64. utzoo!henry
  65. Tue Jun  2 16:08:27 1981
  66. ldiv/lrem on 23, ch.2
  67. Addendum to my previous NET.v7bugs message about the ldiv/lrem bug on
  68. the 44 and 23:  the people who discovered that the problem also occurs
  69. on the 23 have supplied test cases.  If you want to see the problem on
  70. a 23, try  11335500/100  or  11335577%100  .  Thanks to Chris Sturgess
  71. and Ron Gomes of Human Computing Resources for this one.
  72.  
  73. --------
  74.