Linking. Many assembly language programs are written as several smaller pieces rather than as a single large file. Breaking a large program into smaller files helps delineate program modularity. If the program uses library routines, those will already be preassembled, and assembly language source code for the libraries may not be available for purchase.

A linker allows a program to be stitched together out of several smaller pieces. The linker operates on the object files created by the assembler and modifies the assembled code to make the necessary links between files.

Some labels will be both defined and used in the same file. Other labels will be defined in a single file but used elsewhere as illustrated in Figure 5-11 below. The place in the file where a label is defined is known as an entry point. The place in the file where the label is used is called an external reference.

The main job of the loader is to resolve external references based on available entry points. As a result of the need to know how definitions and references connect, the assembler passes to the linker not only the object file but also the symbol table. Even if the entire symbol table is not kept for later debugging purposes, it must at least pass the entry points. External references are identified in the object code by their relative symbol identifiers.

Figure 5-11. External references and entry points.

The linker proceeds in two phases. First, it determines the absolute address of the start of each object file. The order in which object files are to be loaded is given by the user, either by specifying parameters when the loader is run or by creating a load map file that gives the order in which files are to be placed in memory.

Given the order in which files are to be placed in memory and the length of each object file, it is easy to compute the absolute starting address of each file. At the start of the second phase, the loader merges all symbol tables from the object files into a single, large table. It then edits the object files to change relative addresses into absolute addresses.

This is typically performed by having the assembler write extra bits into the object file to identify the instructions and fields that refer to labels. If a label cannot be found in the merged symbol table, it is undefined and an error message is sent to the user.

Controlling where code modules are loaded into memory is important in embedded systems. Some data structures and instructions, such as those used to manage interrupts, must be put at precise memory locations for them to work. In other cases, different types of memory may be installed at different address ranges. For example, if we have EPROM in some locations and DRAM in others, we want to make sure that locations to be written are put in the DRAM locations.

Workstations and PCs provide dynamically linked libraries, and certain sophisticated embedded computing environments may provide them as well. Rather than link a separate copy of commonly used routines such as I/O to every executable program on the system, dynamically linked libraries allow them to be linked in at the start of program execution.

A brief linking process is run just before execution of the program begins; the dynamic linker uses code libraries to link in the required routines. This not only saves storage space but also allows programs that use those libraries to be easily updated. However, it does introduce a delay before the program starts executing.

Next, in Part 3: Basic compilation techniques.
To read Part 1, go to "Program design and analysis."

Used with the permission of the publisher, Newnes/Elsevier, this series of nine articles is based on copyrighted material from "Computers as Components: Principles of Embedded Computer System Design" by Wayne Wolf. The book can be purchased on line.

Wayne Wolf  is currently the Georgia Research Alliance Eminent Scholar holding the Rhesa "Ray" S. Farmer, Jr., Distinguished Chair in Embedded Computer Systems at Georgia Tech's School of Electrical and Computer Engineering (ECE). Previously a professor of electrical engineering at Princeton University, he worked at AT&T Bell Laboratories. He has served as editor in chief of the ACM Transactions on Embedded Computing and of Design Automation for Embedded Systems.

References:
[Dou99] Bruce Powell Douglas, Doing Hard Time: Developing  Real Time Systems with UML. Addison Wesley, 1999.
[Chi94] M.Chiodo, et. al., "Hardware/software codesign of Embedded Systems," IEEE Micro, 1994

Reader Response

Figure 5-5 is missing an edge. The for/while loop discussion is unclear - no text addresses the while (a<b) loop, and placing the diagrams prior to the referencing text is confusing. If I did not already know the material, I would have a difficult time learning from your article. Quite frankly, I found similar presentation problems in the other parts (1-6) of your article. The most recently published article in the series appears to be a more clearly presented, and is more "in-depth", but if the early installments are representative samples from the book, I am not sure I would buy the book. -Michael Ruckstuhl
Orlando, FL

Thanks for the feedback. I have fixed the artwork. As to the positioning of the artwork, I will keep that in mind in the future. But different folks have different strokes. For example, when I read an article, I go through and "read" the graphics first to get a sense of the flow of the article. On the other hand, the original textbook from which this is derived uses your suggestion. But on-line, the problems and layout are different and it is necessary for good visual design to space out the graphics to break up the text into more readable chunks.

In terms of the substance of the article series, I look for content that reaches a broad range of readers, from professionals to students learning to be professionals and am willing to publish good articles where ever I can find them. If you have some ideas for articles that would more clearly explain some topics in this series, please submit a proposal for an article or articles and I will happily consider it. - Bernard Cole, Embedded.com site editor.