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.
This chapter includes the following sections:
There are two code models:
There are two data models:
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.
As previously mentioned, a memory model is a combination of a code model and a data model. The following table describes the memory models supported by Watcom C/C++.
|Memory Model||Code Model||Data Model||Default Code Pointer||Default Data Pointer|
In the flat memory model, the application's code and data must total less than 4GB in size. Segment registers CS, DS, SS and ES point to the same linear address space (this doesn't imply that the segment registers contain the same value). That is, a given offset in one segment refers to the same memory location as that offset in another segment. Essentially, a flat model operates as if there were no segments.
A mixed memory model application combines elements from the various code and data models. A mixed memory model application might be characterized as one that uses the near, far or huge keywords when describing some of its functions or data objects.
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.
Each memory model requires different runtime and floating-point libraries. Each library assumes a particular memory model, and should be linked only with modules that have been compiled with the same memory model. The following table lists the libraries that are to be used to link an application that has been compiled for a particular memory model. Currently, only libraries for the flat/small memory model are provided:
|Runtime Library||Floating-Point Library (80x87)||Floating-Point Library (f-p calls)|
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.
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.
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++:
You can override the default naming convention used by Watcom C/C++ to name segments: