IAT 1 Ans Key
IAT 1 Ans Key
QN Part A 8 x 2=16
1. What are the differences between a microprocessor and a R, CO1
microcontroller?
2. What are the addressing modes supported by 8051? R, CO1
3. Name the interrupts available in microcontroller 8051. R, CO1
4. Draw the format of PSW of 8051. R, CO1
5. Write a Short note on DCC Components. R, CO2
6. Bring out the difference between Program counter and program location U, CO2
counter.
7. Compare CISC versus RISC R, CO2
8. Define linker. R, CO2
Part B 2 x 13=26
9. A Describe the different modes of operation of timers in 8051. R, CO1
(OR)
9. B Explain the different addressing modes of 8051 microcontrollers. R, CO1
10. A Describe the Various stages involved in the design of train controller. R CO2
(OR)
10. B Describe the basic compilation techniques. R, CO2
Part C 1 x 8=8
11. Write a program for the 8051 to transfer “HELLO” serially at 9600 baud A,CO1
rate, 8-bit data, 1 stop bit do this continuously.
1.
2.
3.
4.
5. The Digital Command Control (DCC) was created by the National Model Railroad
Association to support interoperable digitally-controlled model trains.
Standard S-9.1, the DCC Electrical Standard, defines how bits are encoded on the rails for transmission.
Standard S-9.2, the DCC Communication Standard, defines the packets that
carry information.
6. Pc-stores the address of the next instruction. PLC-stores the address of the current inst.
7.
8.
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. Linkers allows a program to be stitched together out of several
smaller pieces.
B)
The way in which the data operands are specified is known as the addressing modes. There are various methods of
denoting the data operands in the instruction.
The 8051 microcontroller supports 5 addressing modes.
They are 1. Immediate addressing mode
2. Direct Addressing mode
3. Register addressing mode
4. Register indirect addressing mode
5. Indexed addressing mode
Immediate addressing mode:
The addressing mode in which the data operand is a constant and it is a part of the instruction itself is known as
Immediate addressing mode.
Normally the data must be preceded by a # sign.
This addressing mode can be used to transfer the data into any of the registers including DPTR. Examples: MOV
A, # 27 H : The data (constant) 27 is moved to the accumulator register
ADD R1, #45 H : Add the constant 45 to the contents of the accumulator
MOV DPTR, # 8245H : Move the data 8245 into the data pointer register.
In the addressing mode, the data operand is in the RAM location (00 -7FH) and the address of the data operand is
given in the instruction.
The direct addressing mode uses the lower 128 bytes of Internal RAM and the SFRs
Examples: MOV R1, 42H : Move the contents of RAM location 42 into R1 register
MOV 49H, A : Move the contents of the accumulator into the RAM location 49.
ADD A, 56H : Add the contents of the RAM location 56 to the accumulator.
1. A)
In order to learn how to use UML to model systems, we will specify a simple system, a model train controller. The
user sends messages to the train with a control box attached to the tracks.
The control box may have familiar controls such as a throttle, emergency stop button, and so on. Since the train
receives its electrical power from the two rails of the track, the control box can send signals to the train over the
tracks by modulating the power supply voltage. As shown in the figure, the control panel sends packets over the
tracks to the receiver on the train.
The train includes analog electronics to sense the bits being transmitted and a control system to set the train motor’s
speed and direction based on those commands.
Each packet includes an address so that the console can control several trains on the same track; the packet also
includes an error correction code (ECC) to guard against transmission errors. This is a one-way communication
system the model train cannot send commands back to the user.
We start by analyzing the requirements for the train control system. We will base our system on a real standard
developed for model trains. We then develop two specifications: a simple, high-level specification and then a more
detailed specification.
Requirements:
Before we can create a system specification, we have to understand the requirements. Here is a basic set of
requirements for the system:
The console shall be able to control up to eight trains on a single track.
The speed of each train shall be controllable by a throttle to at least 63 different levels in each direction (forward
and reverse).
There shall be an inertia control that shall allow the user to adjust the responsiveness of the train to commanded
changes in speed.
There shall be an emergency stop button. An error detection scheme will be used to transmit messages
Higher inertia means that the train responds more slowly to a change in the throttle, simulating the inertia of a large
train. The inertia control will provide at least eight different levels.
Let’s consider the entries in the form: A Model train control system
Name: This is simple but helpful. Giving a name to the project not only simplifies talking about it to other people
but can also crystallize the purpose of the machine.
Purpose: This should be a brief one- or two-line description of what the system is supposed to do. If you can’t
describe the essence of your system in one or two lines, chances are that you don’t understand it well enough.
Inputs and outputs: These two entries are more complex than they seem. The inputs and outputs to the system
encompass a wealth of detail:
Types of data: Analog electronic signals? Digital data? Mechanical inputs?
Data characteristics: Periodically arriving data, such as digital audio samples? Occasional user inputs? How many
bits per data element?
Types of I/O devices: Buttons? Analog/digital converters? Video displays?
Functions: This is a more detailed description of what the system does. A good way to approach this is to work
from the inputs to the outputs
When the system receives an input, what does it do? How do user interface inputs affect these functions? How do different
functions interact?
Performance: Many embedded computing systems spend at least some time controlling physical devices or
processing data coming from the physical world.
In most of these cases, the computations must be performed within a certain time frame. It is essential that the
performance requirements be identified early since they must be carefully measured during implementation to
ensure that the system works properly.
Manufacturing cost: This includes primarily the cost of the hardware components. Even if you don’t know exactly
how much you can afford to spend on system components, you should have some idea of the eventual cost range.
Cost has a substantial influence on architecture.
A machine that is meant to sell at $10 most likely has a very different internal structure than a $100 system.
Power: Similarly, you may have only a rough idea of how much power the system can consume, but a little
information can go a long way. Typically, the most important decision is whether the machine will be battery
powered or plugged into the wall. Battery- powered machines must be much more careful about how they spend
energy.
Physical size and weight: You should give some indication of the physical size of the system to help guide certain
architectural decisions. A desktop machine has much more flexibility in the components used than, for example, a
lapel mounted voice recorder.
10 B)
Compilation begins with high-level language. Simplifying arithmetic expressions is one example of a machine-
independent optimization. Not all compilers do such optimizations, and compilers can vary widely regarding which
combinations of machine- independent optimizations they do perform.
Instruction-level optimizations are aimed at generating code.
They may work directly on real instructions or on a pseudo-instruction format that is later mapped onto the
instructions of the target CPU.
This level of optimization also helps modularize the compiler by allowing code generation to create simpler code
that is later optimized. For example, consider the following array access code: x[i] = c*x[i];
A simple code generator would generate the address for x[i] twice, once for each appearance in the statement.
While in this simple case it would be possible to create a code generator that never generated the redundant
expression, taking into account every such optimization at code generation time is very difficult.
Better code and more reliable compilers are get by generating simple code first and then optimizing it.
11
RET
1. State the function of RS1 and RS0 bits in the flag R, CO1
register of Intel 8051 microcontroller.
2. What is the function of TMOD register? R, CO1
3. What is the size of the on-chip program memory and R, CO1
on-chip data memory of 8051 microcontroller?
4. What are the hardware and software interrupts of R, CO1
8051? Mention its vector addresses.
5. Differentiate Harvard architecture Vs Von-Neumann R, CO2
architecture.
6. Differentiate VLIW vs Superscalar. R, CO2
7. Write a note on Assembler. R, CO2
8. What are the applications of an embedded system? R, CO2
Part B 2 x 13=26
9. A Explain the instruction set of 8051 with examples. R, CO1
(OR)
9. B Explain serial communication in 8051. A, CO1
10. A Classify the ARM instruction set and explain with R CO2
examples.
(OR)
10. B Briefly explain about the steps involved in embedded R, CO2
system design.
Part C 1 x 8=8
11 Write short notes on Assembly, linking and loading. R, CO2
1.
6.
7.Assembler
9 A) Arithmetic instructions:
ADD
• 8-bit addition between the accumulator (A) and a second operand.
• The result is always in the accumulator.
• The CY flag is set/reset appropriately.
ADDC
• 8-bit addition between the accumulator, a second operand and the previous value of the CY flag.
• Subtract an operand and the previous value of a borrow (carry) flag from the accumulator.
• A A - <operand> - CY.
• MOVC A, @A+DPTR
• MOVC A, @A+PC
MOVX
Data transfer between the accumulator and a byte from external data memory.
• MOVX A, @Ri
• MOVX A, @DPTR
• MOVX @Ri, A
• MOVX @DPTR, A
PUSH / POP
Push and Pop a data byte onto the stack.
The data byte is identified by a direct address from the internal RAM locations.
• PUSH DPL
• POP 40H
XCH
Exchange accumulator and a byte operand
• XCH A, Rn
• XCH A, direct
• XCH A, @Ri
XCHD
Exchange lower digit of accumulator with the lower digit of the memory location specified.
• XCHD A, @Ri
• The lower 4-bits of the accumulator are exchanged with the lower 4-bits of the internal memory location identified
indirectly by the index register.
• The upper 4-bits of each are not modified.
• CLR C
SETB
• Set a bit or the CY flag.
• SETB A.2
• SETB C
CPL
• Complement a bit or the CY flag.
• CPL 40H; Complement bit 40 of the bit addressable memory
ORL / ANL
• OR / AND a bit with the CY flag.
Branching instructions:
The 8051 provides four different types of unconditional jump instructions:
Short Jump – SJMP
• Uses an 8-bit signed offset relative to the 1st byte of the next instruction.
9B)
Baud rate:
The baud rates in 8051 are programmable.
SBUF:
It is an 8-bit register used for serial communication.
For a byte data to be transferred via the TxD line:
Byte must be placed in the SBUF register.
Bytes are framed with the start and stop bits and transferred serially via the TxD line.
SBUF holds the byte of data when it is received by 8051 RxD line.
When the bits are received serially via RxD.
SCON:
It is an 8-bit register used to program the start bit, stop bit and data bits of data framing.
SM0 SM1 SM2 REN TB8 RB8 TI RI
TMOD register is loaded with the value 20H, indicating the use of timer 1 in mode 2 (8-bit auto- reload) to set baud rate. 2.
The TH1 is loaded with one of the values to set baud rate for serial data transfer. 3. The SCON register is loaded with the
value 50H, indicating serial mode 1, where an 8-bit data is framed with start and stop bits. 4. TR1 is set to 1 to start timer 1
5. TI is cleared by CLR TI instruction. 6. The character byte to be transferred serially is written into SBUF register. 7. The
TI flag bit is monitored with the use of instruction JNB TI, xx, to see if the character has been transferred completely. 8. To
transfer the next byte, go to step 5.
Write a program for the 8051 to transfer letter “A” serially at 4800 baud, continuously. Solution: MOV TMOD, #20H
;timer 1, mode 2 (auto reload) MOV TH1, #-6 ;4800 baud rate MOV SCON, #50H ;8-bit, 1 stop, REN enabled SETB TR1
;start timer 1 AGAIN: MOV SBUF, #”A” ;letter “A” to trtansfer HERE: JNB TI, HERE ;wait for the last bit CLR TI ;clear
TI for next char SJMP AGAIN ;keep sending A
10)A
The ARM instruction set can be divided into six broad classes of instruction:
Branch instructions
Data-processing instructions on page
Status register transfer instructions on page
Load and store instructions on page
Coprocessor instructions on page
Exception-generating instructions on page.
Branch Instructions:
The B (branch) instruction is the basic mechanism in ARM for changing the flow of
control. The address that is the destination of the branch is often called the branch target.
Branches are PC-relative—the branch specifies the offset from the current PC value to the branch target. The offset is in
words, but because the ARM is byte addressable, the offset is multiplied by four (shifted left two bits, actually) to form a
byte address. Thus, the instruction B #100 will add 400 to the current PC value.
There are also branch instructions which can switch instruction set, so that execution continues at the branch target using
the Thumb instruction set. Thumb support allows ARM code to call Thumb subroutines, and ARM subroutines to return to
a Thumb caller. Similar instructions in the Thumb instruction set allow the corresponding Thumb → ARM switches.
Data-processing instructions on page
The data-processing instructions perform calculations on the general-purpose
Registers. There are five types of data-processing instructions:
Arithmetic/logic instructions
Comparison instructions
Single Instruction Multiple Data (SIMD) instructions
Multiply instructions on page
Miscellaneous Data Processing instructions on page.
Arithmetic/logic instructions:
The arithmetic or logical instructions is used to perform arithmetic or logical
operations. The source operands used here is two and the result is made to store
at the destination register. Based on the result the code flag condition will get updated. Of the two source operands:
One is always a register
The other has two basic forms:
an immediate value
a register value, optionally shifted.
The arithmetic operations perform addition and subtraction; the with-carry versions
include the current value of the carry bit in the computation.
ADD r0, r1, r2
This instruction sets register r0 to the sum of the values stored in r1 and r2.
In addition to specifying registers as sources for operands, instructions may also
provide immediate operands, which encode a constant value directly in the instruction. For example,
ADD r0, r1,#2 sets r0 to r1+2.
Comparison instructions:
The comparison instructions use the same instruction format as the
arithmetic/logic instructions. These perform an arithmetic or logical operation on two source operands, but do not write the
result to a register. They always update
the condition flags, based on the result. The source operands of comparison instructions take the same forms as those of
arithmetic/logic instructions, including the ability to incorporate a shift operation.
Comparison of Instruction and MOVE instruction in ARM processor: The compare instruction
CMP r0, r1 computes r0 – r1, sets the status bits, and throws away the result of the subtraction.
CMN uses an addition to set the status bits. TST performs a bit-wise AND on the operands, while TEQ performs an
exclusive-OR.
The instruction
MOV r0, r1 sets the value of r0 to the current value of r1.
The MVN instruction complements the operand bits (one’s complement) during the move.
Single Instruction Multiple Data (SIMD) instructions:
The add and subtract instructions treat each operand as two parallel 16-bit numbers,
or four parallel 8-bit numbers. They can be treated as signed or unsigned. The operations can optionally be saturating, wrap
around, or the results can be halved to avoid overflow. These instructions are available in ARMv6.
Multiply instructions on page:
There are several classes of multiply instructions, introduced at different times into the architecture.
Miscellaneous Data Processing instructions on page:
These include Count Leading Zeros (CLZ) and Unsigned Sum of Absolute
Differences with optional Accumulate (USAD8 and USADA8).
Status register transfer instructions:
The status register transfer instructions transfer the contents of the CPSR or an SPSR
to or from a general-purpose register. Writing to the CPSR can:
Set the values of the condition code flags
Set the values of the interrupt enable bits
Set the processor mode and state
Alter the endianness of Load and Store operations.
Load and store instructions:
Load-Store instructions are used to transfer the Values between registers and memory.
LDRB and STRB load and store bytes rather than whole words, while LDRH and
SDRH operate on half-words and LDRSH extends the sign bit on loading.
For example: LDR r0,[r1],STR r0,[r1]
An ARM address may be 32 bits long. The ARM load and store instructions do not
directly refer to main memory addresses, since a 32-bit address would not fit into an instruction that included an opcode
and operands. Instead it uses Register Indirect Addressing.
The following load and store instructions are available:
Load and Store Register
Load and Store Multiple registers on page
Load and Store Register Exclusive on page.
There are also swap and swap byte instructions, but their use is deprecated in
ARMv6. It is recommended that all software migrates to using the load and store register exclusive instructions.
Load and Store Register:
Load Register instructions can load a 64-bit double word, a 32-bit word, a 16-
bit half word, or an 8-bit byte from memory into a register or registers. Byte and half word loads can be automatically zero-
extended or sign-extended as they are loaded. Store Register instructions can store a 64-bit double word, a 32-bit word, a
16-bit half word, or an 8-bit byte from a register or registers to memory.
Load and Store Register instructions have three primary addressing modes, all of which use a base register and an offset
specified by the instruction:
• In offset addressing, the memory address is formed by adding or subtracting an offset to or from the base register value.
• In pre-indexed addressing, the memory address is formed in the same way as for
offset addressing. As a side effect, the memory address is also written back to the base register.
• In post-indexed addressing, the memory address is the base register value. As a side effect, an offset is added to or
subtracted from the base register value and the result is written back to the base register.
Load and Store Multiple registers :
Load Multiple (LDM) and Store Multiple (STM) instructions perform a block
transfer of any number of the general-purpose registers to or from memory. Four addressing modes are provided:
Pre-increment
Post-increment
Pre-decrement
Post-decrement
Load and Store Register Exclusive:
These instructions support cooperative memory synchronization. They are designed to provide the atomic behaviour
required for semaphores without locking all system resources between the load and store phases.
Register indirect Addressing:
Register indirect addressing is defined as that the address which will be used by the
instruction (known as the "effective address") is taken from the contents of a register, rather than being encoded directly
within the instruction itself (which is "absolute" addressing).Here the value stored in the register is used as the address to be
fetched from memory; the result of that fetch is the desired operand value.
Coprocessor instructions:
There are three types of coprocessor instructions:
Data-processing instructions
These start a coprocessor-specific internal operation.
Data transfer instructions
These transfer coprocessor data to or from memory. The address of the transfer is calculated by the ARM processor.
Register transfer instructions
These allow a coprocessor value to be transferred to or from an ARM register, or apair of ARM registers.
Exception-generating instructions:
Two types of instruction are designed to cause specific exceptions to occur.
Software interrupt instructions
SWI instructions cause a software interrupt exception to occur. These are normally
used to make calls to an operating system, to request an OS-defined service. The exception entry caused by a SWI
instruction also changes to a privileged processor mode. This allows an unprivileged task to gain access to privileged
functions, but only in ways permitted by the OS.
Software breakpoint instructions
BKPT instructions cause an abort exception to occur. If suitable debugger software is
installed on the abort vector, an abort exception generated in this fashion is treated as a breakpoint. If debug hardware is
present in the system, it can instead treat a BKPT instruction directly as a breakpoint, preventing the abort exception from
occurring.
10)B
The top–downdesign will begin with the most abstract description of the system and
conclude with concrete details. The alternative is a bottom–up view in which we start with components to build a system.
Bottom–up design steps are shown in the figure as dashed-line arrows. We need bottom–up design because we do not
have perfect insight into how later stages of the design process will turn out.
Decisions at one stage of design are based upon estimates of what will happen later: How fast can we make a particular
function run? How much memory will we need? How much system bus capacity do we need? We also need to consider the
major goals of the design.
Manufacturing cost.
Performance (both overall speed and deadlines); and
Power consumption.
We must also consider the tasks we need to perform at every step in the design process. At each step in the design, we
add detail:
We must analyze the design at each step to determine how we can meet the
Specifications.
We must then refine the design to add detail.
We must verify the design to ensure that it still meets all system goals, such as cost, speed and so on. Requirements
Clearly, before we design a system, we must know what we are designing. The initial
stages of the design process capture this information for use in creating the architecture and components.
We generally proceed in two phases: First, we gather an informal description from the customers known as requirements,
and we refine the requirements into a specification that contains enough information to begin designing the system
architecture.
Separating out requirements analysis and specification is often necessary because of the large gap between what the
customers can describe about the system they want and what the architects need to design the system.
Consumers of embedded systems are usually not themselves embedded system designers or even product designers.
Their understanding of the system is based on how they envision users’ interactions with the system. They may have
unrealistic expectations as to what can be done within their budgets; and they may also express their desires in a language
very different from system architects’ jargon.
Capturing a consistent set of requirements from the customer and then massaging those requirements into a more formal
specification is a structured way to manage the process of translating from the consumer’s language to the designer’s.
Requirements may be functional or nonfunctional. We must of course capture the basic functions of the embedded
system, but functional description is often not sufficient.
Typical nonfunctional requirements include:
Performance: The speed of the system is often a major consideration both for the usability of the system and for its
ultimate cost. As we have noted, performance may be a combination of soft performance metrics such as approximate time
to perform a user-level function and hard deadlines by which a particular operation must be completed.
Cost: The target cost or purchase price for the system is almost always a consideration.
Cost typically has two major components: manufacturing cost includes the cost of components and assembly;
nonrecurring engineering (NRE) costs include the personnel and other costs of designing the system.
Physical size and weight: The physical aspects of the final system can vary greatly depending upon the application. An
industrial control system for an assembly line may be designed to fit into a standard-size rack with no strict limitations on
weight. A handheld device typically has tight requirements on both size and weight that can ripple through the entire
system design.
Power consumption: Power, of course, is important in battery-powered systems and is often important in other
applications as well. Power can be specified in the requirements stage in terms of battery life—the customer is unlikely to
be able to describe the allowable wattage.
Validating a set of requirements is ultimately a psychological task since it requires
understanding both what people want and how they communicate those needs.
The mock-up may use canned data to simulate functionality in a restricted demonstration, and it may be executed on a
PC or a workstation. But it should give the customer a good idea of how the system will be used and how the user can react
to it.
Physical, nonfunctional models of devices can also give customers a better idea of characteristics such as size and
weight.
Sample requirements form.
Name Purpose Inputs Outputs Functions Performance
Manufacturing cost
Power
Physical size and weight
Requirements analysis for big systems can be complex and time consuming. However, capturing a relatively small
amount of information in a clear, simple format is a good start toward understanding system requirements.
To introduce the discipline of requirements analysis as part of system design, we will use a simple requirements
methodology.
We can use the requirement form as a checklist in considering the basic characteristics of the system.
Name: This is simple but helpful. Giving a name to the project not only simplifies talking about it to other people but
can also crystallize the purpose of the machine.
Purpose: This should be a brief one- or two-line description of what the system is supposed to do. If you can’t describe
the essence of your system in one or two lines, chances are that you don’t understand it well enough.
Inputs and outputs: These two entries are more complex than they seem. The inputs and outputs to the system
encompass a wealth of detail:
Types of data: Analog electronic signals? Digital data? Mechanical inputs?
Data characteristics: Periodically arriving data, such as digital audio samples? Occasional user inputs? How many bits
per data element?
Types of I/O devices: Buttons? Analog/digital converters? Video displays?
Functions: This is a more detailed description of what the system does. A good way to approach this is to work from the
inputs to the outputs: When the system receives an input, what does it do? How do user interface inputs affect these
functions?
Performance :embedded computing systems spend at least some time controlling physical devices or processing data
coming from the physical world. In most of these cases, the computations must be performed within a certain time frame. It
is essential that the performance requirements be identified early since they must be carefully measured during
implementation to ensure that the system works properly.
Manufacturing cost: This includes primarily the cost of the hardware components. Even if you don’t know exactly how
much you can afford to spend on system components, you should have some idea of the eventual cost range. Cost has a
substantial influence on architecture: A machine that is meant to sell at $10 most likely has a very different internal
structure than a $100 system.
Power: Similarly, you may have only a rough idea of how much power the system can consume, but a little information
can go a long way. Typically, the most important decision is whether the machine will be battery powered or plugged into
the wall. Battery-powered machines must be much more careful about how they spend energy.
Physical size and weight: You should give some indication of the physical size of the system to help guide certain
architectural decisions. A desktop machine has much more
flexibility in the components used than, for example, a lapel mounted voice recorder.
11)
Assembly and linking are the last steps in the compilation process they turn a list of instructions into an
image of the program’s bits in memory.
Loading actually puts the program in memory so that it can be executed.
The compilation process is often hidden from us by compilation commands that do everything required to
generate an executable program.
As the figure shows, most compilers do not directly generate machine code, but instead create the
instruction-level program in the form of human-readable assembly language.
Generating assembly language rather than binary instructions frees the compiler writer from details
extraneous to the compilation process, which includes the instruction format as well as the exact
addresses of instructions and data.
The assembler’s job is to translate symbolic assembly language statements into bit-level representations
of instructions known as object code. T
The assembler takes care of instruction formats and does part of the job of translating labels into
addresses.
However, since the program may be built from many files, the final steps in determining the addresses of
instructions and data are performed by the linker, which produces an executable binary file.
That file may not necessarily be located in the CPU’s memory, however, unless the linker happens to
create the executable directly in RAM. The program that brings the program into memory for execution is
called a loader.
The simplest form of the assembler assumes that the starting address of the assembly language program
has been specified by the programmer. The addresses in such a program are known as absolute addresses.
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.
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.