(moving to sbcl-devel an ongoing conversation about how to put
PCL into cold init)
On Wed, Feb 26, 2003 at 02:35:25AM +0100, Gerd Moellmann wrote:
> Christophe Rhodes <csr21@...> writes:
> > This rationalization should mean that things such as
> > EARLY-GENERIC-FUNCTION can go away, maybe being replaced by some
> > fixups to run during what we call "cold init" -- the initial function
> > of the cold-sbcl.core is something that starts off by making package
> > structures, setting up handlers for this and that, running top-level
> > forms and the like; only after all this does the compiler start doing
> > "warm load" -- the alternative is that we could do some make-load-form
> > magic on e.g. host generic functions to dump them as target
> > structures, but that seems scary.
> Is cold-sbcl.core the "cross compiler"? I mean the compiler built
> by the host Lisp from sbcl sources?
* "the cross compiler" = Python running as an application in the
host Lisp, reading .lisp files and writing .fasl files (which are
to be executed on the target Lisp)
* cold-sbcl.core = what's written by GENESIS (itself running as an
app in the host Lisp) after reading the .fasl files written
by the cross-compiler; machine code and data for the target Lisp
* "cold init" = what happens when cold-sbcl.core is loaded for the
first time. Lots of fundamental setup gets done at this time, and
until it's done the system is very incomplete and fragile. When
it's done the system is mature enough to give you a REPL, though
it's still missing some pieces which are set up in warm init.
* "warm init" = doing (LOAD "src/cold/warm.lisp") in the bare-bones
system which was created by cold init. Each file is compiled using
target Lisp system's compiler, then LOADed after it is compiled.
Then after warm init, we write out the final sbcl.core which is used
for ordinary operation.
Historically PCL has been compiled and LOADed in warm init. We'd like
to process it earlier now, so that its .lisp files are compiled by the
cross-compiler, its .fasl files are read by GENESIS, its code is
written into cold-sbcl.core, and its initialization is done at cold
> In a way CMUCL's way of building has its advantages (and ducks) :).
> Until it comes to changing something in incompatible ways, of
Yes, on both counts. It's an acute headache arranging for everything
to be built from scratch in a valid bootstrap order each time you
build the system, instead of just filling in the not-built-yet pieces
with whatever old code happens to be in place from the last time you
compiled. But once you've made the arrangements once, now your source
has a straightforward blueprint-like relationship to the target code,
and every compile/bootstrap cycle is a sort of flag day for all the
software components, just as in ordinary (non-Lisp, non-Smalltalk)
software systems. Et voila, you longer have chronic headaches
associated with trying to make code from some older version
interoperate with new incompatible code in complicated ways (which
presumably were, in the interests of avoiding acute headaches,
incompletely specified and incompletely understood:-).
William Harold Newman <william.newman@...>
"Build a man a fire, and he'll be warm for a day. Set a man on fire,
and he'll be warm for the rest of his life." -- Terry Pratchett
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C