Hardware Reference
In-Depth Information
Andy
Anton
Cathy
Dick
Erik
Frances
Frank
Gerrit
Hans
Henri
Jan
Jaco
Maarten
Reind
Roel
Willem
Wiebren
14025
31253
65254
54185
47357
56445
14332
32334
44546
75544
17097
64533
23267
63453
76764
34544
34344
0
4
5
0
6
3
3
4
4
2
5
6
0
1
7
6
1
Hash
table
(a)
Linked table
Andy
14025
0
Maarten
23267
Dick
54185
Reind
63453
1
Wiebren
34344
Henri
75544
2
Frances
56445
Frank
14332
3
Hans
44546
Gerrit
32334
Anton
31253
4
Jan
17097
Cathy
65254
5
Jaco
64533
Willem
34544
Erik
47357
6
Roel
76764
7
(b)
Figure 7-11.
Hash coding. (a) Symbols, values, and the hash codes derived from
the symbols. (b) Eight-entry hash table with linked lists of symbols and values.
The first step is performed by the compiler or assembler and the second one is per-
formed by the linker.
The translation from source procedure to object module represents a change of
level because the source language and target language have different instructions
and notation. The linking process, however, does not represent a change of level,
since both the linker's input and the linker's output are programs for the same vir-
tual machine. The linker's function is to collect procedures translated separately
and link them together to be run as a unit called an
executable binary program
.
On Windows systems, the object modules have extension
.obj
and the executable
binary programs have extension
.exe.
On
UNIX
, the object modules have extension
.o
; executable binary programs have no extension.
Compilers and assemblers translate each source file separately for a very good
reason. If a compiler or assembler were to read a series of source procedures and
immediately produce a ready-to-run machine language program, changing one
