home *** CD-ROM | disk | FTP | other *** search
/ ftp.barnyard.co.uk / 2015.02.ftp.barnyard.co.uk.tar / ftp.barnyard.co.uk / cpm / walnut-creek-CDROM / CPM / TURBOPAS / TURBOBUG.TXT < prev    next >
Text File  |  2000-06-30  |  6KB  |  156 lines
  1.  
  2.                     ***** BUG REPORT *****
  3.          ***** MAJOR BUG IN TURBO PASCAL V2.00 *****
  4.                          July 1,1984
  5.                     (updated December 1984)
  6.  
  7.  
  8.      The runtime routines  do  not  handle  a  floating-point 
  9. (real)  subtraction  correctly.  For  some subtractions,  the 
  10. correct  difference  is  returned;  for  others,  a  zero  is 
  11. returned. The following program demonstrates the bug:
  12.  
  13. program test;
  14. begin
  15.      writeln(9.+(-6.0));        { Wrong value returned }
  16.      writeln(-1.0+(-1.0));      { Correct value returned }
  17.      writeln(1-2);              { Correct value returned }
  18.      writeln(1.-2:10:2);        { Wrong value returned }
  19.      writeln(1.-2.0);           { Wrong value returned }
  20.      writeln(1-2.0);            { Wrong value returned }
  21.      writeln(456 - 123.0);      { Correct value returned }
  22. end.
  23.  
  24. A value of zero is returned on those lines marked as 'wrong'. 
  25. The other lines return the correct difference.
  26.  
  27.  
  28.  
  29. VERSIONS TESTED AND FOUND OK (December 1984)
  30.  
  31. The following versions of Turbo have been checked for this bug 
  32. and are alright.  Any versions for same OS, with higher serial 
  33. numbers, should be alright--but  use the above test program to 
  34. be sure.  The bug may be unique to MS-DOS versions.
  35.  
  36.     Turbo  ver 1.01A for CP/M-86    serial #  1225
  37.     Turbo  ver 2.00B for CP/M-86    serial # 49036
  38.     Turbo  ver 2.00B for MS-DOS     serial #131821
  39.  
  40.  
  41. THE CAUSE
  42.  
  43.     After disassembling and tracing through a sample compiled 
  44. program, the error was located in the following code:
  45.  
  46. XXXX:12FA E84FFF        CALL    124C            ; Subtract
  47. XXXX:12FD 7306          JNB     1305
  48. XXXX:12FF 80F780        XOR     BH,80           ; Handle negative
  49. XXXX:1302 E863FF        CALL    1268            ;   numbers
  50. XXXX:1305 8B4504        MOV     AX,[DI+04]      ; Is mantissa zero?
  51. XXXX:1308 0B4502        OR      AX,[DI+02]
  52. XXXX:130B 0A4501        OR      AL,[DI+01]      ; ***** ERROR *****
  53. XXXX:130E 740D          JZ      131D            ; Yes
  54. XXXX:1310 F6450580      TEST    BYTE PTR [DI+05],80  ; Normalize
  55. XXXX:1314 750C          JNZ     1322
  56.  
  57. (Comments  have  been  added for clarity).  This disassembled 
  58. code is located in the  routines  that  handle  addition  and 
  59. subtraction  (only the subtraction part is shown).  The error 
  60. occurs when the routine tests to see if  the  result  of  the 
  61. subtraction is zero. It tests for a zero by "OR-ing" together 
  62. the five bytes of the mantissa (the instructions that do this 
  63. are at offsets 1305H to 130BH). If the mantissa is zero, then 
  64. the result of this "multiple-or" will set the zero flag.  The 
  65. first  of  these instructions is a move of the word at [DI+4] 
  66. to AX.  The next instruction takes the logical OR of  AX  and 
  67. [DI+2].  No problem so far.  However, the last instruction is 
  68. "OR AL,[DI+1]",  an instruction that operates on a  byte  and 
  69. not  on  a word.  If the OR of the words at [DI+4] and [DI+2] 
  70. results in a word whose UPPER byte is NONZERO but whose LOWER 
  71. byte is ZERO,  then the next instruction, the "byte-wise" OR, 
  72. will SET the zero flag if the byte at [DI+1] is zero.  Notice 
  73. that the instruction at 130BH totally ignores the contents of 
  74. the upper byte of AX;  the flags are  set  according  to  the 
  75. lower byte of AX only.  This is what causes the error.
  76.  
  77.  
  78. THE FIX
  79.  
  80.      The fix to this bug is simple: simply exchange the order 
  81. of the two "OR" instructions.  This way, the zero flag is set 
  82. according  to  a  full  16-bit  OR  and  not  an  8-bit  one. 
  83. IMPORTANT:  Only persons familiar with the operation of DEBUG 
  84. should  attempt  the  following.  Using DEBUG,  the following 
  85. sequence of commands can be used to fix the bug:
  86.  
  87.      Assumptions and notes in the following:
  88.           1) ONLY WORK ON A COPY OF TURBO!  DO  NOT  USE 
  89.              YOUR MASTER COPY!
  90.           2) The sequence of commands shown below writes 
  91.              out  the   fixed   version   to   the  file 
  92.              'turbo.com'
  93.           3) Make sure that you have version 2.00
  94.           4) 'turbo.com'   must   be   in   the  current 
  95.              directory on drive B.
  96.           5) DOS  2.00  or  above  is  being  used  (the 
  97.              debugger in DOS 1.00 and 1.10 does not have 
  98.              the 'assemble' command).                           
  99.           6) Be  sure  to  verify  that  the code in the 
  100.              compiler is the same as  that  shown  below 
  101.              initially.  After the changes are made,  be 
  102.              sure to verify that the changes  have  been 
  103.              made  correctly  before  writing  the fixed 
  104.              version out to disk.
  105.  
  106. B>debug turbo.com
  107. -u 12fa             <- Verify the following locations
  108. XXXX:12FA E84FFF        CALL    124C
  109. XXXX:12FD 7306          JNB     1305
  110. XXXX:12FF 80F780        XOR     BH,80
  111. XXXX:1302 E863FF        CALL    1268
  112. XXXX:1305 8B4504        MOV     AX,[DI+04]
  113. XXXX:1308 0B4502        OR      AX,[DI+02]
  114. XXXX:130B 0A4501        OR      AL,[DI+01]
  115. XXXX:130E 740D          JZ      131D
  116. XXXX:1310 F6450580      TEST    BYTE PTR [DI+05],80
  117. XXXX:1314 750C          JNZ     1322
  118. XXXX:1316 E8F9FE        CALL    1212
  119. XXXX:1319 FE0D          DEC     BYTE PTR [DI]
  120. -a 1308             <- Make changes
  121. XXXX:1308 or al,[di+1]
  122. XXXX:130E or ax,[di+2]
  123. XXXX:1311                       <- Press 'enter'
  124. -u 12fa             <- Verify that the changes are correct
  125. XXXX:12FA E84FFF        CALL    124C
  126. XXXX:12FD 7306          JNB     1305
  127. XXXX:12FF 80F780        XOR     BH,80
  128. XXXX:1302 E863FF        CALL    1268
  129. XXXX:1305 8B4504        MOV     AX,[DI+04]
  130. XXXX:1308 0A4501        OR      AL,[DI+01]
  131. XXXX:130B 0B4502        OR      AX,[DI+02]
  132. XXXX:130E 740D          JZ      131D
  133. XXXX:1310 F6450580      TEST    BYTE PTR [DI+05],80
  134. XXXX:1314 750C          JNZ     1322
  135. XXXX:1316 E8F9FE        CALL    1212
  136. XXXX:1319 FE0D          DEC     BYTE PTR [DI]
  137. -w                  <- Save fixed version of turbo
  138. Writing 8E80 bytes
  139. -q
  140.  
  141. B>
  142.  
  143. <end of fix>
  144.  
  145.  
  146. OTHER NOTES ABOUT TURBO
  147.  
  148.      One  cannot  set  breakpoints  in TURBO using DEBUG.  It 
  149. seems that TURBO  uses  the  breakpoint  interrupt  for  some 
  150. hideous  reason.  If  one  attempts  to set breakpoints,  the 
  151. system will probably crash.  Tracing,  however,  does seem to 
  152. work.  The  above  bug  was  tracked down only after hours of 
  153. tracing (by machine and by hand) and disassembling.
  154.  
  155.     --------
  156.