From: dmurdoch@watstat.waterloo.edu (Duncan Murdoch)
Subject: Re: Norbert Juffa's bug list (part 2 of 2)
Organization: University of Waterloo
Date: Tue, 7 Apr 1992 15:58:31 GMT




16. Incorrect assembly of certain JMPs and CALLs by inline assembler

     The inline assembler will incorrectly assemble certain JMPS and
     CALLs that are invalid and are rejected by the MASM and TASM
     assemblers. It will also incorrectly assemble JMPs and CALLs to
     destination declared with the ABSOLUTE directive. The bugs can
     be demonstrated by the following program:

     PROGRAM Jmp_Call;

 
    VAR AbsPointer: POINTER ABSOLUTE $1234:$5678;
         NormPointr: POINTER;

     PROCEDURE FarProc; FAR; ASSEMBLER;
     ASM
     END;

     PROCEDURE NearProc; NEAR; ASSEMBLER;
     ASM
     END;

     BEGIN
     ASM
        JMP  NEAR PTR AbsPointer   { This is illegal in MASM / TASM }
        JMP  FAR PTR AbsPointer    { incorrectly assembled by inline assmbl.! }
        JMP  AbsPointer            { This is illegal in MASM / TASM }
        JMP  NEAR PTR NormPointr   { This is illegal in MASM / TASM }
        JMP  FAR PTR NormPointr
        JMP  NormPointr
        JMP  NEAR PTR FarProc
        JMP  FAR PTR FarProc
        JMP  FarProc
        JMP  NEAR PTR NearProc
        JMP  FAR PTR NearProc
        JMP  NearProc
        CALL NEAR PTR AbsPointer   { This is illegal in MASM / TASM }
        CALL FAR PTR AbsPointer    { incorrectly assembled by inline assmbl.! }
        CALL AbsPointer            { This is illegal in MASM / TASM }
        CALL NEAR PTR NormPointr   { This is illegal in MASM / TASM }
        CALL FAR PTR NormPointr
        CALL NormPointr
        CALL NEAR PTR FarProc
        CALL FAR PTR FarProc
        CALL FarProc
        CALL NEAR PTR NearProc
        CALL FAR PTR NearProc
        CALL NearProc
     END;
     END.


     The instructions marked as "illegal in MASM / TASM" should be
     flagged as errors by the inline assembler. "JMP NEAR PTR AbsPointer"
     and "JMP NEAR PTR NormPointr" are near jumps to a different CS,
     and in "JMP AbsPointer", AbsPointer can't be addressed with the
     currently assumed registers. The same remarks apply to the
     equivalent CALL statements in the source. Consequently, the
     inline assembler produces garbage for the illegal statements.
     "JMP FAR PTR AbsPointer" should assemble to "JMP 1234:5678", but
     the inline assembler produces something very different. Instead
     of the absolute segment 1234h it uses the value of CS and in
     addition mangles the offset value. The assembly language program
     below, which is equivalent to the above PASCAL program, shows
     that "JMP FAR PTR AbsPointer" and "CALL FAR PTR AbsPointer" can
     be assembled correctly by TASM / MASM, so the inline assembler
     should do this as well.


                DOSSEG

     AbsSeg     SEGMENT AT 1234h
                ORG     5678H
     AbsPointer DD      ?
     AbsSeg     ENDS


     DATA       SEGMENT WORD PUBLIC 'DATA'
                ASSUME  DS:DATA
     NormPointr DD      ?
     DATA       ENDS


     CODE       SEGMENT BYTE PUBLIC 'CODE'
                ASSUME  CS:CODE, DS:DATA

     FarProc    PROC    FAR
                RET
     FarProc    ENDP

     NearProc   PROC    NEAR
                RET
     NearProc   ENDP

     Main:      MOV     AX, SEG (NormPointr)
                MOV     DS, AX
     ;          JMP     NEAR PTR AbsPointer ; error !
                JMP     FAR PTR AbsPointer
     ;          JMP     AbsPointer          ; error !
     ;          JMP     NEAR PTR NormPointr ; error !
                JMP     FAR PTR NormPointr
                JMP     NormPointr
                JMP     NEAR PTR FarProc
                JMP     FAR PTR FarProc
                JMP     FarProc
                JMP     NEAR PTR NearProc
                JMP     FAR PTR NearProc
                JMP     NearProc
     ;          CALL    NEAR PTR AbsPointer ; error !
                CALL    FAR PTR AbsPointer
     ;          CALL    AbsPointer          ; error !
     ;          CALL    NEAR PTR NormPointr ; error !
                CALL    FAR PTR NormPointr
                CALL    NormPointr
                CALL    NEAR PTR FarProc
                CALL    FAR PTR FarProc
                CALL    FarProc
                CALL    NEAR PTR NearProc
                CALL    FAR PTR NearProc
                CALL    NearProc

     CODE       ENDS


     STACK      SEGMENT STACK
                DB      100h DUP (?)
     STACK      ENDS

                END     MAIN


