Every program's code and data are stored in blocks called “segments.” The memory model of the program determines the organization of these segments. (See Chapter 16 for more information on segments.) The memory model also determines what kind of executable file is generated. All models except tiny produce an .EXE file. The tiny model produces a .COM file. Any version of CL that targets a 32-bit system offers only the small memory model (/AS). CL offers the memory-model options described in Table 13.1.
Table 13.1 Memory Models
| CL Option |
Memory Model |
Data Segments |
Code Segments |
Long Form |
| /AT | Tiny | One segment for both data and code | One segment for both data and code | none |
| /AS | Small | One | One | /Asnd |
| /AM | Medium | One | One code segment per module | /Alnd |
| /AC | Compact | Multiple data segments; data items must be smaller than 64K | One | /Asfd |
| /AL | Large | Multiple data segments; data items must be smaller than 64K | One code segment per module | /Alfd |
| /AH | Huge | Multiple data segments; arrays can be larger than 64K | One code segment per module | /Alhd |
By default, the compiler uses the small memory model.
For programs that target 16-bit processors, memory models with multiple code segments can accommodate larger programs than can memory models with one code segment. Memory models with multiple data segments can accommodate more data-intensive programs than can memory models with one data segment. Programs with multiple code or data segments, however, are slower than programs with a single code or data segment. A program destined to be a Windows DLL can use only a single data segment.
For 32-bit target code, memory is no longer partitioned into hardware-defined 64K segments. The compiler still partitions each program into one code segment and one data segment; the size of the segments is limited only by the amount of memory addressable by a 32-bit pointer—about 4 gigabytes.
It is more efficient to compile with the smallest possible memory model and use the __near, __far, __huge, and __based keywords to override the default addressing conventions for any data items or functions that cannot be accommodated in that model. For more information, see Chapter 4 in the Programming Techniques manual.
CL also supports customized memory models, in which different features from standard memory models are combined. You specify a customized memory model with the /Astring option, where string is composed of three letters that specify the code pointer size, the data pointer size, and the stack and data segment setup, respectively. All three letters must be present, but they can appear in any order. The allowable letters appear in Table 13.2.
Table 13.2 Customized Memory Model Codes
| Group | Code | Description |
| Code pointers | s l | Small Large |
| Data pointers | n f h |
Near Far Huge |
| Segment setup | d u w |
SS == DS SS != DS; DS loaded for each function entry SS != DS; DS not loaded at function entry |
As examples, the customized representations of the standard memory models appear in the Long Form column of Table 13.1.
The segment setup codes can also be given as separate options when used to modify a standard memory model. For example, the options /ASu specify the small model and force DS to be loaded at function entry.
The memory-model and math options used to compile the program determine the library the linker searches to resolve external references. The library name is mLIBCf.LIB, where the memory-model option determines m: S for small (default) or tiny model, M for medium model, C for compact model, or L for large or huge model, and the math option determines f: E for emulator (default), A for alternate math, or 7 for 8087/80287. For example, the following specifies a small-model library with coprocessor support:
MLIBC7.LIB
For more information on the math options, see “/FP Options”.