home *** CD-ROM | disk | FTP | other *** search
/ Fish 'n' More 2 / fishmore-publicdomainlibraryvol.ii1991xetec.iso / disks / disk393.lzh / LibTool / AsmSimple / Simple.DOC < prev    next >
Text File  |  1990-10-28  |  9KB  |  167 lines

  1.  This document describes how to make the simple.library assembly example.
  2.  
  3.   A shared library is a disk-based executable file that usually resides in
  4. the LIBS drawer of your boot disk. Such a library contains functions that
  5. your application can call, but which are not a part of your program. Many
  6. other applications can open and use the same shared library (usually simul-
  7. taneously), thus saving memory when the applications are run concurrently.
  8. Also, a shared library can help reduce development time in new products since
  9. you can make a library of commonly used routines, and just open and use it
  10. for each program that you write. There's no need to scavange old code, re-
  11. compile or re-assemble previously written functions, modify code to avoid
  12. conflicting labels and variable names, or re-edit old INCLUDE files. Also,
  13. you can allow other programmers to make use of your libraries without having
  14. to give away source code or object modules of the functions.
  15.   The first step in making a shared library is to write and test the functions
  16. which you intend to put in the library. The easiest way to do this is to
  17. develop a self-contained program to test the functions. When you are finished
  18. modifying the functions and are certain that they work properly, separate them
  19. from the rest of the code along with their variables. When writing lib
  20. functions, it is best to avoid using global variables. Use locals or allocate
  21. mem as needed. This will make your library truly reentrant (many tasks can use
  22. it simultaneously without stomping on each other's variables). The only globals
  23. in your lib code should be pre-initialized variables which never change value
  24. (such as an error message string). Place these functions in their own ascii
  25. text file. Save the remainder of your test program since this will be turned
  26. into a test application to open and use the new library.
  27.   The text file, "Simple.asm", is an example of this. I created 3 routines,
  28. Add2Numbers, Sub2Numbers, and Mult2Numbers which I wish to turn into a shared
  29. library.
  30.   In order to turn these functions into a library, I need to create two more
  31. files: an fd file which describes what args are passed to the functions in
  32. which regs, and a library startup code to be linked with these functions.
  33.   "Simple.fd" is an example of an fd file. Here is the contents of that file:
  34.  
  35. ##base SimpleBase *the name of our base used by C glue code and C PRAGMAS
  36. ##name simple     *the name of our library (i.e. simple.library)
  37. ##vers 1          *version #
  38. ##revs 0          *revision #
  39. ##libid  simple asm lib (ver 1.0)
  40. ##bias 30         *first function is always at an offset of -30 from lib base
  41. *Here are all of the lib functions callable by an application
  42. * These 3 functions return ULONG
  43. ##ret ULONG
  44. Add2Numbers(num1,num2)(D0,D1)
  45. Sub2Numbers(num1,num2)(D0,D1)
  46. Mult2Numbers(num1,num2)(D0,D1)
  47. ##end
  48.  
  49.   Note that some of the lines begin with ##. This indicates that this line is
  50. a command. The command follows the ##.
  51.   For example, the first line begins with ##base. This means that the label
  52. following ##base is the variable which is used in C glue stubs for our library.
  53. I have chosen to name this variable SimpleBase. This is only used by a C app-
  54. lication, but you should always declare it anyway. A good naming method is to
  55. append "Base" to the name of your library. Thus, we come up with SimpleBase
  56. for this example.
  57.   The next line starts with ##name. This means that the following label is what
  58. we intend to call our library (minus the .library extension). So, our library
  59. is going to be named "simple.library".
  60.   The next line, ##vers, indicates what the version of our library is. This
  61. number is what an application uses when it opens our library.
  62.   The next line, ##revs, is the revision number of our library. This should be
  63. incremented everytime we make a new library which is backwardly compatible with
  64. an earlier library, but somehow different.
  65.   The next line, ##libid, is a string which describes our library. This can be
  66. anything you choose, but should include the name of the library and version
  67. and revision. Note that I chose "simple asm lib (ver 1.0)" for this string.
  68. The 1.0 means version 1, revision 0.
  69.   The next line, ##bias, indicates the negative offset from the library base
  70. for its first custom function. This should always be 30 for our purposes.
  71.   The next line, ##ret describes what the following function(s) return. For
  72. example, all 3 functions return ULONG. If I happened to have a fourth function,
  73. Blort() which returned a struct Window *, I would have to add a ##ret before
  74. Blort's function definition as so:
  75.  
  76. ##ret struct Window *
  77. Blort()
  78.  
  79.   This is only used for C applications which wish to take advantage of LibTool's
  80. ability to generate a C INCLUDE file. If you don't know how to declare a return
  81. value in the C language, then you can omit this command but then LibTool
  82. cannot automatically generate the C INCLUDE.
  83.   The next 3 lines are the descriptions of my 3 library functions. The order
  84. of these is arbitrary. Note that I have the name of the function and its input
  85. args in parenthesis, followed by the respective 68000 regs in which those args
  86. are passed. Note that the regs must line up with the args. For example, in
  87. Add2Numbers, num1 will be passed in D0. If a function doesn't require any input
  88. args, then I would only need 1 set of empty parenthesis. For example,
  89.  
  90. NoArgsFunc()
  91.  
  92.   The last line, ##end, just means that this is the end of the fd file.
  93.   You must create this fd file yourself. This file is then used by the LibTool
  94. program to create almost all of the other files needed for this project.
  95.   Now, let's make our simple.library. First, assemble the 3 functions
  96. (Simple.asm) into a resulting object file, Simple.o. Next, invoke LibTool.
  97.  
  98. LibTool -am Simple.fd
  99.  
  100.   This will make 2 files, "Simple.i" and "Simple.src". "Simple.i" is the
  101. INCLUDE file for our assembly application. "Simple.src" is the asm
  102. code which gets linked with our 3 functions and turns them into a shared
  103. library. Assemble "Simple.src" into a resulting object called "libstart.o".
  104. Now you must link the files. ALWAYS LINK THE SRC MODULE MADE BY LIBTOOL FIRST.
  105. For example,
  106.  
  107. blink libstart.o simple.o small.lib NODEBUG TO libs:simple.library
  108.  
  109. ln -o libs:simple.library libstart.o simple.o -lcl32
  110.  
  111. small.lib is available from CATS or on Fred Fish #92. We have now made our
  112. shared library and placed it in the LIBS: drawer as "simple.library".
  113.   This is the method you use to make any shared library.
  114.  
  115.   Now let's make an asm application to test the library. "SimpleApp.asm" is
  116. an example of this. Assemble this file. Link it with any standard startup code
  117. (not libstart.o!!!).  LibTool already made our INCLUDE file for us.
  118.  
  119. blink startup.o SimpleApp.o small.lib NODEBUG TO ram:TestProgram
  120.  
  121. ln -o ram:TestProgram ManxStartup.o SimpleApp.o -lcl32
  122.  
  123.   Now run ram:TestProgram and see how the application uses simple.library.
  124.  
  125.   Now, you may wish to allow you C and Basic programmer friends to use your
  126. library. You need to make support files for them. C programmers need a glue
  127. module(s) or a PRAGMA file. To make a glue file, do this
  128.  
  129. LibTool -o glue.asm Simple.fd
  130.  
  131.   This makes 1 module, glue.asm, containing all of the C stubs for all of the
  132. functions in your library. Make sure to tell your friend what the name of the
  133. library base is (i.e. SimpleBase in this example).
  134.  
  135. Here's how to make a PRAGMA file, "Simple.pragma", for the Lattice C compiler
  136.  
  137. LibTool -lp Simple.fd
  138.  
  139.   If you properly inserted the ##ret commands in the fd file, you can generate
  140. a C INCLUDE file as well.
  141.  
  142. LibTool -h Simple.fd
  143.  
  144.   For Basic programmers, you need to make a BMAP file.
  145.  
  146. LibTool -b Simple.fd
  147.  
  148.   This makes "Simple.BMAP". Remember that a BMAP file must be the same name as
  149. the library (minus the .library extension). This should be copied to the LIBS:
  150. directory of the boot disk.
  151.   AmigaBasic cannot have imbedded underscores in function names, so you should
  152. avoid having any in your library function names. LibTool will convert imbedded
  153. underscores to the exceptable "." and print an error msg to the CLI.
  154.   You should also avoid naming any lib functions the same as Basic keywords
  155. (i.e. don't call some function "Print").  LibTool also checks for the following
  156. known collisions, and prepends an "x" if found:
  157.  
  158.   abs,Close,Exit,Input,Open,Output,Read,tan,Translate,Wait,Write
  159.  
  160.   AmigaBasic cannot support passing any args in a5, a6, or obviously a7. If
  161. a lib function does this, then an error msg is posted to the CLI. There is no
  162. way to call such a function from AmigaBasic.
  163.  
  164.   After experimenting with creating a few of your own simple libraries, study
  165. the AsmComplex example which demonstrates a few more complicated considerations
  166. in constructing a library.
  167.