17. Other bugs in the inline assembler (ASM directive)

     Several instructions that have a format with an immediate operand
     support senseless or incorrect ranges for the immediate value. The
     IN, OUT, and INT instructions will accept values between -128 and
     255. Since negative values make no sense here, the possible range
     should be restricted to 0 to 255. The ENTER instruction will also
     take negative arguments. Again, this is not a very sensible choice.
     How are -5 bytes reserved for local variables? The allowed range
     for the arguments should be 0 to 255 and 0 to 65535, respectively.
     Although it is not officially documented by Intel, the AAM and AAD
     instructions may take additional arguments that indicate the base
     on which to perform the conversion. This is supported by the inline
     assembler. However, it accepts arguments between -128 and 127 while
     it should accept bases between 0 and 255, since the bases available
     with AAM and AAD must be positive.

     The inline assembler performs no check on the index in
     the stack top relative addressing mode of the coprocessor.
     Very large or even negative values are allowed. For example,
     FADD ST, ST(123456) will be accepted as perfectly legal.
     This must be fixed to make sure the index is between zero and
     seven.

     There is no way to code an absolute far jump such as JMP F000:FFF0
     (to perform a warm start). The same restriction applies to far
     calls. In a conventional assembler such a jump could be coded as
     follows:

     BIOS     SEGMENT AT 0F000h
     ORG      0FFF0h
     Restart  LABEL FAR
     BIOS     ENDS

     CODE     SEGMENT BYTE PUBLIC 'CODE'
     JMP      Restart
     CODE     ENDS

     There are no segment declarations available with the inline
     assembler, so the jump has to be either hand coded with DBs or
     changed to a memory indirect far jump using a appropriately
     initialized pointer. This problem should be documented in
     the Turbo-Pascal manuals.

     One of the standard syntax available with the IMUL instruction is
     not accepted by the inline assembler. IMUL reg16, immed8 is not
     allowed, rather the inline assembler expects this to be coded as
     IMUL reg16, reg16, immed8, where the two registers are identical.
     The IMUL reg16, immed8 is commonly accepted by assemblers and is
     also listed in Intel's documentation. Therefore, this syntax should
     be supported by the inline assembler.

     Some 286 protected mode instructions (LLDT, LMSW, LTR, SMSW, VERR,
     VERW) when used with memory operands require the use of the PTR
     directive to establish operand size with an untyped operand (e.g.,
     [BX+SI]). Two other instruction, SGDT and SIDT, do not require the
     use of PTR in these cases. This usage is inconsistent. Since the
     operand size can be deduced from the instructions itself (just as
     can be done in the case of a MOV AX, [BX]) no PTR directive at all
     should be required. Likewise, the POP mem16 instruction should not
     require a WORD PTR directive with an untyped memory operand, since
     memory operand size is obvious from the instruction.



18. Errors / problems / documentation deficiencies using coprocessor
     instructions with the new ASM directive of TP 6.0

     In the $G+,N+ compiler mode the inline assembler does not
     assemble coprocessor instructions into emulator interrupts
     regardless of the $E switch setting. Instead it always generates
     optimized coprocessor instructions (without inserted WAITs).
     This causes programs compiled with $G+,N+,E+ to fail if no
     coprocessor is present. The assembler must ensure that the
     $E switch is off before performing this optimization.

     Coprocessor instructions in the no-wait form (e.g. FNINIT,
     FNSTSW, FNSTCW, FNSTENV, FNCLEX) are not encoded into emulator
     interrupts, since it makes no sense to use them with the
     emulator which cannot work in parallel with the CPU. This
     may lead to problems if programmers are not aware of the
     fact that these instructions will have absolutely no effect
     in an emulator environment. Since it is desirable to have the
     no-wait instructions available, programmers should be warned
     by the documentation not to use them in programs or routines
     that may be executed by the emulator or to explicitly code
     around this problem by using the system variable Test8087.

     An example of a work around solution follows.

     ASM
        .                         { some other code }
        .
        CMP   Test8087, 0         { coprocessor present ? }
        JNE   @Emulate            { no, do specific code for emulator}
        FNINIT                    { can be safely used with 8087 }
        JMP   @Continue           { skip emulator code }

        @Emulate:
        FINIT                     { this can be emulated }

        @Continue:                { continue with more code }
        .
        .
     END;



19. Inconsistent error messages emitted by inline assembler

     When constants that are out of range are supplied to assembler
     instructions that take some kind of immediate operand, two different
     error messages are emitted depending on the type of the destination
     operand. If the destination operand is a byte operand, as in
     ADD AL, 256 the compilation will result in error 155, 'Invalid
     combination of opcode and operands'. However, if the destination
     is a word operand as in ADD AX, 65536 the resulting error will be
     #76, 'Constant out of range'. This discrepancy should be resolved
     by always emitting the 'Constant out of range' error when an
     immediate value is not within the specified limits called for by the
     destination operand.

     Instructions that require one of their operands to be a memory
     reference (BOUND, LDS, LES, LEA, SGDT, SIDT, LGDT, LIDT) should
     cause compile error 156 (memory reference expected) to be emitted
     when a register is supplied instead of a memory reference. This
     will give a more detailed description of the error than the
     currently used error 155 (invalid combination of opcode and
     operand).

     There are space saving sign extending encodings available for OR,
     AND, and XOR instructions that the inline assembler fails to use.
     These encodings are the equivalents of the sign extending encodings
     used with the ADD, ADC, SUB, SBB, and CMP instructions. A list of
     the additional instructions follows:

     Instruction          | Encoding
     ---------------------+-------------------------------------------
     OR  reg16, const8    | 83   mod 001 r/m    data8
     OR  mem16, const8    | 83   mod 001 r/m   (disp)   (disp)   data8
     AND reg16, const8    | 83   mod 100 r/m    data8
     AND mem16, const8    | 83   mod 100 r/m   (disp)   (disp)   data8
     XOR reg16, const8    | 83   mod 110 r/m    data8
     XOR mem16, const8    | 83   mod 110 r/m   (disp)   (disp)   data8


