1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
|
% This file is part of Oaklisp.
%
% This program is free software; you can redistribute it and/or modify
% it under the terms of the GNU General Public License as published by
% the Free Software Foundation; either version 2 of the License, or
% (at your option) any later version.
%
% This program is distributed in the hope that it will be useful,
% but WITHOUT ANY WARRANTY; without even the implied warranty of
% MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
% GNU General Public License for more details.
%
% The GNU GPL is available at http://www.gnu.org/licenses/gpl.html
% or from the Free Software Foundation, 59 Temple Place - Suite 330,
% Boston, MA 02111-1307, USA
\chapter{Bootstrapping}
In this chapter we describe new versions of Oaklisp are created.
Essentially, the process is quite similar to the way in which a C
program is created. First the Oaklisp source files which make up the
\emph{cold world load} are compiled to produce object files. Then a
linker, originally written in T but now an Oaklisp program, takes
these object files and lays them all out in memory, resolving
references to global variables and laying out quoted constants refered
to in the code. The linker also puts a map of where it allocated
various globals and such in memory. At this point, the cold world
(named \df{oaklisp.cold}) is booted, and the files that the linker
layed out in memory are thereby executed, sequentially. These files
gradually build all the infrastructure required for a full Oaklisp
world. The first files are written at an extremely low level, and
make things like \df{make} and \df{cons} work. Later files bring up
more advanced constructs, until finally there is enough for object
files to be loaded. At this point the world is dumped to
\df{oaklisp.ol}, and then this world is booted and has files loaded
into it using the normal file loading mechanisms until the full
Oaklisp world, \df{oaklisp.olc}, is built.
The formats of these files is very simple. They contain a header
which gives the length of the various segments and the values of some
registers. This is followed by a memory image, with pointers given as
offsets from the beginning of the image. This is followed by the weak
pointer table.
The cold world is in a hexidecimal format, with each reference
represented as a space followed by a sequence of hexidecimal digits.
Carriage returns may optionally preceed spaces. Actually, the space
referred to above can be either a space character or the \upar\
character. The later indicates that the following reference contains
bytecodes. Since bytecodes are ordered differently depending on the
endianity of the machine, the hex format world loader swaps the two
instructions on little endian machines but not on big endian machines.
This keeps the cold load file independent of endianity.
The warm world loads are in a binary format and are not independent
of endianity. For this reason, warm world extensions start with
\df{.ol} for big endian versions and \df{.lo} for little endian
versions. The emulator replaces the characters \texttt{\%\%} in the
command line file argument (or the default world in \df{config.h})
with either \texttt{ol} or \texttt{lo}, depending on whether
\df{BIG\protect\_ENDIAN} is defined.
To make Oaklisp dump itself upon exiting use the \dfsw{-d} \dfsw{-b}
switches when invoking Oaklisp. After Oaklisp has exited, the
emulator will prompt for a filename to dump the world image to, unless
this filename has been provided with the \dfsw{-f}~\emph{filename}
switch. Usually the \dfsw{-G} switch is also given when the world is
being dumped.
|
