home *** CD-ROM | disk | FTP | other *** search
/ RBBS in a Box Volume 1 #3.1 / RBBSIABOX31.cdr / typd / turbobug.tlk < prev    next >
Encoding:
Text File  |  1990-09-29  |  7.4 KB  |  198 lines
  1.             ***** BUG REPORT *****
  2.      ***** MAJOR BUG IN TURBO PASCAL V2.00 *****
  3.              July 1,1984
  4.  
  5.  
  6.      The runtime routines  do  not  handle  a  floating-point
  7. (real)    subtraction  correctly.  For  some subtractions,  the
  8. correct  difference  is  returned;  for  others,  a  zero  is
  9. returned. The following program demonstrates the bug:
  10.  
  11. program test;
  12. begin
  13.      writeln(9.+(-6.0));    { Wrong value returned }
  14.      writeln(-1.0+(-1.0));    { Correct value returned }
  15.      writeln(1-2);        { Correct value returned }
  16.      writeln(1.-2:10:2);    { Wrong value returned }
  17.      writeln(1.-2.0);        { Wrong value returned }
  18.      writeln(1-2.0);        { Wrong value returned }
  19.      writeln(456 - 123.0);    { Correct value returned }
  20. end.
  21.  
  22. A value of zero is returned on those lines marked as 'wrong'.
  23. The other lines return the correct difference.
  24.  
  25.  
  26. THE CAUSE
  27.  
  28.     After disassembling and tracing through a sample compiled
  29. program, the error was located in the following code:
  30.  
  31. XXXX:12FA E84FFF    CALL    124C        ; Subtract
  32. XXXX:12FD 7306        JNB    1305
  33. XXXX:12FF 80F780    XOR    BH,80        ; Handle negative
  34. XXXX:1302 E863FF    CALL    1268        ;   numbers
  35. XXXX:1305 8B4504    MOV    AX,[DI+04]    ; Is mantissa zero?
  36. XXXX:1308 0B4502    OR    AX,[DI+02]
  37. XXXX:130B 0A4501    OR    AL,[DI+01]    ; ***** ERROR *****
  38. XXXX:130E 740D        JZ    131D        ; Yes
  39. XXXX:1310 F6450580    TEST    BYTE PTR [DI+05],80  ; Normalize
  40. XXXX:1314 750C        JNZ    1322
  41.  
  42. (Comments  have  been  added for clarity).  This disassembled
  43. code is located in the    routines  that    handle    addition  and
  44. subtraction  (only the subtraction part is shown).  The error
  45. occurs when the routine tests to see if  the  result  of  the
  46. subtraction is zero. It tests for a zero by "OR-ing" together
  47. the five bytes of the mantissa (the instructions that do this
  48. are at offsets 1305H to 130BH). If the mantissa is zero, then
  49. the result of this "multiple-or" will set the zero flag.  The
  50. first  of  these instructions is a move of the word at [DI+4]
  51. to AX.    The next instruction takes the logical OR of  AX  and
  52. [DI+2].  No problem so far.  However, the last instruction is
  53. "OR AL,[DI+1]",  an instruction that operates on a  byte  and
  54. not  on  a word.  If the OR of the words at [DI+4] and [DI+2]
  55. results in a word whose UPPER byte is NONZERO but whose LOWER
  56. byte is ZERO,  then the next instruction, the "byte-wise" OR,
  57. will SET the zero flag if the byte at [DI+1] is zero.  Notice
  58. that the instruction at 130BH totally ignores the contents of
  59. the upper byte of AX;  the flags are  set  according  to  the
  60. lower byte of AX only.    This is what causes the error.
  61.  
  62.  
  63. THE FIX
  64.  
  65.      The fix to this bug is simple: simply exchange the order
  66. of the two "OR" instructions.  This way, the zero flag is set
  67. according  to  a  full    16-bit    OR  and  not  an  8-bit  one.
  68. IMPORTANT:  Only persons familiar with the operation of DEBUG
  69. should    attempt  the  following.  Using DEBUG,    the following
  70. sequence of commands can be used to fix the bug:
  71.  
  72.      Assumptions and notes in the following:
  73.       1) ONLY WORK ON A COPY OF TURBO!  DO    NOT  USE
  74.          YOUR MASTER COPY!
  75.       2) The sequence of commands shown below writes
  76.          out  the    fixed    version   to   the  file
  77.          'turbo.com'
  78.       3) Make sure that you have version 2.00
  79.       4) 'turbo.com'   must   be   in   the  current
  80.          directory on drive B.
  81.       5) DOS  2.00    or  above  is  being  used  (the
  82.          debugger in DOS 1.00 and 1.10 does not have
  83.          the 'assemble' command).
  84.       6) Be  sure  to  verify  that  the code in the
  85.          compiler is the same as  that  shown  below
  86.          initially.  After the changes are made,  be
  87.          sure to verify that the changes  have  been
  88.          made  correctly  before  writing  the fixed
  89.          version out to disk.
  90.  
  91. B>debug turbo.com
  92. -u 12fa         <- Verify the following locations
  93. XXXX:12FA E84FFF    CALL    124C
  94. XXXX:12FD 7306        JNB    1305
  95. XXXX:12FF 80F780    XOR    BH,80
  96. XXXX:1302 E863FF    CALL    1268
  97. XXXX:1305 8B4504    MOV    AX,[DI+04]
  98. XXXX:1308 0B4502    OR    AX,[DI+02]
  99. XXXX:130B 0A4501    OR    AL,[DI+01]
  100. XXXX:130E 740D        JZ    131D
  101. XXXX:1310 F6450580    TEST    BYTE PTR [DI+05],80
  102. XXXX:1314 750C        JNZ    1322
  103. XXXX:1316 E8F9FE    CALL    1212
  104. XXXX:1319 FE0D        DEC    BYTE PTR [DI]
  105. -a 1308         <- Make changes
  106. XXXX:1308 or al,[di+1]
  107. XXXX:130E or ax,[di+2]
  108. XXXX:1311            <- Press 'enter'
  109. -u 12fa         <- Verify that the changes are correct
  110. XXXX:12FA E84FFF    CALL    124C
  111. XXXX:12FD 7306        JNB    1305
  112. XXXX:12FF 80F780    XOR    BH,80
  113. XXXX:1302 E863FF    CALL    1268
  114. XXXX:1305 8B4504    MOV    AX,[DI+04]
  115. XXXX:1308 0A4501    OR    AL,[DI+01]
  116. XXXX:130B 0B4502    OR    AX,[DI+02]
  117. XXXX:130E 740D        JZ    131D
  118. XXXX:1310 F6450580    TEST    BYTE PTR [DI+05],80
  119. XXXX:1314 750C        JNZ    1322
  120. XXXX:1316 E8F9FE    CALL    1212
  121. XXXX:1319 FE0D        DEC    BYTE PTR [DI]
  122. -w            <- Save fixed version of turbo
  123. Writing 8E80 bytes
  124. -q
  125.  
  126. B>
  127.  
  128. <end of fix>
  129.  
  130.  
  131. OTHER NOTES ABOUT TURBO
  132.  
  133.      One  cannot  set  breakpoints  in TURBO using DEBUG.  It
  134. seems that TURBO  uses    the  breakpoint  interrupt  for  some
  135. hideous  reason.  If  one  attempts  to set breakpoints,  the
  136. system will probably crash.  Tracing,  however,  does seem to
  137. work.  The  above  bug    was  tracked down only after hours of
  138. tracing (by maching and by hand) and disassembling.
  139.  
  140.  
  141. Additional remarks from CompuServe:
  142.  
  143.  
  144.  #: 17310      Sec. 4 - High-Level Langs.
  145. Sb: #Turbo Pascal
  146.     04-Sep-84  20:50:42
  147. Fm: Borland International     71016,1573
  148. To: David J. Jones  72345,357
  149.  
  150. The bug in version 2.00a did not occur in the cp/m 80
  151. version.  Under MS DOS real # subtraction which should have produced a negative
  152. result always produced a zero for a result.  People with this bug can get a
  153. return authorization number from us and we will swap their master disk for a
  154. ver. 2.00B.  Operating under cp/m 80, your version 2.00A is the current version
  155. so you don't need a replacement.
  156. We don't yet know whether or not the C or the Modula 2 compiler will run under
  157. cp/m 80.
  158.  
  159.  #: 17317      Sec. 4 - High-Level Langs.
  160. Sb: Turbo Pascal 2.00
  161.     04-Sep-84  22:05:26
  162. Fm: Borland International     71016,1573
  163. To: Bill McArthur   75226,3142
  164.  
  165. Sounds like you got the IBM version.  If the label reads "MS DOS IBM PC then it
  166. is definitely the IBM PC version.  You can call ((408) 438-8400) or write
  167. (address on cover of reference manual).  You will then be given a return
  168. authorization number and we will arrange to swap your master disk for a generic
  169. MS DOS Turbo.
  170.  
  171. And a test program:
  172.  
  173. program turbotest;
  174.  
  175. {by Larry Weiss, Garland, Tx}
  176.  
  177. {There apparently was an early release of Turbo Pascal 2.0 for the IBM PC
  178.  that had a flaw in the code generated to handle real arithmetic.  Here
  179.  is some information that can help owners determine if they need to patch
  180.  or replace their copy.  My copy is apparently OK (I have version 2.00B),
  181.  so I have not had the opportunity to test a bad copy.}
  182.  
  183. { From "Journal of Pascal,Ada & Modula-2" July-August 1984 (reader's forum)
  184. "Owners of an IBM PC who have bought a copy of Turbo Pascal should be aware
  185.  of a serious bug in the "reals" arithmetic in some versions of Turbo Pascal.
  186.  To see if your copy has this bug, run the following program.  In the correct
  187.  versions the value of C will be 1.0 until the value of A is (2.0)^40.    The
  188.  incorrect versions get C=0.0 when A=(2.0)^16."}
  189.  
  190. var a,b,c :real;   i:integer;
  191. begin  a:=2.0; b:=a+1.0; c:=b-a;i:=1;
  192.   repeat i:=i+1; a:=2.0*a; b:=a+1.0; c:=b-a until c<>1.0;
  193.   if i>=40 then writeln('Good version of Turbo Pascal') else
  194.         writeln('Bad version of Turbo Pascal');
  195.   writeln('i=',I:2);
  196.  
  197. end.
  198. 40 then writeln('Good version of Turbo