20. Compiler Switch /V doesn't export names of SYSTEM routines

     When using the /V of TPC or choosing standalone debugging within
     the Turbo Pascal IDE, all public identifiers are supposed to be
     included into the EXE file for debugging purposes. However, the
     names of just about every routine from the SYSTEM unit are not
     included, although the variables (such as HeapOrg) are included.
     Among the few exceptions are the MemAvail and MaxAvail routines,
     which are sometimes included into the debug information. This bug
     is very annoying when programs are profiled with the Turbo Profiler
     and one wants to know how much time the program spends in certain
     SYSTEM routines. Also, when debugging programs with Turbo Debugger
     one would rather like the disassembly to display a call as e.g.
     CALL SYSTEM.LONGMUL instead of a cryptic CALL 152E:05B8. This makes
     the disassembled code hard to follow. I therefore urge Borland to
     assure correct inclusion of *all* public symbols in the debug
     information generated by the /V switch.



21. Problem with AAM xx and AAD xx instructions when stepping/tracing
    through inline ASM code with Turbo-Pascal's build-in debugger

     The inline assembler correctly allows parameters with the AAM and
     AAD instructions. Although this feature is not officially documented
     by Intel, it works on all 80x86 processors and compatibles, such as
     NEC's V30. The inline assembler will correctly assemble an instruction
     like AAM 16, which is quite useful when one wants to print a number
     in hexadecimal format. Turbo-Pascal's internal debugger does not
     recognize AAM opcodes other than the plain AAM opcode. When stepping/
     tracing through inline assembly code, it seems to skip the instruction,
     causing the program to behave differently than in an ordinary run.
     For example, the following instruction sequence will give 0505 in AX
     when run on any 80x86, but will give 0055 in AX when stepped through
     with Turbo-Pascal's internal debugger.
     .
     .
     MOV  AX, 0055h
     AAM  16
     .                   { AX should contain 0505h now }

     Another example involving the AAD instruction will give 0066h in AX
     when simply run, but AX will contain 00CEh when the code is stepped.
     .
     .
     MOV  AX, 0606h
     AAD  16
     .                   { AX should contain 0066h now }



