home *** CD-ROM | disk | FTP | other *** search
/ Power-Programmierung / CD2.mdf / c / tools / tdebug / tcdebug.doc next >
Text File  |  1987-08-09  |  22KB  |  793 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.                                                               August 9, 1987
  9.  
  10.                              TCdebug Version 0.00
  11.  
  12.                     (C) Copyright 1987 by L. David Baldwin.  
  13.                              All Rights Reserved.
  14.  
  15.   Further copyright information given below
  16.  
  17.  
  18.   OVERVIEW
  19.  
  20.   TCdebug is an experimental source code debugger for use in debugging Turbo 
  21.   C (tm) Programs on the IBM-PC (tm).  Its goal is to allow source code 
  22.   debugging in all of Turbo C's memory models and with most of the possible 
  23.   compile and link options.  TCdebug allows you to:
  24.  
  25.        1.  View your source code (and, optionally, the assembly language 
  26.            code) while debugging.
  27.        2.  Trace the operation of your program by source code lines or by 
  28.            assembly language instructions.
  29.        3.  Insert breakpoints in your program by function name, by line 
  30.            number, or hexadecimal address.
  31.        4.  Examine (and change) simple global variables by symbolic name.  
  32.            Local variables may also be examined and changed, but require that 
  33.            the proper displacement on the stack be known. 
  34.        5.  Set up a Watch window to keep continuous tabs on a variable.
  35.  
  36.   TCdebug is not a finished program.  It is being released at this time to 
  37.   get an indication of interest and to obtain assistance in finding bugs and 
  38.   problems which are probably numerous at this time.
  39.  
  40.   TCdebug is designed exclusively for debugging Turbo C programs.  It should 
  41.   not be used on programs generated by other compilers.
  42.  
  43.  
  44.   SYSTEM REQUIREMENTS
  45.  
  46.        1.  An IBM-PC, AT, or compatible.  Screen compatibility is a must.
  47.        2.  PC-DOS 2.0 or above.
  48.        3.  Approximately 128k more memory than would normally be required to 
  49.            run the program to be tested.
  50.  
  51.  
  52.   PREPARATION
  53.  
  54.   TCdebug requires that a Map file for your program be present to supply 
  55.   information on the program symbols and line number locations.  When 
  56.   compiling and linking with TC, the options can be set with O/C/C/L and 
  57.   O/L/M/P.  With TCC use -M and -y.
  58.  
  59.  
  60.  
  61.  
  62.                                       1
  63.  
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70.  
  71.  
  72.  
  73.  
  74.   When starting a debugging session, the following files should be on the 
  75.   default drive:
  76.  
  77.     PROG.EXE    (or, optionally, .COM for the Tiny Model)
  78.     PROG.MAP    the map file
  79.     various.C   all the source files for the program (or at least all that 
  80.                 will be accessed.)
  81.  
  82.  
  83.  
  84.   OPERATION
  85.  
  86.   TCdebug may be started by entering the filename of the program to be 
  87.   debugged and any parameters that the program requires on the command line 
  88.   as:
  89.  
  90.     TCdebug PROG <other stuff>
  91.  
  92.   Here, PROG is the name of the program to be tested with EXE being the 
  93.   default extension.  <other stuff> will be passed on to PROG as its command 
  94.   line when execution begins.  If TCdebug is called without parameters, a 
  95.   request will be made for them.
  96.  
  97.   When execution begins, TCdebug loads the Map file, the EXE file and reports 
  98.   some facts about the program.  Note should be made of whether pointers are 
  99.   regarded as Near or Far by default as this will be important when 
  100.   displaying pointers later.
  101.  
  102.   After "hitting any key", the program is executed to "main()" and the 
  103.   debugging screen appears.  The debugging screen is divided into two parts.  
  104.   The lower section is the command and data section.  The '*' is a prompt for 
  105.   one of the commands described later.  The top part of the screen displays 
  106.   the program source code text which at this point will be centered at the 
  107.   first statement in main().  Source code line number appear on the left and 
  108.   the current line (the one to be executed next) is highlighted.
  109.  
  110.   Dividing the two portions of the debugging screen is a line which shows the 
  111.   name of the source file presently displayed.
  112.  
  113.   Two keys which can be tried at this point are the F9 and F10 keys.  The 
  114.   F9 key toggles into and out of the assembly mode.  When in assembly mode, 
  115.   the assembly language instructions of the program are displayed with the 
  116.   source code lines interspersed.  The F10 key toggles between the debugger 
  117.   screen and the screen which receives program output.
  118.  
  119.  
  120.   SPECIAL KEYS FOR VIEWING TEXT
  121.  
  122.   The following keys may be used to change the text being displayed:
  123.  
  124.        Pg Up
  125.        Pg Dn       Move the display up or down one page.
  126.  
  127.  
  128.                                       2
  129.  
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136.  
  137.  
  138.  
  139.  
  140.  
  141.        ^Pg Up
  142.        ^Pg Dn      Move to the start or end of the current file.
  143.  
  144.        Up arrow
  145.        Down arrow  Scroll up or down one line.
  146.  
  147.        ^Left Arrow  (with Scroll Lock on)
  148.        ^Right Arrow (with Scroll Lock on)
  149.                    Scroll horizontally left and right.
  150.  
  151.        F9 key      Toggle in and out of assembly mode.
  152.  
  153.        F10 key     Toggle between the debug screen and the screen
  154.                    of the program under test.
  155.  
  156.   In addition, the text being displayed may be changed using the View command 
  157.   described later.
  158.  
  159.  
  160.   COMMAND EDITOR
  161.  
  162.   Commands are entered at the '*' prompt.  When entering commands, the 
  163.   following keys may used to edit the command:  (They perform the same 
  164.   functions as they do in the Turbo C editor.)
  165.  
  166.        ^A,^S,^D,^F,^G,^T,^H,^V,^Y,LFARW,RTARW,^LFARW,^RTARW,
  167.        Ins, Del, Backspace
  168.  
  169.   The Insert mode (default) is indicated by a slightly fatter cursor.  The 
  170.   cursor is normal in the Overwrite mode.
  171.  
  172.   In addition, a stack of the last 6 commands (those having more than 3 
  173.   characters) is maintained.  The F3 key accesses the stored commands from 
  174.   the most recent to the oldest and the F5 key accesses them in the reverse 
  175.   order.  These old commands may be used as is or may be modified by editing 
  176.   them.
  177.  
  178.   Note that commands are not acted upon until the Enter key is hit.  (The 
  179.   cursor does not have to be at the line end to enter the command.)
  180.  
  181.  
  182.   COMMAND PARAMETERS
  183.  
  184.   TCdebug uses one or two letter commands.  The command is often followed by 
  185.   one or more parameters.  Parameters are delimited from the command and each 
  186.   other using spaces.  The one exception to this is the format parameter 
  187.   which is preceded by a comma.  The parameters which may be used are:
  188.  
  189.  
  190.  
  191.  
  192.  
  193.  
  194.                                       3
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.  
  203.  
  204.  
  205.  
  206.     <Symbol>
  207.        A C source code symbol representing a function name or variable as 
  208.        appropriate. The leading underbar added by the compiler has been 
  209.        stripped off, so symbols are entered exactly as used in the source 
  210.        program.  Case is significant.
  211.  
  212.     <Line Number>
  213.        Line numbers are entered as <filename>\<number> as:
  214.            myprog.c\345
  215.  
  216.        In most cases, the <filename> part can be dropped.  An entry of the 
  217.        form
  218.  
  219.            \345
  220.  
  221.        implies line number 345 in the currently displayed source file.  
  222.        (Currently, the '\' also may be dropped and a simple decimal entry will 
  223.        do.  However, the '\' may be required in future versions.)
  224.  
  225.     <Hexaddress>
  226.        Normal numerical entry in TCdebug is decimal with hex entries allowed 
  227.        by preceding them with '0x'.  However, numerical address entries must 
  228.        be entered in hex to distinguish them from line numbers.  A 
  229.        <hexaddress> takes the following form:
  230.  
  231.            0x1234:0x1ABC
  232.            es:bx+2
  233.            SS:BP-0X5a
  234.  
  235.        As indicated above, register names are allowed in address 
  236.        specifications.  The _current_ value in the register is used--the 
  237.        address does not change if the register value later changes.  The 
  238.        segment part of the <hexaddress> may be dropped as in:
  239.  
  240.            bp-0xA
  241.            0x123
  242.            bx
  243.  
  244.        If no segment is present in the entry, there is an implied segment.  
  245.        The rules for determining the implied segment are:
  246.  
  247.        1.  If the BP register is used, SS is implied.
  248.        2.  If BX,SI,DI are used (but not BP), DS is implied.
  249.        3.  If none of the above and a data entry is expected, DS is implied.
  250.        4.  If a code address is expected, the current CS is implied.
  251.  
  252.     <Format>
  253.        Format parameters are entered as one or two letters preceded by a 
  254.        comma.  Case is significant.  The purpose of the <format> parameter is 
  255.        to inform TCdebug of the size and type of a variable as this 
  256.        information is not available in the Map file.  <format> parameters 
  257.        correspond to those used in the C 'printf' and 'scanf' functions.  
  258.  
  259.  
  260.                                       4
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.        Currently supported are:
  273.  
  274.            c,s,i,d,u,x,X,o,p,g,G,li,ld,lx,lX,lo,Np,Fp,lg,lG
  275.  
  276.        For the p (pointer) format, the default pointer size for the selected 
  277.        memory model is used.  This size is indicated in the information 
  278.        presented at startup.  To override the default, use either N or F as 
  279.        appropriate.
  280.  
  281.        The c (character) format has been used as a catchall for byte size 
  282.        items.  Display is in quoted character form, decimal, and hex.  Change 
  283.        entries may be made using any of those forms.
  284.  
  285.  
  286.   COMMANDS
  287.  
  288.   G    (Go)
  289.  
  290.     Format:
  291.        G [<parameter> [<parameter..]]
  292.  
  293.     The Go command starts execution of the program under test.  Execution 
  294.     will continue until a breakpoint is reached or the program terminates.
  295.  
  296.     One or more breakpoints may be entered with the Go command.  These 
  297.     breakpoints are called temporary breakpoints as they are in effect only 
  298.     until the first stopping point is reached.  Any temporary breakpoint 
  299.     would then have to reentered with the next Go command if desired.
  300.  
  301.     Examples:
  302.  
  303.        G   Start execution with no temporary breakpoints. (There might be 
  304.            some permanent breakpoints, however.)
  305.  
  306.        G \345 funct1 0x113
  307.            Start execution with temporary breakpoints at line number 345, at 
  308.            the start of function, funct1, and at address CS:0x113. In 
  309.            addition, there might be other permanent breakpoints in effect.
  310.  
  311.   T    (Trace)
  312.  
  313.     Format:
  314.        T   (or F7 key)
  315.  
  316.     In source code mode, execute the code on the current line.  Execution 
  317.     will stop at the next encountered line number.  If the current line 
  318.     contains a function call, the break will be at the start of the 
  319.     function.
  320.  
  321.     In assembly mode (assembly code is displayed), execute the next assembly 
  322.     language instruction.
  323.  
  324.  
  325.  
  326.                                       5
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338.  
  339.   N    (Next)
  340.  
  341.     Format:
  342.        N    (or F8 key)
  343.  
  344.     In source code mode, execute the code on the current line in its 
  345.     entirety.  In assembly mode, this command currently does nothing.
  346.  
  347.     The difference between the Trace and the Next command is that if the 
  348.     current line contains a function call, Next will completely execute the 
  349.     function whereas Trace will Trace through the function.
  350.  
  351.  
  352.   P    (Permanent breakpoint)
  353.  
  354.     Format:
  355.        [-]P [<parameter>]
  356.  
  357.     The P command is used to specify permanent breakpoints.  Unlike temporary 
  358.     breakpoints, permanent breakpoints remain in effect until removed (using 
  359.     a '-' preceding the P command).  
  360.  
  361.     If no parameter is entered, the breakpoints in effect are listed.
  362.  
  363.     Passcounts are not implemented at this time.
  364.  
  365.     Examples:
  366.  
  367.        P              List all permanent breakpoints.
  368.       -P              Delete all permanent breakpoints.
  369.        P moda.c\345   Install a breakpoint at line 345 in file moda.c.
  370.       -P funct1       Remove a breakpoint at function funct1.
  371.        P 0x34b        Install a breakpoint at CS:034B.
  372.  
  373.  
  374.   V    (View text)
  375.  
  376.     Format:
  377.        V [<parameter>]
  378.  
  379.     The View command may be used to change the text being observed 
  380.     in the text window.  If no parameter is entered, the text will 
  381.     be centered around the current line.
  382.  
  383.     Examples:
  384.  
  385.        V initscreens   View text at function initscreens.
  386.        V \545          View text around line 545.
  387.  
  388.  
  389.  
  390.  
  391.  
  392.                                       6
  393.  
  394.  
  395.  
  396.  
  397.  
  398.  
  399.  
  400.  
  401.  
  402.  
  403.  
  404.   VF   (View File)
  405.  
  406.     Format:
  407.        VF <filename>
  408.  
  409.     The View command is for viewing the program source files.  The VF 
  410.     command allows any ASCII file to be displayed.
  411.  
  412.  
  413.   E    (Examine/change variable) 
  414.  
  415.     Format:
  416.        E <symbol>|<hexaddress> , <format>
  417.  
  418.     The Examine/change command allows the the value of a simple variable to 
  419.     be displayed and optionally changed.  Global variables may be referred to 
  420.     symbolically.  Auto and static variables must be referred to by a 
  421.     <hexaddress>.  Pointers may be resolved using one or more '*'s preceding 
  422.     the symbol or address.  <format> indicates the type of display wanted.
  423.  
  424.     After a variable value is displayed in response to the Examine/change 
  425.     command, a new value may be optionally entered followed by the Enter key.  
  426.     The Enter key by itself is used if no new value is desired.
  427.  
  428.     String variables are displayed as a string within quotes.  When 
  429.     specifying a change to a string variable, the new string should be 
  430.     enclosed in double quotes.  A null string is specified by two quotes 
  431.     enclosing nothing.
  432.  
  433.  
  434.     Examples:
  435.  
  436.        E flt,g
  437.        E dble,lg
  438.        E *st,c
  439.        E es:bx,u
  440.        E bp-0x52, s
  441.  
  442.  
  443.   W    Watch variable
  444.  
  445.     Format
  446.        W <symbol>|<hexaddress> , <format>
  447.     [-]W [<number>]
  448.  
  449.     The Watch command opens up a watch window so that the specified variable 
  450.     is displayed continuously.  The value displayed is updated whenever 
  451.     TCdebug regains control.  The syntax for watch variable entry is 
  452.     identical to that used with the Examine command.  
  453.  
  454.  
  455.  
  456.  
  457.  
  458.                                       7
  459.  
  460.  
  461.  
  462.  
  463.  
  464.  
  465.  
  466.  
  467.  
  468.  
  469.  
  470.     When watch variables are displayed, they are given a number.  The number 
  471.     is useful for selectively deleted them using the -W command.
  472.  
  473.     Examples:
  474.        W var1, u    Watch the unsigned variable, var1
  475.        W *bp-4,c    Watch the char variable pointed to by SS:BP-4
  476.       -W 1          Delete watch variable #1
  477.       -W            Delete all watch variables  
  478.  
  479.  
  480.   R    (Register Display)
  481.  
  482.     Format:
  483.        R
  484.  
  485.     The Register display command displays the current machine register 
  486.     contents.  At this time, there is no way to change the registers.
  487.  
  488.  
  489.   RE   (Restart program under test)
  490.  
  491.     Format:
  492.        RE
  493.  
  494.     Reloads a fresh version of the test program and restarts it from the 
  495.     beginning.  Breakpoints and watch variables remain in effect.
  496.  
  497.  
  498.   WD   (Window Divide)
  499.  
  500.     Format:
  501.        WD [n]
  502.  
  503.     The Window Divide command allows the line dividing the screen to be moved 
  504.     up or down.  n is the desired line position.  If n is not entered, the 
  505.     line position is not changed but the screen is refreshed.
  506.  
  507.  
  508.   Q    (Quit)
  509.  
  510.     Format:
  511.        Q
  512.  
  513.     The Quit command ends debugging without running the program under test to 
  514.     completion.  However, the program's exit() routine is executed, so that 
  515.     files are closed, etc.  You will be asked if you wish to restart the 
  516.     program.  (oops, that's not working!).
  517.  
  518.  
  519.  
  520.  
  521.  
  522.  
  523.  
  524.                                       8
  525.  
  526.  
  527.  
  528.  
  529.  
  530.  
  531.  
  532.  
  533.  
  534.  
  535.  
  536.   DG   (DebuG)
  537.  
  538.     Format:
  539.        DG
  540.  
  541.     This command is used to enter an optional external assembly language 
  542.     debugger.  It is used mainly for debugging TCdebug.
  543.  
  544.  
  545.   HINTS
  546.  
  547.   It is possible to insert breakpoints in the source code using 
  548.   geninterrupt(3).  These breakpoints cannot be removed by TCdebug but may be 
  549.   useful for conditional breaks.  For instance:
  550.  
  551.     if (i==49) geninterrupt(3);
  552.  
  553.   If you mistakenly Trace into a function you wanted to skip using Next, use 
  554.   G \n, where n is the last line number in the function, then one Trace will 
  555.   get you back to the original line of code.  Hopefully, there will be a 
  556.   'Return' command in the future which will make this easier.
  557.  
  558.   If, in the assembly mode, you trace into a library routine and can't find 
  559.   your way out, toggle out of assembly mode (F9).  Even if the source code 
  560.   screen is blank at this time, a single Trace will get you to the next line 
  561.   number.
  562.  
  563.   Avoid assembly tracing of the 8087 emulation code.
  564.  
  565.   Auto (stack) variables can be Examined or Watched by using the disassembly 
  566.   listing to determine their position on the stack relative to the BP 
  567.   register.  When doing this, be sure that the BP register is valid.  In 
  568.   particular, the BP register is not valid immediately on entry to the 
  569.   function.  One source line trace must be made (or several assembly 
  570.   instructions passed) before the BP register is correct.
  571.  
  572.   The Huge memory model has the same sort of problem with the DS register 
  573.   which changes between modules.  In this case, it only effects the 
  574.   disassembly listing.  The data symbols will not be correctly listed until 
  575.   the DS register has been setup.
  576.  
  577.  
  578.   RESTRICTIONS, PROBLEMS, BUGS
  579.  
  580.   The following are current limits (somewhat arbitrarily set).  
  581.  
  582.     Permanent and temporary breakpoints are limited to 5 each.
  583.     Maximum file size for displayed files = 32k.
  584.     Maximum number of line numbers (only those with code count) = 3000.
  585.     Maximum number of program modules accommodated = 20.
  586.     Maximum number of symbols = 700.
  587.  
  588.  
  589.  
  590.                                       9
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.   A simple screen swap is currently used.  This limits debugging to text only 
  603.   programs.  Snow may be horrendous at this time.
  604.  
  605.   The map file for the Tiny memory model has some peculiarities in data 
  606.   addresses which I haven't got figured out yet.  This affects a number of 
  607.   library data symbols but only seems to affect one or two source symbols.  
  608.   The problem shows up in the assembly listing where the affected symbols are 
  609.   not correctly displayed.
  610.  
  611.   The 8087 emulation code turns into a mess when disassembly is attempted.
  612.  
  613.   Currently, non default pointers cannot be resolved by the 'E' or 'W' 
  614.   commands.  That is:
  615.  
  616.     E *st,c
  617.  
  618.   will always resolve st as a far pointer if the default is far.  Probably 
  619.   some sort of cast will have to allowed, as:
  620.  
  621.     E *(near*)st,c
  622.  
  623.  
  624.   COPYRIGHT
  625.  
  626.   Documentation and Program (C) Copyright 1987 by L. David Baldwin.  
  627.   All Rights Reserved.
  628.  
  629.   TCdebug may be copied and distributed freely by individuals to friends and 
  630.   acquaintances providing that no fee is charged and it is not part of a 
  631.   package for which a charge is made.
  632.  
  633.   The uploading of TCdebug to any bulletin board except that of the Borland 
  634.   Sig (CompuServe) is expressly forbidden.
  635.  
  636.  
  637.   TRADEMARKS
  638.  
  639.        IBM-PC is a trademark of International Business Machines 
  640.        Corporation.
  641.        Turbo C is a trademark of Borland International Inc.
  642.  
  643.  
  644.  
  645.   Please report all bugs, suggestions, and problems to Dave 
  646.   Baldwin, CompuServe ID #76327,53.
  647.  
  648.  
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656.                                      10
  657.  
  658.  
  659.  
  660.  
  661.  
  662.  
  663.  
  664.  
  665.  
  666.  
  667.  
  668.   APPENDIX A -- COMPILER OPTIONS
  669.  
  670.   As mentioned earlier, it is mandatory that the map file generation and line 
  671.   number options be turned on.  The effect of some of the other compiler 
  672.   options on debugging are discussed below.  Some of this is just guess work 
  673.   at this stage as not all have actually been tested.
  674.  
  675.   Standard Stack Frame
  676.     Unimportant at this time but may be mandatory in the future when other 
  677.     features are added.
  678.  
  679.   Register Optimization
  680.     Borland suggests off.  I haven't tried this one but I suspect that it 
  681.     confuses things somewhat.  Those adept at assembly language may not have 
  682.     too much trouble.
  683.  
  684.   Jump Optimization
  685.     Same as register optimization.
  686.  
  687.   80186/80286 Code Generation
  688.     Off is best here.  The disassembler in TCdebug currently does not 
  689.     understand the new instructions.
  690.  
  691.   Use Register Variables
  692.     Off might be somewhat better although I've never turned it off.  When on, 
  693.     you may have to figure out which variables the compiler decided to store 
  694.     in registers.  Also, in the current version of TCdebug, there is no way 
  695.     to change register values.
  696.  
  697.   8087 vs Emulation
  698.     If you have a choice, by all means select straight 8087.  The emulated 
  699.     code does not disassemble in any meaningful way.
  700.  
  701.  
  702.  
  703.  
  704.  
  705.  
  706.  
  707.  
  708.  
  709.  
  710.  
  711.  
  712.  
  713.  
  714.  
  715.  
  716.  
  717.  
  718.  
  719.  
  720.  
  721.  
  722.                                      11
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730.  
  731.  
  732.  
  733.  
  734.   APPENDIX B -- SOURCE CODE FORMATTING
  735.  
  736.   With modern compilers, line numbers often do not correspond to the code 
  737.   generated in the manner that you might expect.  Layout of the source code 
  738.   can help in this respect.  While you probably don't want to reformat all 
  739.   your present code, you may want to change your formatting for code yet to 
  740.   be written.
  741.  
  742.   The most obvious format change is to only have one source statement per 
  743.   line.  With more than one statement on a line, line numbers can't be used 
  744.   to set a breakpoint on the second statement and the Trace statement will 
  745.   trace multiple statements.
  746.  
  747.   Statements split between two lines do not cause much trouble.
  748.  
  749.   The 'else' in an 'if' statement causes a difficulty.  Consider the 
  750.   following code:
  751.  
  752.   100  if (...)
  753.   101     {..do something..}
  754.   102  else {..do something else..}
  755.   103
  756.  
  757.   To put a breakpoint on the ..do something else.. one might try a break on 
  758.   line 102.  But the else here actually generates a jump instruction (to line 
  759.   103) so ..do something else.. is inaccessible except by using a code 
  760.   hexaddress.  A better format is:
  761.  
  762.   100  if (...)
  763.   101     {..do something..}
  764.   102  else 
  765.   103     {..do something else..}
  766.   104
  767.  
  768.   The 'for' statement also causes problems.  The decision code for the 'for' 
  769.   statement is actually done at the bottom of the loop and often is included 
  770.   as part of the next line where you would normally think the statement was 
  771.   completed.  The best solution here is to add a blank line after the 'for' 
  772.   statement loop.
  773.  
  774.   In short, it's best to use plenty of vertical spacing and blank lines.  
  775.   Also take a peek at the assembly code to see what's going on.
  776.  
  777.  
  778.  
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786.  
  787.  
  788.                                      12
  789.  
  790.  
  791.  
  792.  
  793.