Purpose of the M-bit and FRAME DATUM Fields

 Last reviewed: July 17, 1997
Article ID: Q66579
3.x 4.x 5.x | 1.x 
MS-DOS      | OS/2
kbtool

The information in this article applies to:

  • Microsoft LINK Utility for MS-DOS, versions 3.x, 4.x, and 5.x
  • Microsoft LINK Utility for OS/2, versions 1.x

SUMMARY

One of the jobs of the linker is to resolve (fix up) addresses which the compiler or assembler could not resolve. This article clarifies a couple of points discussed in "Article 19: Object Modules" in the "MS-DOS Encyclopedia".

MORE INFORMATION

The M-bit field in the fixup field of the FIXUPP record is described in the "MS-DOS Encyclopedia." Its value determines if the linker should calculate the address from the start of the segment in question (segment-relative), or from the current location in the code/data (self-relative). The following is an example: 

                   MYSEG Segment

       -->      +-----------------+     <-- Start of segment
      |         |                 |
      |         |                 |
      |         |                 |
      |         |                 |
      |    -->  +-----------------+     <-- Reference to symbol
      |   |     |                 |
          |     |                 |
     (A)  |     |                 |
                /                 \
      |  (B)    \                 /
      |         /                 \
      |   |     \                 /
      |   |     |                 |
      |   |     |                 |
       --> -->  +-----------------+     <-- Symbol
                /                 \
                \                 /
                /                 \
                \                 /
                +-----------------+     <-- End of segment
In this example, (A) is the segment-relative address and (B) is the self- 
relative address. The self-relative calculation is used when you   want to
jump forward a certain number of bytes in the code (for example, a short jump). The calculation is fairly straightforward. Calculate the segment- relative address for the symbol. Subtract the segment-relative address of the reference, and you have the self-relative address for the symbol from the reference.

The FRAME DATUM field is used in almost exactly the same manner. It might seem that the fields TARGET DATUM and TARGET DISPLACEMENT are sufficient to fix up references in an LEDATA or LIDATA record. To understand why it is required, see the following example:

Microsoft C/C++ compilers (16-bit) generate a group called DGROUP that holds data segments _NULL, _DATA, _CONST, and so forth. The fixups that it generates are similar to the following: 

   frame DGROUP target _CONST
   frame DGROUP target _DATA
   ...
For the average MS-DOS program, this is fine. We could, eliminate the FRAME DATUM field and change target to DGROUP, right? Wrong. Examine ROMable code; they use the same OBJ. In that case, the linker must know if a reference to _CONST is a far reference (based on DGROUP) or a near reference (based on CONST). If we only told it to use DGROUP, it would have no idea how to resolve the references to _CONST after it moved _CONST to another segment (for example, ROM based). If we left in the target _CONST and removed the frame DGROUP, we would have the wrong address for MS-DOS, right? Hence, FRAME DATUM *is* important.

The way the FRAME DATUM field affects the fixup makes sense, given the example above for the M-bit. Just calculate the offset based on the TARGET segment and add in the offset from the FRAME.

Additional reference words: kbinf kbinf
KBCategory: kbtool
KBSubcategory: LinkIss
Keywords : kb16bitonly

THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: July 17, 1997
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.