home *** CD-ROM | disk | FTP | other *** search
/ Programmer 7500 / MAX_PROGRAMMERS.iso / PASCAL / TPML2INL.ZIP / TPML2INL.COM / ML2INLIN.TXT < prev   
Encoding:
Text File  |  1988-06-29  |  6.9 KB  |  117 lines
  1. |D╔══════════════════╗════════════════════════════════════════════════════════════
  2. |D║ |5The Happy Hacker |D║════════════════════════════════════════════════════════════
  3. |D╚══════════════════╝════════════════════════════════════════════════════════════
  4.  
  5. ^C^1Machine Language to Turbo Pascal Inline
  6. ^Cby
  7. ^CAshraf Maher Kaiser
  8.  
  9.    Turbo Pascal allows the user to mix Pascal with Machine Language by using the
  10. Inline statement, which allows the insertion of the machine code in numeric
  11. format in the Turbo program.  The process of writing the Inline statements is
  12. tedious and error prone if done manually.  This utility reads in a .COM file and
  13. creates a file with equivalent Turbo Pascal Inline statement.  Just write the
  14. function in assembly, assemble and link it and convert it to a .COM or .BIN file
  15. with the EXE2BIN utility (or you can input it using DEBUG), then run this
  16. utility to get a Turbo procedure (or function) with equivalent Inline
  17. statements.
  18.  
  19.    The user supplies the name of the file to be converted to Turbo Inline
  20. statements, and the name of the file to be created.  The user may choose whether
  21. or not to have the offsets of the instructions printed, which may be useful for
  22. tracing branches in the code and data locations.
  23.  
  24.    The program works by determining the input file size, and writes out a file
  25. containing commands for DEBUG (the debugger that comes with MS-DOS) to
  26. disassemble the correct size of code. DEBUG is then invoked from within the
  27. program and its input is redirected from the file (INDEBUG) which contains the
  28. commands and its output is redirected to the file (OUTDEBUG).  Finally, the
  29. output file (OUTDEBUG) is processed to create the Turbo file containing Inline
  30. statements.  Therefore, the files COMMAND.COM and DEBUG.COM should be accessible
  31. to the program while running, and the program will prompt you for their drive
  32. letter and path.  Note that you will need plenty of disk space for the input
  33. and output files.
  34.  
  35.    The program then asks for the procedure or function name of the routine.
  36. Then it asks for any global variable references for your procedure or function.
  37. Next, it asks for local variables, that is any variables accessed by the
  38. assembly language routine.  Finally, it asks for the parameters to be passed to
  39. the procedure.  After entering the data for each routine, you will have a chance
  40. to change any of the data associated with each section.  If no type is entered 
  41. with a local variable or a passed parameter, then the next type entered will be 
  42. used unless you change from VAR to value or vice versa. 
  43.  
  44.    The key to this program working properly is in the coding of your assembler
  45. program.  Global variables should be placed in the data segment.  The type of
  46. variable determines its offset as assembled in the binary file and will
  47. correspond to the offset from start of the data segment in the assembly file.  
  48. The variables appear in the OUTDEBUG file as 4 digit offsets enclosed in 
  49. brackets, i.e. [0000],[0002].  If the type of variable specified in ML2INLINE 
  50. does not match the number of bytes defined in the assembler program, then 
  51. ML2INLINE will not properly place the Turbo global variable names in the inline 
  52. program.  Here is an example of assembler code with the associated Turbo code.
  53.  
  54. data    segment
  55. test1   db ?                    test1: byte;
  56. test2   dw ?                    test2: integer;
  57. test3   db 81 dup(?)            test3: string[80];    { specify as 81 bytes }
  58. test4   db ?                    test4: byte;                 { in ML2INLINE }
  59. data    ends
  60.  
  61.    Local variables and passed parameters are referenced in the inline code from
  62. the base pointer [BP].  Local variables should be coded in the assembly listing
  63. as negative offsets to BP.  The first variable is coded as [BP-1], the second as
  64. [BP-2], etc.  Parameters passed to the inline procedure should be passed as
  65. positive offsets to BP.  The first variable that Turbo pushes on the stack is
  66. coded as [BP+1], the second as [BP+2], etc.  The ML2INLINE entry routine assumes
  67. a 1 byte offset to the pointer, but if you are passing more than 255 bytes to
  68. the inline routine or accessing more than 255 bytes of local variables, then you
  69. should add 256 to the parameter number in the assembly code for that and all
  70. variables that follow it and change the 2 byte offset reference in the ML2INLINE
  71. entry to yes.  This is because the machine code is different for a one byte
  72. offset and a two byte offset.  Remember that Turbo passes the last variable in
  73. its parameter list first, and the first one last, but local variables are
  74. assigned in normal order.  The program follows this convention to keep you
  75. reminded of this.  Here is an example of Turbo code and what ML2INLINE expects 
  76. to see when it replaces the text. 
  77.  
  78.    Procedure Test (Up, Down: byte; Across: integer);
  79.    var
  80.       i,j: byte;
  81.       k: integer;
  82.  
  83.    ML2INLINE will replace [BP+3] with <Up, [BP+2] with <Down, and [BP+1] with
  84. <Across as passed parameters, and [BP-1] with i, [BP-2] as j, and [BP-3] with k
  85. as local variables.  If Across is changed to a type of String[255] then Down and
  86. Up will need offsets of 258 (102h) and 259 (103h) respectively, and ML2INLINE
  87. will expect to see [BP+0102] and [BP+0103], and will place >Down and >Up in the
  88. inline code.
  89.  
  90.    If your routine accesses global variables, then you should place 2 nops at 
  91. the end of the code segment.  ML2INLINE will detect these and you can end the 
  92. processing without the data segment bytes at the end of the inline code. 
  93. ML2INLINE will process multiple procedures.  Each procedure should be separated 
  94. by at least 2 nops.  The program detects 2 nops as the end of a procedure, so 
  95. that you can write several procedures in one file.  Global variables are 
  96. accessed throughout all the procedures, but each procedure will have its own 
  97. local variables and parameters.  If you have nested procedures, you will have to 
  98. place the proper amount of NOPs in your assembly code in order to get the 
  99. correct compiled addresses.  When Turbo compiles procedures, it places 
  100. instructions at the beginning and end of every procedure and function.  Turbo 
  101. places 7 bytes of code before every procedure and 7 bytes after if you pass no 
  102. parameters to the procedure.  If you pass any parameters to the procedure, Turbo 
  103. places 9 bytes after it.  If you declare local variables to the procedure, Turbo 
  104. places 1 extra byte of code if the total size of the local variables is 1 byte, 
  105. 2 extra bytes if the size is 2 bytes, 3 extra bytes if the size is 3 to 255 
  106. bytes and 4 extra bytes if the size is greater than 256 bytes.  This will enable 
  107. you to calculate the correct number of NOPs to put in your assembly language 
  108. code. 
  109.  
  110.    Since, there is not much extra disk space on this disk, you should run it 
  111. from outside the BIG BLUE DISK menu.  To run this program outside the BIG BLUE 
  112. DISK menu, type ^1ML2INLIN^0. 
  113.  
  114. DISK FILES USED BY THIS PROGRAM:
  115. ^FML2INLIN.COM
  116. ^FML2INLIN.CFG
  117.