On Thu, Feb 21, 2002 at 07:41:03PM +0000, Christophe Rhodes wrote:
> Firstly, the first patch; it removes :gencgc from
> base-target-features, and adds it in local-target-features if
> sbcl_arch is x86. This might save future porters some pain, unless we
> get a whole new gc implementation by then :)
That looks good to me. I'm presently fiddling with trying to get
SBCL to catch stack overflow, so my local copy is a little unstable
right now, but as soon as it's behaving (maybe the next build,
maybe not:-) I'll probably merge it.
> The second patch should not be applied, I think; it doesn't work, but
> I'm using it to try to explain what I want to do. What I would like is
> to set sb!c:*backend-subfeatures* to some value that is not nil for
> the duration of make-host-2, so that the core is built with
> optimizations for the specified subfeatures; also, the resulting core
> should have those subfeatures in sb-c:*backend-subfeatures*.
> My understanding of the various package-juggling isn't terribly clear,
> but I suspect the attached patch does the former but not the latter,
> and what I actually want is
> (defvar *backend-subfeatures* #.sb-cold:*backend-subfeatures*)
> at the definition point and to set up sb-cold:*b-s* via the customizer
> mechanism. Is that more likely to work?
I'm not sure exactly what you're trying to do. I take it from the
patch that the "customizer mechanism" is the new
customize-backend-subfeatures.lisp file, analogous to the current
The package juggling involved in SB-C stuff isn't too
complicated, I think. At compile time, SB-C is the xc host, if the xc
host is SBCL, and otherwise SB-C just doesn't exist. At compile time,
SB!C is target stuff. After genesis, the host stuff is left behind. In
warm init, warm.lisp, we rename every package SB!FOO to SB-FOO.
So if you just set up your sb!c:*backend-subfeatures* list in some
src/compiler/*.lisp file which is built as part of the cross-compiler
and then cross-compiled as part of the target compiler, it should
work, I think. As long as you want the same values at xc time
and as the default in the target Lisp, it's even straightforward.
(The really complicated package juggling is not in SB!C or other
implementation-only packages, but in the CL package, which has to be
shared with the xc host, and sort of shadowed by the SB-XC package
which holds target-related definitions; and then in various hacks to
control out which one should be used in macroexpanders and so forth.
There's not nearly so much ambiguity and confusion for the other
> --- make-host-2.sh 7 Feb 2002 20:37:52 -0000 1.16
> +++ make-host-2.sh 21 Feb 2002 17:20:12 -0000
> @@ -85,6 +85,15 @@
> (set-macro-character #\, #'sb!impl::comma-macro)
> ;; Control optimization policy.
> + (setf sb!c:*backend-subfeatures*
> + ;; FIXME: cut'n'pasted (kinda) from shared.lisp
> + (let* ((default-subfeatures nil)
> + (customizer-file-name "customize-backend-subfeatures.lisp")
> + (customizer (if (probe-file customizer-file-name)
> + (compile nil
> + (read-from-file customizer-file-name))
> + #'identity)))
> + (funcall customizer default-subfeatures)))
> ;; Specify where target machinery lives.
> (with-additional-nickname ("SB-XC" "SB!XC")
> (funcall fn))))
Besides doing this in make-host-2.lisp, it looks to me as though you'd
need some sort of mechanism for propagating your preferred
*BACKEND-SUBFEATURES* value into the target Lisp. if you wanted to do
it by incrementally modifying your patch, you could add something like
(untested, possibly somewhat wrong)
;; Propagate xc-time *B-S* value (set up by various magic in
;; make*.sh files) into target compiler as its default.
(setf *backend-subfeatures* '#.*backend-subfeatures*)
in cold init or in toplevel code executed somewhere before the target
compiler is run.
Another possibility would be not to use make-host-2.sh to set up
*BACKEND-SUBFEATURES*, but instead use (probably) make-config.sh to
generate a default-backend-subfeatures.lisp-expr file, and then load
that file into *BACKEND-SUBFEATURES* using SB-COLD:READ-FROM-FILE,
more or less the way that the existing code works with other
externally generated or shared data, like version.lisp-expr or
early-defstruct-args.lisp-expr. I think with this DEFVAR in
early-c.lisp or someplace like that, things would tend to just work
(assuming that having the same defaults at xc time and in the target
really is always the right thing, which seems likely but not certain).
William Harold Newman <william.newman@...>
"Look on my works, ye Mighty, and despair!" -- Ozymandias, King of Kings
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C