Re: [Sbcl-devel] Re: Cold building PCL

[<ger...@t-...>]

Christophe Rhodes <cs...@ca...> writes:

> > So, PCL effectively bootstraps in the cold core.  Or so it seems; I'm
> > not sure if I'm not overlooking something crucial.  All input welcome.
> > 
> > Also not clear to me is how to proceed from here.  Hm...
> 
> Well, what this suffers from is that it still goes through the whole
> bootstrap procedure, even though it doesn't need to.  In CMUCL terms,
> you know enough about the class hierarchy not to need *EARLY-CLASSES*
> and whatnot, because you can just interrogate the running lisp about
> them instead.  That way, I submit (and I can do this because this is
> sbcl-devel :-) lies pain, because if you do get it building by using
> its host to query for information, then to make changes you again have
> to do bootstrap voodoo like for incompatible changes to defstruct
> :-)

Yep, which is why I would like to keep bootstrapping PCL.  It's an
interesting problem once compiler and world use PCL, and PCL uses
world and compiler.  Not easy :).

> Now, the difference between that approach and what I'm trying to do is
> that the two-pass system allows us to build up the information we need
> in the sbcl-as-application system to be able to construct the relevant
> initialization forms for the cold core to execute.
> 
> To make this slightly more concrete: at the moment, on
> pcl_build_1_branch, we build defclass.lisp and defs.lisp in the cold
> build procedure, so that when we get our cold-sbcl.core it has in it a
> variable *EARLY-CLASS-DEFINITIONS* which contains the early class
> definitions you would expect to see.

I've thought of something like that for the case of avoiding
cold-bootstrapping PCL.  Basically, teach genesis how to write out the
state of a fully-bootstrapped PCL and initialize a cold PCL from that
information.  That should be, maybe very roughly, equivalent to what
you are doing, I think.

Also not exactly easy to do.

> If I could get as far as including braid.lisp in the cold core, rather
> than causing BOOTSTRAP-META-BRAID to happen at (effective) braid.lisp
> load time, I could cause it to happen earlier, by dumping a suitable
> !cold-init-form function that would execute before the ordinary
> top-level forms.  Doing that would mean that, by the time the ordinary
> top-level forms (from effective loads of files) run, the fundamental
> kernel classes already exist.  So that would mean that effectively,
> the defclass machinery would be set up and ready even for files early
> in the load.
> 
> Do you see what I'm driving at?  

I think so.  You are aiming at building a class tree only in a first
step, which I think should work with BOOTSTRAP-META-BRAID, provided
all classes in the tree are suitable recorded in some way.

> Basically, I think with my way (or the hacky CMUCL way) it ought to
> be possible to remove the need for *BOOT-STATE*'s existence -- in
> the CMUCL philosophy by querying the running CLOS for the
> information it needs; in the SBCL worldview by using the information
> built up while building the cross-compiler...

In a way, I can do that already with #+COLD-PCL, with the usual boot
files that might be necessary to get from one version to another.
I think I could cold-load fasls from a #+COLD-PCL build and have
something in the cold core that basically doesn't need to be
bootstrapped.

Problem---lots of work and hair in getting the dynamic state
reconstructed.  But it could well be that this is the only way to get
CLOS into the world.

Or, maybe it's possible, say by precompiling what's needed, to make
PCL usable enough and early enough for the compiler and world to use
it, and at the same time prevent PCL from calling other parts that are
not yet up and running.  I don't know.