Legacy Document

Inside Macintosh: Processes

Chapter 7 - Segment Manager / About the Segment Manager

Code Segmentation

Your development system's linker divides your application's executable code into segments according to directives that you provide. The main segment contains the main program. This segment is loaded into memory when your application starts to run and is never purged or unlocked as long as the application is running. The main event loop and other frequently needed small routines are generally stored in the main segment.

Most applications, however, consist of multiple code segments. There are two principal reasons for dividing code into different segments:

• Compiler limitations. Most development systems generate PC-relative instructions for intrasegment references (references to other routines within the same code segment). Because PC-relative instructions on an MC68000 use a 16-bit offset, the offset to the last routine in the segment cannot be larger than 32K bytes. Some development systems therefore restrict the size of any one code segment to 32K bytes.
• Memory limitations. Many applications are so large that the entire executable code, together with static data (such as your application's global data and resources) and data created dynamically during the execution of the application (such as windows and the items they contain), simply cannot fit into a memory partition of reasonable size.

By dividing your executable code into segments, you can circumvent both these limitations. The size of your application can increase as required to provide the desired capabilities without necessitating an increased run-time memory partition. For example, code that isn't executed very often (such as code for printing a document) can be put into a separate segment; it's loaded when needed and can be unloaded to free the memory for other uses when it's no longer needed.

Note

Some development systems allow you to create segments that are larger than 32K bytes. Consult your development system's documentation to determine how and when to increase segment size. ·

The key fact to keep in mind when deciding how to group routines into segments is that an entire segment is loaded into memory whenever you call one of the routines in the segment. It makes sense, therefore, to group related routines in the same segment. You should segment routines according to your run-time call chain rather than on a simple file-by-file basis.

There are also some less obvious guidelines to follow when grouping routines into segments.

• Put your main event loop into the main segment.
• Put any routines that handle low-memory conditions into a locked segment (commonly the main segment). For example, if your application provides a grow-zone function, put that function into a locked segment.
• Put any routines that execute at interrupt time, including VBL tasks and Time Manager tasks, into a locked segment (commonly the main segment).
• Put into a separate segment any initialization routines that are executed exactly once at application startup time. Then unload that segment after those routines are executed. There is, however, at least one important exception to this rule. Routines that allocate nonrelocatable objects in your application heap should be called in the main segment, before you load any code segments that will later be unloaded. If you put such allocation routines into a code segment that is later unloaded and purged, you increase heap fragmentation. Routines such as MoreMasters and InitWindows, which are typically called at the beginning of an application, allocate nonrelocatable objects and should therefore be in the main segment.