22. Error in heap manager (GetMem, New)

     Turbo-Pascal 6.0 allows memory allocation functions to allocate
     data structures of more than 65528 bytes on the heap. Data
     structures on the heap of size greater than 65528 bytes may
     cause segment wrap-around, thereby destroying other data on the
     heap or causing a general protection exception on processors
     from the 80286 on upwards. This general protection exception
     #GP(0) is triggered when a word is accessed at offset FFFFh in
     a segment, even when the processor is in real mode. With no valid
     #GP(0) handler present, the system will crash upon returning
     from the INT 0Dh service routine since the exception has pushed
     an error code *after* pushing the return address, which will not
     be removed from the stack without a valid #GP(0) handler present
     when the INT ODh executes it's IRET. 386 memory managers like
     QEMM or the DOS-box of Windows in 386-Enhanced catch a #GP(0)
     exception, but plain DOS, even with MS-DOS 5.0, crashes. The
     following program illustrates the problems:


     PROGRAM HeapBug;

     TYPE SpcRecord  = RECORD
                          W1: WORD;
                          W2: WORD;
                          B1: BYTE;
                       END;
          SmallArray = ARRAY [1..8] OF CHAR;
          BigArray   = ARRAY [1..65535] OF CHAR;
          SpcArray   = ARRAY [1..13107] OF SpcRecord;


     VAR P1  : ^SmallArray;
         P2  : ^BigArray;
         P3  : ^SpcArray;
         Hptr: POINTER;

     BEGIN
        HPtr := HeapPtr;           { save initial value of heap pointer }
        WHILE HeapPtr = HPtr DO BEGIN
           New (P1);               { use up blocks in freelist }
        END;
        IF Ofs (HeapPtr^) <> 8 THEN
           New (P1);               { make sure large array will have ofs of 8 }
        New (P2);
        FillChar (P1^, 8, 'A');    { initialize 1st array }
        FillChar (P2^, 65534, 'B');{ initialize 2nd array -> trashes 1st array }
        IF P1^[6] <> 'A' THEN      { chk if 1st array's integrity was violated }
           WriteLn ('First array trashed!');
        P3 := Pointer (P2);
        P3^[13106].W2 := $55AA;    { access at ofs FFFF causes #GP(0) on 80286 }
     END.

     The problem here is that 80x86 segments start at 16-byte boundaries
     (paragraph boundaries), while allocation of data structures on the
     heap is aligned at 8-byte boundaries. If a data structure in the
     heap has a start address with an offset of 8 and is greater than
     65528 bytes, accessing the very last bytes of that data structure
     will cause undesired segment wrap around. Therefore, maximum allowed
     allocation for data structures on the heap should be 65528 bytes.



23. Logical error in GRAPH.TextWidth function

     The TextWidth function delivers uncorrect results when fonts
     are scaled with the SetUserCharSize procedure. To compute the
     width of the string passed to it, the TextWidth function adds
     the width of all characters in the string. Depending on the
     current setting of the Direction parameter within GRAPH the
     resulting value is then multiplied and divided by either the
     MultX and DivX or the MultY and DivY scaling factors. If these
     scaling factors are not unity, this method will compute the
     wrong text width. Since text justification using the OutTextXY
     and SetTextJustify procedures relies on the TextWidth function
     for computing the starting position for string output, this
     output is not correctly justified. The TextWidth function, when
     used with user supplied font scaling factors, usually returns
     a width that is bigger than the actual width of the string. The
     correct way to compute text width is to compute the actual size
     of every character in the string using the scale factors supplied
     by the user and add these values up. An example:

     Suppose we want to compute the width of the string 'World'.
     Assume that the unscaled width of the characters as taken from
     the font information is 10, 7, 7, 5, 7, the output direction is
     horizontal and that the scale factors are MultX = 5 and DivX = 8.
     The current implementation of TextWidth would compute the width
     as ((10+7+7+5+7) * 5) DIV 8 = (36 * 5) DIV 8 = 180 DIV 8 = 22.
     A correct implementation however, would calculate the width as
     follows: (10*5) DIV 8 + 3 * (7*5) DIV 8 + (5*5) DIV 8 = (6+12+3)
     = 21. This version is correct since it uses character sizes as
     used in the OutText and OutTextXY procedures.



24. Length of descender not taken into account by SetTextJustify

     If text is to be written at the very bottom of the current
     graphics window, one uses SetTextJustify (AnyMode, BottomText)
     and OutTextXY (AnyX, ViewMaxY, AnyText) to accomplish that.
     However, if the text contains letters that decend below the
     base line for letters, descenders are outside the window and
     clipped off. If one wants to output text in the manner described,
     this is very annoying, since the programmer has to adjust the
     Y-coordinate hinself according to the font size in effect. The
     same problem occurs if text is to be written horizontally at
     the very right of the graphics window. Obviously, the TextHeight
     function used by the SetTextJustify procedure does not account
     for descender length. To fix the problem described, justification
     should be changed to account for the overall height of characters
     including descenders.




25. "Snow" prevention fails on CGA due to unsafe algorithm

     The internal DirectWrite routine of module CRT is designed to prevent
     "snow" when writing directly to the CGA screen. However, a logical
     error prevents that this snow-checking works 100% safe. The same
     critisism applies to the WriteView method in module VIEWS of Turbo
     Vision. The following is an excerpt from CRT.DirectWrite:

     .
     .
     @@2:    LODSB             ; 1; get char
             MOV     BL,AL     ; 2;
     @@3:    IN      AL,DX     ; 3; wait until out of current horiz. sync,if in
             TEST    AL,1      ; 4;
             JNE     @@3       ; 5;
             CLI               ; 6;
     @@4:    IN      AL,DX     ; 7; wait until next horiz. sync starts
             TEST    AL,1      ; 8;
             JE      @@4       ; 9;
             MOV     AX,BX     ;10;
             STOSW             ;11; write to screen
             STI               ;12;
             LOOP    @@2       ;13;
     .
     .


     If an interrupt occurs after line 3 and before line 6 in the
     above code fragment, the program will *not* wait for the *start* of
     the horizontal sync but only test if the CGA is *in* a horizontal
     sync upon returning from the interrupt service routine. Since
     horizontal sync allows only for the output of exactly one character
     if output starts at the very beginning of horizontal sync, there
     is a good chance that the above program writes to the screen after
     the horizontal sync has been completed, thereby causing the CGA to
     "snow". Of course, failure of the above code to prevent "snow" is
     only noticeable in a system with very high interrupt rates e.g.
     running serial communication as a background TSR. One additional
     disadvantage of the above code is that it makes only use of the
     horizontal sync period, although this is much shorter than the
     vertical retrace period.

     The following enhanced code is 100% safe to prevent snow and uses
     the vertical and horizontal retrace periods. It has been tested on
     an original IBM-CGA. Interrupt latency is only marginally higher than
     with the original code and still allows to run interrupt driven
     serial communication at the highest possible rate of 115000 baud.

     DirectWrite:

               CMP     SI, DI              ; start address = end address ?
               JE      EmptyStr            ; yes, nothing to write
               PUSH    CX                  ; save
               PUSH    DX                  ;  registers
               PUSH    DI                  ;   that
               PUSH    DS                  ;    must be
               PUSH    ES                  ;     preserved
               MOV     CX, DI              ; string end address
               SUB     CX, SI              ; number of characters to write
               MOV     DL, CheckSnow       ; get flag for snow check
               MOV     DH, TextAttr        ; get current attribute
               XOR     AX, AX              ; address BIOS data area
               MOV     DS, AX              ;  via segment 0
               MOV     AL, DS:CrtWidth+400h; width of scan line in current mode
               MUL     BH                  ; multiply by cursor y-position
               XOR     BH, BH              ; clear hi-byte to prepare for addition
               ADD     AX, BX              ; add cursor x-position
               ADD     AX, AX              ; two screen bytes for every character
               XCHG    AX, DI              ; offset into screen memory to DI
               MOV     AX, DS:Addr6845+400h; get 6845 base address
               ADD     AX, 6               ; 6845 status port
               XCHG    AX, DX              ; AX = CheckSnow/TextAttr, DX = port
               MOV     BX, 0B800H          ; screen segment for color modes
               CMP     DS:CrtMode+400h, 7  ; monochrome mode ?
               JNE     ColorMode           ; no, one of the color modes
               MOV     BH, 0B0H            ; screen at segment B000h if mono
     ColorMode:PUSH    ES                  ; address character string
               POP     DS                  ;  via DS
               MOV     ES, BX              ; extra segment addresses screen seg
               CLD                         ; autoincrement for string instruct.
               OR      AL, AL              ; CheckSnow = TRUE ? (AH=attribute)
               JE      OutLoop             ; no, don't check for snow
     WriteChr: LODSB                       ; get character to write, AH = attrib
               XCHG    AX, BX              ; save character/attribute to write
     WaitHor:  CLI                         ; interrupts disturb critical timing
               IN      AL, DX              ; read 6845 status
               TEST    AL, 8               ; in vertical retrace ?
               JNZ     WriteScr            ; yes, it is safe to write to screen
               TEST    AL, 1               ; in horizontal retrace ?
               JNZ     WaitHor             ; yes, wait until out of hor. retrace
     WaitHor2: IN      AL, DX              ; read 6845 status
               TEST    AL, 1               ; horizontal or vertical retrace ?
               JZ      WaitHor2            ; no, wait until either kind of retr.
     WriteScr: XCHG    AX, BX              ; in horiz. or vert. retrace: get ch
               STOSW                       ; write character and attribute
               STI                         ; interrupts ok now
               LOOP    WriteChr            ; write next character until all thru
               JMPS    WriteDone           ; screen write done
     OutLoop:  LODSB                       ; get character to write
               STOSW                       ; write character and attribute
               LOOP    OutLoop             ; until all characters printed
     WriteDone:POP     ES                  ; restore
               POP     DS                  ;  destroyed
               POP     DI                  ;   registers
               POP     DX
               POP     CX
     EmptyStr: RET




26. GetDir doesn't report use of invalid drive number

     The GetDir procedure should emit run time error 15 "Invalid
     drive number" when passed an invalid drive number. However, the
     procedure does not do the required check on the DOS return code

     and therefore never raises run time error 15. Instead, it always
     returns the String "X:\", where the X stands for any character
     in the IBM character set. The bug can easily be fixed by adding
     a few lines of code to the source module DIRH.ASM. The following
     program will demonstrate the bug:


     PROGRAM GetDirBug;

     VAR DriveNr:  INTEGER;
         PathName: STRING;

     BEGIN
        REPEAT
           Write  ('Enter Drivenumber (try also numbers > 100, 99 exits): ');
           ReadLn (DriveNr);
           GetDir (DriveNr, PathName);
           WriteLn('The path on drive ', DriveNr, ' is ', PathName);
        UNTIL DriveNr = 99;
     END. {GetDirBug}




27. Help bug

     Context sensitive help (Ctrl-F1) for the predefined arrays Port
     and PortW is missing. There was no help for these arrays in TP5.5
     as well.



28. Problems with the file selector box in IDE

     The history list of a file selector box contains only those
     files that were selected entering the file name in the input
     box, not those selected by double clicking the name in the
     file list, which is the standard way to select a file if the
     mouse is heavily used. Even when working mainly with the mouse
     a history list is still useful, since the desired files may
     be at the end of a file list 100 files long and one has to
     get to the right part of the file list before being able to
     double click the file name. By the way, this is also a problem
     on the Apple Macintosh, since its file select boxes do not
     have a history list feature at all. This can really be a pain
     in the neck. It is therefore strongly recommended that all
     files that have been selected with either method (that is, by
     entering the name in the input box or by double clicking the
     name in the file list) be put in the history list.



29. Possible problems in unit APP.PAS

     APP.PAS contains a assembler function ISqr, that computes the
     integral part of the square root of its integer argument. This
     function has several shortcomings. First of all, it should more
     appropriately named ISqrt. Then, for all arguments > 32760, it
     will enter an endless loop. Finally it is not very fast, since
     it makes use of the IMUL instruction. Unfortunately, it is not
     clear to me, if the shortcomings pointed out cause any threat
     to program integrity. If it is desirable to fix the function,
     the following substitute could be used. It uses a more elegant
     and faster algorithm and returns the correct result for all
     positive INTEGERs. The code length is identical to the original
     routine ISqr.

     { ISqrt (I) computes INT (SQRT (I)), that is, the integral part of the }
     { square root of integer I. It does not check for negative arguments.  }
     { For all arguments 0..MaxInt the correct result is returned. The      }
     { algorithm exploits the following property:                           }
     {          n                                                           }
     {  n**2 =  Sigma (2i-1)                                                }
     {          i=1                                                         }

     FUNCTION ISqrt (I: INTEGER): INTEGER; ASSEMBLER;

     ASM
           MOV   CX, I   { load argument }
           MOV   AX, -1  { init result }
           CWD           { init odd numbers to -1 }
           XOR   BX, BX  { init perfect squares to 0 }
     @loop:INC   AX      { increment result }
           INC   DX      { compute }
           INC   DX      {  next odd number }
           ADD   BX, DX  { next perfect square }
           CMP   BX, CX  { perfect square > argument ? }
           JBE   @loop   { until square greater than argument }
     END;




30. Poor performance of REAL type arithmetic

     Although this does not constitute a real bug, an analysis of the
     poor performance of the REAL type arithmetic will be given. The
     rationale here is that a 'TURBO product' should also deliver
     turbo performance wherever it can be achieved. One obvious example
     that there is ample room for speed improvements is the REAL-Sqrt
     function. It will take more time to compute the square root to 12
     decimal places than the coprocessor emulator needs to compute the
     function result to 19 decimal places. I feel that such a performance
     is unacceptable. Unfortunately, there were no improvements in TP6.0
     over TP 5.5.

     Improvements are also possible in the LONGINT arithmetic, especially
     the division, which will enjoy accelerations of factor four to six
     (depending on the CPU) when coded using the DIV instruction.

     Performance can be enhanced by careful register scheduling within
     all routines, thus avoiding unnecessary memory accesses. This
     measure will also reduce the overall instruction count for a routine.
     Wherever possible, time saving CPU instructions such a MUL or DIV

     should be used. This will vastly improve performance especially on
     the 286, 386, and 486 CPUs. Most important is the choice of the
     appropriate algorithm for each function. Tests show that the REAL
     division uses the slowest out of four possible algorithms. This
     clearly indicates that not much time was invested in finding short
     but fast algorithms. On the other hand, the square rooting routine
     uses a basically fast algorithm (Newton's iteration), but
     obliterates it advantages by poor implementation. The trancendental
     functions are based on polynomial approximations. It seems that no
     care was taken to find the shortest and most accurate polynomials
     possible. The speed advantages possible by a careful recoding of
     the complete REAL arithmetic range from a few percent for simple
     functions like LONGINT to REAL conversion to up to a factor of 20
     for the Sqrt function.



31. Inefficient string handling

     The string handling operations Insert, Delete, and Pos have
     always been implemented in a very simple but quite ineffient
     manner in Turbo-Pascal. There were no improvements in Turbo-
     Pascal 6.0. Since an acceleration of 300% - 400% can be
     achieved, this is hard to accept.


***  Note: The above mentioned improvements have been realized in a
           replacement for the original SYSTEM.TPU. The source has been
           made available to BORLAND, but will not be given here. The
           library replacement (not the source though) is available
           as TPL60NEW.ZIP via anonymous FTP from garbo@uwasa.fi




++++++++++++++++++++ Suggestions for enhancements ++++++++++++++++++++++++++


1. Suggested improvements for coprocessor / emulator arithmetic

     The routine that patches the emulator interrupts (INT 34 to INT 3D)
     back to coprocessor instructions at runtime if a coprocessor is
     present always insert WAITs (9Bh) before the coprocessor instruction.
     However, for all coprocessors except the 8087 these WAITs are
     unnecessary, since the 287 and 387 synchronize with the CPU at
     hardware level, using ports F0h thru FFh. These WAITs can therefore
     be replaced by NOPs, resulting in somewhat faster code. Performance
     improvements of up to 6% were observed with programs that make heavy
     use of simple coprocessor instructions (linear equation solver) by
     this simple change. A new routine, which does insert NOPs instead
     of WAITs where approriate is presented here.


     CODE    SEGMENT BYTE PUBLIC 'CODE'

             ASSUME  CS:CODE

     JMPS    EQU     <JMP SHORT>

     ;------------------------------------------------------------
     ; PATCH87 is the routine responsible for converting emulator
     ; interrupts back to coprocessor opcodes if a coprocessor is
     ; detected by the startup code.
     ;
     ; This routine is 1 byte shorter than the original one and has
     ; been enhanced to generate NOPs instead of WAITs before each
     ; coprocessor instruction when the coprocessor is a 287 or 387.
     ;
     ; INPUT:     No input or output. The desired sideeffect is
     ; OUTPUT:    patching the code at run-time.
     ;
     ; DESTROYS:  -
     ;
     ; All rights reserved (c) 1988-1992 Norbert Juffa
     ;
     ; Borland is free to use this code if desired !
     ;-------------------------------------------------------------

             JMPS  EQU  <JMP SHORT>

     PATCH87 PROC  FAR
             PUSH  BP                ; save TURBO-Pascal framepointer
             MOV   BP, SP            ; make new framepointer
             PUSH  AX                ; save
             PUSH  SI                ;  destroyed
             PUSH  DS                ;   registers
             TEST  BYTE PTR [BP+7], 2; interrupts allowed before int ?
             JZ    $intdis           ; no
             STI                     ; yes, enable interrupts
     $intdis:LDS   SI, [BP+2]        ; load return address
             DEC   SI                ; point to int data
             MOV   AX, WORD PTR [SI] ; get interrupt number & data
             DEC   SI                ; point to patch
             SUB   AL, 34h           ; 34..3D --> 0..9
             CMP   AL, 9             ; interupt valid (between 0..9) ?
             JA    $invald           ; invalid interrupt
             JE    $fwait            ; interrupt $3D --> FWAIT
             CMP   AL, 8             ; interrupt $3C ?
             JE    $spcial           ; yes, handle segment overrides
             ADD   AL, 0D8h          ; new opcode
     $tst286:MOV   AH, AL            ; second byte of opcode
             MOV   AL, 90h           ; first byte is a nop
             PUSH  SP                ; test if
             POP   BP                ;  286 or
             CMP   SP, BP            ;   higher
             JE    $patch            ; 286
             MOV   AL, 9Bh           ; convert nop to wait
     $patch: MOV   WORD PTR [SI], AX ; store new opcode
             MOV   BP, SP            ; address stack via BP
             MOV   WORD PTR [BP+8],SI; set new return address
     $endptc:POP   DS                ; restore
             POP   SI                ;  destroyed
             POP   AX                ;   registers
             POP   BP                ; restore TURBO-Pascal frameptr
             IRET                    ; done
     $fwait: MOV   AX, 9B90h         ; store FWAIT
             JMPS  $patch            ; patch it in
     $spcial:TEST  AH, 20h           ; bit 5 set indicates spec. func.
             JNZ   $invald           ; not supported, invalid
             MOV   AL, AH            ; generate
             AND   AX, 07C0h         ;  segment
             SHR   AL, 1             ;   override
             SHR   AL, 1             ;    byte
             SHR   AL, 1             ;     and
             XOR   AL, 18h           ;      coprocessor
             ADD   AX, 0D826h        ;       opcode
             MOV   BYTE PTR [SI+2],AH; set new opcode
             JMPS  $tst286           ; put in new opcode
     $invald:JMPS  $endptc           ; no error handling, ignore
     PATCH87 ENDP

     CODE    ENDS

     END


     Another optimization could be performed if a program is
     compiled in the $N+,E- mode. Since no emulator is used
     anyhow, the compiler could give up generating emulator
     interrupts and generate real coprocessors instructions
     instead. On CPUs > 286 neither NOPs nor WAITs had to be
     inserted before NDP instructions. This would save space
     as well as time.

     Those functions that use the Borland shortcut interrupt 3Eh
     could test which NDP is present whenever this interrupt is
     called. If Test8087 = 3, the enhanced instructions (e.g. FSIN,
     FCOS) available on the 387/486/287XL could be executed. There
     would be only minimum timing overhead, but vast performance
     improvements on 386/486 machines. Since no elaborate argument
     reduction schemes are necessary, the additional code would be
     quite short.

     The Borland shortcut interrupt provides some functions not
     accessible from Turbo-Pascal 6.0. These functions are the tangent
     Tan (subcode F0h), the dyadic logarithm Ld (subcode F6h), the
     common logarithm Log (subcode F8h), power of two (subcode FCh),
     and power of ten (subcode FEh). Tests show that these undocumented
     functions are provided with a coprocessor as well as with the
     emulator and are fully operational. These functions should be
     made available to programmers through the SYSTEM unit and be
     documented. Especially the Tan is quite useful since it only
     takes 40% of the time of the equivalent construct Sin/Cos.



2. Inclusion of LOADALL in inline assemblervalid instructions

     Since the undocumented AAM xx and AAD xx instructions are provided
     by the inline assembler, the undocumented LOADALL instruction
     (opcode 0F05h) could be provided as well when the compiler is in
     $G+ mode. The Turbo-Debugger will correctly disassemble LOADALL.



3. Suggestions regarding 286 code generation feature ($G+)

     Programs compiled with the $G+ switch will have reduced memory
     requirements and will execute somewhat faster on a 286/386/486
     CPU. Typically, memory and time savings will not execeed 2%.
     Additionally, setting the $G switch on will allow the use of
     real and protected mode 286 instructions. As explained in section
     five of the README file, programs compiled with $G+ will not
     check for the presence of a approriate processor at runtime. It
     is strongly recommended that this behavior be changed. At least
     two cases are known (one involving Borlands biggest competitor)
     where programs were shipped that had been compiled with an 286
     switch setting. Customers using them on PC type machines were
     puzzled when they discovered that programs crashed on their systems
     although they had performed flawlessly on their office computer.
     Finally someone found the bug by tracing the program with a debugger.
     To avoid such unpleasant confusion, programs compiled with $G+
     should execute a short routine at startup to determine if an 286
     or later processor is present. If this is not the case, it should
     emit an error message and abort the program, just as programs
     compiled with $N+,$E- abort if they fail to detect a coprocessor.

     Since 286 real mode instructions can also be executed on NEC's
     V20/V30 processors and on the 80186/188, it might be desirable
     to have an 186 code generation feature. This would effectively
     split the $G switch into two separate switches. No changes would
     have to be made to the code generator, since it generates no 286
     protected mode instructions. Thus, generated code would be the
     same with either the 186 and 286 switches on. However, the inline
     assembler would only recognize protected mode instructions when
     the 286 switch is on. This would allow maximum utilization of the
     286 real mode instructions and a run time check for the CPU at the
     same time. Below is some code that can be used to distinguish between
     8086/8088, 80188/186/V20/V30, and 80286/386/486.


     ;--------------------------------------------------------------------
     ; CPU_Test distinguishes between three groups of CPUs commonly used
     ; in computers and returns an associated code for each.
     ;
     ; OUTPUT:  AX  = 0   Group #0 may execute 8086 code only (8086/8088)
     ;          AX  = 1   Group #1 may additionally execute 286 real mode
     ;                    instructions (V20/V30, 80186/80188)
     ;          AX  = 2   Group #2 may additionally execute 286 protected
     :                    mode instructions
     ;--------------------------------------------------------------------

     CPU_Test PROC    FAR
              PUSH    SP                   ; test updating
              POP     AX                   ;  of stackpointer
              CMP     AX, SP               ; stackpointer updated before push ?
              JE      @Grp2                ; no, must be 286, 386 or 486
              CLC                          ; make sure carry clear
              PUSHA                        ; PUSHA executed on 88/86 as JMP $+2
              STC                          ; carry set if V20/V30 or 186/188
     @8086:   JC      @Grp1                ; yes, its group #1
              XOR     AX, AX               ; CPU is 8088/8086
              RET                          ; done
     @Grp1:   POPA                         ; remove pushed bytes
              MOV     AX, 1                ; CPU is V20/V30 or 80186/80188
              RET                          ; done
     @Grp2:   MOV     AX, 2                ; CPU is 286/386/486
              RET                          ; done
     CPU_Test ENDP



4. Suggestions for enhancements in the code generator

 4.1 Enhancing procedure entry/exit code in $G+ mode (286 code generation)


     When a procedure/function does not use local variables, the
     standard exit code in $G- mode is:

     POP   BP
     RET

     This is replaced by the following code in $G+ mode:

     LEAVE
     RET

     However, for procedures/function that have no local variables,
     it would be advantageous to always use the first sequence in
     either mode, $G- and $G+. Although both sequences take the same
     number of clock cylces on 286 and 386 processors, the first is
     considerably faster on the 486. Since the code generator already
     checks if no local variables are declared to generate optimized
     entry code in $G+ mode, the optimized exit code could be
     generated just as easily.

     Although the use of the ENTER imm16, 0 instruction does produce
     shorter code when a procedure/function has both, parameters and
     local variables, the equivalent but longer (two or three byte more)
     standard procedure entry code will execute faster than ENTER on
     all Intel processors. Therefore, it should be considered if it is
     really desirable to use ENTER at all. A lot of programs really
     do run slower on a 386DX machine if compiled with $G+ instead of
     $G-, as tests indicate.

     processor  |  ENTER imm16, 0    | standard entry sequence
     -----------+--------------------+------------------------
     80286      |  11 clocks         | 3 + 2 + 3 = 8 clocks
     80386      |  10 clocks         | 5 + 2 + 2 = 9 clocks
     80486      |  14 clocks         | 1 + 2 + 1 = 4 clocks



 4.2 Optimizing entry code for non nested procedures without parameters
     and local variables

     If a procedure/function takes neither any parameters nor declares
     any local variables and is not statically nested within another
     procedure/function, there is no need for any entry code. Turbo
     Pascal performs this optimization only for assembler procedures,
     but skips it for normal procedures, probably so that nested and
     non-nested procedures can use the same branch of the code
     generator. The code generator could be enhanced to generate
     procedure entry code only for those procedures that are either
     statically nested (and thus have a hidden parameter, namely the
     framepointer of the preceding procedure in the static chain),
     take parameters, or declare local variables.



5. Suggestions for IDE

     The status line for the edit mode should be enhanced to include the
     shortcuts F5 Zoom and F6 Next. These additional hints will exactly
     fit into the remaining space. When IDE is in the stepping/debugging
     mode, shortcuts F4 Goto Cursor and Ctrl-F9 Run should be added to
     the status line. This would accelerate debugging sessions, since
     all program flow control could be excerted using simple mouse clicks
     on the status line.



6. Suggestion regarding TURBO command-line options

     There should be a help switch like /? or /Help on the Turbo-Pascal
     Prorammer's Platform command line that displays a help screen
     which describes the other command-line switches that are available
     and explains what they will do.


Xref: sparky comp.lang.pascal:2836 comp.lang.c:7421 comp.os.msdos.programmer:5283