Professional Documents
Culture Documents
32 Bit Memry Model
32 Bit Memry Model
This chapter describes the various 32-bit memory models supported by Watcom C/C+
+. Each memory model is distinguished by two properties; the code model used to
implement function calls and the data model used to reference data.
small code model - all calls to functions are made with near calls. In a near call, the
destination address is 32 bits, and is relative to the segment value in segment register CS.
Hence, in a small code model, all code comprising your program, including library
functions, must be less than 4GB.
big code model - all calls to functions are made with far calls. In a far call, the
destination address is 48 bits (a 16-bit segment value and a 32-bit offset relative to the
segment value). This model allows the size of the code comprising your program to
exceed 4GB. QNX doesn't support the big code model.
If your program contains less than 4GB of code, you should use a memory model that employs
the small code model. This results in smaller and faster code, since near calls are smaller
instructions and are processed faster by the CPU.
small data model - all references to data are made with near pointers. Near pointers are
32 bits; all data references are made relative to the segment value in segment register DS.
Hence, in a small data model, all data comprising your program must be less than 4GB.
big data model - all references to data are made with far pointers. Far pointers are 48 bits
(a 16-bit segment value and a 32-bit offset relative to the segment value).
This removes the 4GB limitation on data size imposed by the small data model. However,
when a far pointer is incremented, only the offset is adjusted. Watcom C/C++ assumes
that the offset portion of a far pointer isn't incremented beyond 4GB. The compiler
assigns an object to a new segment if the grouping of data in a segment causes the object
to cross a segment boundary. Implicit in this is the requirement that no individual object
exceed 4GB.
If your program contains less than 4GB of data, you should use the small data model. This
results in smaller and faster code, since references using near pointers produce fewer
instructions.
Memory Model Code Model Data Model Default Code Pointer Default Data Pointer
flat small small near near
small small small near near
For example, a medium memory model application that uses some far pointers to data can be
described as a mixed memory model. In an application such as this, most of the data is in a 4GB
segment (DGROUP), and hence can be referenced with near pointers relative to the segment value
in segment register DS. This results in the generation of more efficient code, and better execution
times than one can expect from a big data model. Data objects outside of the DGROUP segment are
described with the far keyword.
The letter ``r'' or ``s'' that's affixed to the file name indicates the particular strategy with which
the modules in the library have been compiled.
r
denotes a version of the Watcom C/C++ 32-bit libraries that have been compiled for the
flat/small memory models using the 3r, 4r or 5r option.
s
denotes a version of the Watcom C/C++ 32-bit libraries that have been compiled for the
flat/small memory models using the 3s, 4s or 5s option.
Memory layout
The following describes the segment ordering of an application linked by the Watcom Linker.
Note that this assumes that the DOSSEG linker option has been specified.
1. all USE16 segments. These segments are present in applications that execute in both real
mode and protected mode. They are first in the segment ordering so that
the REALBREAK option of the RUNTIME directive can be used to separate the real-mode part
of the application from the protected-mode part of the application. Currently,
the RUNTIME directive is valid for Phar Lap executables only.
2. all segments not belonging to group DGROUP with class CODE
3. all other segments not belonging to group DGROUP
4. all segments belonging to group DGROUP with class BEGDATA
5. all segments belonging to group DGROUP not with class BEGDATA, BSS or STACK
6. all segments belonging to group DGROUP with class BSS
7. all segments belonging to group DGROUP with class STACK
Segments belonging to class BSS contain uninitialized data. Note that this only includes
uninitialized data in segments belonging to group DGROUP. Segments belonging to
class STACK are used to define the size of the stack used for your application. Segments
belonging to the classes BSS and STACK are last in the segment ordering, so that uninitialized data
need not take space in the executable file.
In addition to these special segments, the following conventions are used by Watcom C/C++:
1. The CODE class contains the executable code for your application. In a small code model,
this consists of the segment _TEXT. In a big code model, this consists of the
segment module_TEXT, where module is the file name of the source file.
2. The FAR_DATA class consists of the following:
o data objects whose size exceeds the data threshold in large data memory models
(the data threshold is 32K unless changed using the zt compiler option)
o data objects defined using the FAR or HUGE keyword
o literals whose size exceeds the data threshold in large data memory models (the
data threshold is 32K unless changed using the zt compiler option)
o literals defined using the FAR or HUGE keyword.
You can override the default naming convention used by Watcom C/C++ to name segments:
The nm option for the Watcom C/C++ compiler can be used to change the name of the
module. This, in turn, changes the name of the code segment when compiling for a big
code model.
The nt option for the Watcom C/C++ compiler can be used to specify the name of the
code segment, regardless of the code model used.