From: Christophe R. <cs...@ca...> - 2003-02-27 19:53:44
|
Gerd Moellmann <ger...@t-...> writes: > The idea behind this was that executing the various PCL stuff in > *LISP-INITIALIZATION-FUNCTIONS* in %INITIAL-FUNCTION in sequence > should correspond roughly to what happens when PCL is bootstrapped in > a normal build, where one file after the other is compiled and > immediately afterwards loaded. Yes. That's the essential idea. > 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 :-) 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. 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? 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... Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) |