Retro video games delivered to your door every month!
Click above to get retro games delivered to your door ever month!
X-Hacker.org- Peter Norton Programmer's Guide - Norton Guide http://www.X-Hacker.org [<<Previous Entry] [^^Up^^] [Next Entry>>] [Menu] [About The Guide]

  The ROM BIOS services use some common calling conventions that provide
  consistency in the use of registers, flags, the stack, and memory. We'll
  outline the characteristics of these operating conventions, beginning with
  the segment registers.

  The code segment register (CS) is automatically reserved, loaded, and
  restored as part of the interrupt process. Consequently, you don't have to
  worry about your program's CS. The DS and ES registers are preserved by
  the ROM BIOS service routines, except in the few cases where they are
  explicitly used. The stack segment register (SS) is left unchanged, and
  the ROM BIOS services depend on you to provide a working stack.
  (Everything depends on a working stack!)

  The stack requirements of the ROM BIOS services are not spelled out and
  can vary considerably, particularly because some services invoke other
  services. Generally, however, most programs ought to be working with a
  much larger stack than the ROM BIOS services need.

  The ROM BIOS varies in its usage of the other 8086 registers. The
  instruction pointer (IP) is preserved by the same mechanism that preserves
  the code segment. In effect, the stack pointer (SP) is preserved because
  all the ROM BIOS services leave the stack clean, popping off anything that
  was pushed on during the service-routine execution.

  As usual, the general-purpose registers, AX through DX, are considered
  fair game. The standard rule is not to expect any contents of these
  registers to be maintained when you pass control to another routine, and
  that applies to the ROM BIOS services as well. If you closely inspect the
  coding of the services in the IBM technical reference manuals, you will
  find that one or more registers are left undisturbed in one service or
  another, but you would be foolish to try to take advantage of this. As a
  general rule, when a simple result is returned from a subroutine, it is
  left in the AX register; this applies to both the ROM BIOS and to all
  programming languages. We'll see how often this really happens when we
  cover the ROM BIOS services in detail.

  The index registers (SI and DI) can be changed, exactly like the AX
  through DX registers. The stack frame register (BP) can also be changed by
  a few ROM BIOS service routines.

  The various flags in the flag register are routinely changed as a
  by-product of the instruction steps in the ROM BIOS routines. You should
  not expect any of them to be preserved. In a few instances, the carry flag
  (CF) or the zero flag (ZF) is used to signal the overall success or
  failure of a requested operation.

  These details are important but rather tedious, and there is little reason
  for you to pay much attention to them. If your programs follow the general
  interface rules given in the next section, and if they follow the specific
  requirements of your programming language (covered in Chapters 19 and
  20), you may not need to be concerned with them at all.

  --------------------------------------------------------------------------
  NOTE:
    If you set out to use the ROM BIOS services in your programs, you'll
    naturally be concerned about the possible conflicts between the services
    and the operating conventions that your language follows. Put your mind
    at ease. You will find that you do not have to take any extraordinary
    precautions to protect your programming language from the ROM BIOS, or
    vice versa.
  --------------------------------------------------------------------------

Online resources provided by: http://www.X-Hacker.org --- NG 2 HTML conversion by Dave Pearson