home *** CD-ROM | disk | FTP | other *** search
/ C!T ROM 2 / ctrom_ii_b.zip / ctrom_ii_b / PROGRAM / FOXPRO / FFAQ / INTER_A.FAQ < prev    next >
Text File  |  1992-04-11  |  8KB  |  181 lines
  1.     FORCE FAQ (Frequently Asked Questions)   (inter_a 1.1)             1
  2.     --------------------------------------------------------------------
  3.  
  4.     Topic:   INTERFACING WITH Assembler             Author: David Holmes
  5.  
  6.     What you'll find here:
  7.  
  8.        ( ) General discussion and easy FAQ answers
  9.        ( ) How to pass parameters from FORCE to ASM functions
  10.        ( ) Other, miscellaneous but frequently asked ASM/FORCE questions
  11.  
  12.     Examples: A_EXMPL1.ZIP
  13.  
  14.     General discussion and easy FAQ answers:
  15.     -------------------------------------------------------------------
  16.  
  17.     The FORCE compiler and it's FORCE library were written in assembler
  18.     (those of you championing ASM clap now), so FORCE partakes of all
  19.     the advantages and disadvantages of writing in Assembler.  Let's
  20.     outline those, just for fun:
  21.  
  22.     The advantages:  FORCE offers incredible control over the DOS
  23.     environment.  The function "more_handles()" is a good example.
  24.     Assembly allows FORCE to generate the fastest run-time code of all
  25.     the xbase compilers, while still generating (usually by far) the
  26.     smallest and tightest run-time code.
  27.  
  28.     The disadvantages:  Non-portability being the primary one.  We
  29.     can't just port the compiler to a Mac or UNIX environment by using
  30.     #ifdefs and huge Makefiles.  Support is a little more difficult
  31.     also, when you have support personnel for whom 86 assembler is a
  32.     second or third or fourth language (comme moi-meme).
  33.  
  34.         However, those are moot points, because FORCE is here, and
  35.     it has a lot of time and code invested in making it the quick and
  36.     tight compiler that it is.  So lets look no further at advantages
  37.     or disadvantages and get on to the business at hand.
  38.  
  39.     Compatibility:
  40.     -------------------------------------------------------------------
  41.     Q:    Is FORCE compatible with XxX brand assembler?
  42.  
  43.     A:    Given the unique nature of Assembly Language, FORCE should be
  44.     compatible with nearly all Assemblers.  However, I can only say for
  45.     sure that FORCE is compatible with MicroSoft's MASM and Borland's
  46.     TASM, the reason being that those are the only assemblers with
  47.     which I've tested (also, all of FORCE and its library were
  48.     developed with those two assemblers).
  49.  
  50.     Q:    Is FORCE compatible with XxX brand assembler linkers?
  51.  
  52.     A:    Of linkers, I can only say that MicroSoft's LINK.EXE
  53.     (versions 3.65 and lower) and Borland's TLINK.EXE (versions 2.0 and
  54.     lower) will work with FORCE.  Blink Inc's BLINKer works also, and
  55.     I've heard that Zortech's BLINK.EXE (no relation to Blink Inc) works
  56.     also, but I can't confirm that last.  Any others, and you're on your
  57.     own, though    I can tell you that Borland's TLINK version 3.0 and 4.0
  58.     will NOT work.
  59.     -------------------------------------------------------------------
  60.                                                                       1
  61.     FORCE FAQ (Frequently Asked Questions)                            2
  62.     -------------------------------------------------------------------
  63.  
  64.     How FORCE Passes Parameters
  65.     -------------------------------------------------------------------
  66.           Before I answer the questions coming up, I think we should
  67.     have a quick discussion on how FORCE passes parameters.  Understand-
  68.     ing of this is crucial to mixing ASM and FORCE effectively, so here
  69.     we go:
  70.  
  71.           FORCE passes parameters in two different ways:  by reference
  72.     and by value.  When you pass by reference, FORCE passes the address
  73.     of the parameter rather than pushing the entire parameter on to the
  74.     stack, as is done when you pass by value.  That is, when you pass
  75.     by value, you pass a copy of the original, and when you pass by
  76.     reference, you pass a pointer to the original.
  77.  
  78.           FORCE decides on how to pass parameters by looking at the
  79.     function prototypes, and checking to see whether the "PARAMETERS"
  80.     part of the function prototype has the modifiers VALUE or CONST.
  81.     Make sense?  Clear as mud, right?  Here's code to say what I mean:
  82.  
  83.     FUNCTION INT hash PROTOTYPE
  84.        PARAMETERS VALUE INT      && will pass the actual integer, say 5
  85.  
  86.     FUNCTION INT hash2 PROTOTYPE
  87.        PARAMETERS INT      && will pass the full address, say 023A:0004
  88.  
  89.  
  90.     How to pass parameters from FORCE functions to ASM functions
  91.     --------------------------------------------------------------------
  92.     Q:    What is involved in writing ASM routines for FORCE?
  93.  
  94.     A:    Writing ASM routines for FORCE is fairly straight-forward,
  95.     if you know assembly language.  I'm afraid a quick ASM tutorial
  96.     is beyond the scope of this FAQ list, so if you don't know ASM,
  97.     go learn it, and then come back (see you in a bit).  And, if you
  98.     haven't read the above section on "How FORCE Passes Parameters,"
  99.     do so now.
  100.  
  101.     When writing ASM routines for FORCE, follow two rules of thumb:
  102.         1) All calls and pointers are far.
  103.         2) You must save DS, SI, ES, and DI for each routine.
  104.             (unless you don't trash them in your code).
  105.  
  106.     What that translates to is that when you declare your "procs," you
  107.     can't    declare them as NEAR (unless they are not called by FORCE),
  108.     and when you reference pointers from the stack, you must grab not
  109.     only the offset, but also the segment.    Using the simplified segment
  110.     directive ".model large" can save you some work for the former, but
  111.     you have to do the latter by hand.  Here's a quick little code segment
  112.     to say what I mean (and you seasoned ASM programmers, please refrain
  113.     from laughing at my code for a few minutes; ASM isn't my primary
  114.     language):
  115.  
  116.     ;    FUNCTION INT hash PROTOTYPE
  117.     ;        PARAMETERS char, value int
  118.  
  119.     -------------------------------------------------------------------
  120.                                                                       2
  121.     FORCE FAQ (Frequently Asked Questions)                            3
  122.     -------------------------------------------------------------------
  123.  
  124.     and the assembly would begin like this:
  125.  
  126.     _hash        proc    far    ; not near!
  127.             push    bp        ; set up our stack ref
  128.             mov    bp,sp
  129.             push    ds        ; save the segment registers
  130.             push    si
  131.  
  132.             mov    ax,word ptr ss:[ bp+8 ]    ; grab the string's segment
  133.             mov    ds,ax
  134.             mov    ax,word ptr ss:[ bp+6 ]    ; grab the string's offset
  135.             mov    si,ax
  136.             mov    dx,word ptr ss:[ bp+10] ; grab the hashvalue
  137.     ...    etc    ...
  138.             pop    si        ; restore the segment registers
  139.             pop    ds        ; (we didn't use es or di)
  140.             pop    bp
  141.             ret
  142.     _hash        endp
  143.  
  144.         Short and sweet as it is, that little code segment shows
  145.     both of the two "rules of thumb" I stated above, 1) that procedures
  146.     must be FAR, and 2) you must preserve the values of the DS:SI and
  147.     ES:DI segment:offset registers.
  148.  
  149.         Recall from the section "How FORCE Passes Parameters" that
  150.     FORCE will pass the address of any parameter unless that parameter
  151.     is modified with the CONST of VALUE modifiers.
  152.  
  153.         Therefore, when you write your assembler routines, be sure that
  154.     their corresponding FORCE prototypes are correct, or you'll destroy
  155.     your stack.  For example, if the prototype for the function hash()
  156.     above looked like this:
  157.  
  158.     FUNCTION INT hash PROTOTYPE
  159.         PARAMETERS VALUE char, VALUE int
  160.  
  161.     FORCE would load the entire 255 (or whatever) characters of the
  162.     string on to the stack and then call your hash() function.  If you
  163.     were expecting the address instead, you'd end up referencing a
  164.     string god-knows-where in memory, probably at 'lm':'Ho' or some-
  165.     thing like that.
  166.  
  167.         If you stick with the two rules of thumb stated above, you'll
  168.     be okay.  For anything more complicated than that, leave me a
  169.     message on the board and I'll take care of you there.
  170.  
  171.     P.S.  One final note.  Apparently, Borland's Turbo Assembler
  172.     (TASM) will generate non-standard code if you include the segment
  173.     directive DOSSEG.  Your FORCE code won't work with your assembler
  174.     files if you have this directive in your assembly code and you
  175.     link with TASM.
  176.  
  177.  
  178.  
  179.     -------------------------------------------------------------------
  180.                                                                       3
  181.