Click above to get retro games delivered to your door ever month!

  Once you have your assembly language in hand, you'll need to examine the
  assembly-language conventions and interface customs that apply to your
  programming language. Your assembly-language interface will have to know
  how to gain access to the parameters passed by the calling program, how to
  interpret the data format, and how to send the parameters back--among
  other things. Even if your language documentation doesn't provide such
  information, you can obtain it from the language itself.

  To learn the conventions for both a calling and a called program--that is,
  to see both sides of the program-call interface--you can study your
  compiler's assembler-style listing, as we mentioned earlier. You can also
  study the assembly-language subroutines provided with the language
  compiler for a somewhat different perspective. This technique not only
  provides the interface conventions for assembly-language routines but also
  gives you specific programming examples that can serve as models.

  The most accessible subroutines are often part of the libraries that
  accompany your compiler. Usually, it is easiest to simply choose a
  compiler feature that you're interested in, such as I/O, screen control,
  or arithmetic, and then determine which subroutines are invoked for that
  feature.

  A few compiler vendors sell source code for their subroutine libraries. If
  source code isn't available, however, you'll have to resort to
  disassembling the actual subroutines by extracting them from your
  compiler's object libraries. You can locate a particular subroutine in an
  object library by using a library manager like LIB to list the contents of
  the library. Let's assume there's a library named SLIBC.LIB on your disk.
  You can direct the library listing to another file named LISTING.TXT with
  the following DOS instruction:

  LIB SLIBC,LISTING.TXT;

  Look over the library listing to find the subroutine you're interested in
  and the name of the module that it's a part of; let's say the subroutine's
  name is _abs and the name of the library module containing it is ABS. You
  can use LIB to extract ABS from the library and create a separate object
  file, ABS.OBJ:

  LIB SLIBC *ABS;

  At this point, you could try to look inside ABS.OBJ. But because this file
  contains extraneous link-editor information that would only get in your
  way, it's easier to convert the object module into an executable file
  (even though it's only a subroutine and not a complete program). Use the
  linker utility, LINK, to do this:

  LINK ABS;

  LINK generates an executable file, ABS.EXE. In the process, you'll
  probably see a few error messages, because the subroutine you're linking
  isn't a complete program and lacks such necessities as a stack. That's not
  important in this case, because you really only want to examine the
  subroutine's executable code.

  To disassemble the subroutine, use DEBUG:

  DEBUG ABS.EXE

  You can now use DEBUG's U command to convert the executable code into
  readable assembly-language instructions. First, note the size of your .EXE
  file, and subtract 512 bytes to determine the actual size of the
  subroutine. (The 512 bytes contain information that is used by DOS to load
  an executable program, but that is not part of the subroutine itself.) For
  example, if the size of ABS.EXE is 535 bytes, the size of the subroutine
  is actually only 23 (hexadecimal 17) bytes. The DEBUG command to use would
  then be

  U 0 L17

  These steps may seem overly elaborate and cumbersome, but once you learn
  them, you can perform them quickly and easily, and they will give you an
  inside look at how your own programming language uses assembly-language
  interface routines.

  The next section will repeat the key steps of this exercise as we
  demonstrate the mechanics of creating a small but complete
  assembly-language program.