Use of the /Gt Switch in C

Last reviewed: July 17, 1997
Article ID: Q49840
6.00 6.00a 6.00ax 7.00 | 6.00 6.00a | 1.00 1.50
MS-DOS                 | OS/2       | WINDOWS
kbtool kbfasttip

The information in this article applies to:

  • The Microsoft C/C++ Compiler (CL.EXE) component, included with:

        - Microsoft C for MS-DOS, versions 6.0, 6.0a, and 6.0ax
        - Microsoft C for OS/2, versions 6.0, and 6.0a
        - Microsoft C/C++ for MS-DOS, version 7.0
        - Microsoft Visual C++ for Windows, versions 1.0 and 1.5
    

In Microsoft products mentioned above, the way /Gt is used determines which data items are moved out of the default data segment. /Gt alone is the same as /Gt256, which means that ONLY data items of size 256 and

 greater get moved out. If you have a lot of data items smaller than
that, that data will NOT get moved out. With /Gt256, the data left in DGROUP plus the stack may still exceed 64K.

As the value on the /Gt switch becomes smaller, more and more data gets pushed out. /Gt0 pushes all the data generated by your program out. However, it also generates some constants in the logical segment _CONST in DGROUP -- 2 bytes for each extern or uninitialized variable moved. The following classes of variables generate a 2-byte segment address in DGROUP for EACH variable of that class declared when /Gt0 is used:

  1. All extern declarations, such as "extern int i;"

  2. All declarations without storage class that are not initialized, such as "int i;"

Initialized variables, such as "int i = 0;", provided that the sum of their sizes is less than 64K, are treated as a group and generate only one segment address in DGROUP per module. Therefore, the optimal number for minimizing DGROUP space is /Gt3. /Gt3 is better than /Gt0 for uninitialized and extern variables because /Gt0 will move out 1- and 2-byte data elements to the far heap, replacing them with 2-byte segment addresses. Not only does this NOT save you space in DGROUP V.S. /Gt3, but it increases the overall size of the executable V.S. /Gt3, as you also have to pay 2 bytes in the far heap per data element moved. Another reason to use /Gt3 over /Gt0 is that although the size of DGROUP will remain the same, /Gt0 will cause character and integer data elements to be addressed with far pointers, slowing execution. With /Gt0, all that remains in DGROUP is the stack, several kilobytes of variables associated with the run-time library, the near heap (from which will be allocated some file buffers and the local copy of the environment), and the 2-byte segment addresses for data items moved out as needed.


Additional reference words: kbinf 1.00 1.50 6.00 6.00a 6.00ax 7.00 8.00
8.00c L2041
KBCategory: kbtool kbfasttip
KBSubcategory: CLIss
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.