From: Christophe R. <cs...@ca...> - 2002-05-16 23:48:34
|
On Thu, May 16, 2002 at 06:29:45PM -0500, William Harold Newman wrote: > On Thu, May 16, 2002 at 11:44:08PM +0100, Christophe Rhodes wrote: > > On Thu, May 16, 2002 at 10:28:32AM -0500, William Harold Newman wrote: > > > The only troubling thing thing I noticed was DEFAULT-INIT-CHAR, since > > > I was worried about dumping it anyway, and making it a > > > CHARACTER-valued constant defined early makes me worry more. But > > > fortunately, DEFAULT-INIT-CHAR isn't used anywhere any more, so the > > > whole thing can be deleted: problem solved.:-) > > > > Good catch :) So if I adjust the patch to deal with non-x86 > > architectures and zap default-init-char, are you willing to live with > > the fact that defconstant-eqx doesn't use def!constant? I confess to not > > understanding what's going on there ("please, sir, may I leave? My brain > > is full.") -- the danger with putting it in as it is now is that no-one > > is motivated to fix it, though it has to be said that I personally would > > be happy to lose defconstant-eqx (replacing it with defparameter wrapped > > in appropriate eval-whens). > > Oops, I didn't catch that DEFCONSTANT-EQX would die. I should think > that in at least some cases, that would cause the performance > advantage to be reduced, because DEFCONSTANT-EQX is used to represent > lots of BYTE expressions, with the intent of allowing the compiler to > grok them at compile time and optimize the code which depends on them. It doesn't die, but nor does it use def!constant. The patch I posted doesn't touch defconstant-eqx -- it expands into a defcontstant (not def!constant) as before. So we still get the same behaviour regarding defconstant-eqx forms -- not defined as a target constant until target building. This is fine in the case of (defconstant-eqx some-byte (byte 3 3) #'equal) (def!constant some-byte-size (byte-size some-byte)) Because (I think) the host will have the definition of some-byte ready for when the def!constant form needs it, and then the def!constant form takes care of propagating the some-byte-size constantness to the cross-compiler. Where it loses is if the byte specifier itself is the important constant; then we get the "old" behaviour (some-byte will be treated by the cross-compiler as a global, not a constant, until the cross-compiler itself compiles this file). There's another problem with (byte x y) expression that I've run across in cross-compilation, though, and that's that the representation of (byte x y) is not specified by ANSI; in that respect, it may not make much sense to try to preserve identity of (byte x y) across the cross-compiler -- we may, in fact, need SB-XC:BYTE to cope with this. Another thing to think about, related to this latter issue and not to def!constant, is the make-load-form handling; I don't think that we would survive doing s/:just-dump-it-normally/:sb-just-dump-it-normally/ on our current sources -- I think we might need an SB-XC:MAKE-LOAD-FORM-SAVING-SLOTS, too... I still don't pretend to understand make-load-form, but that's the impression I get from reading openmcl compiler messages -- that make-host-2 tries to dump host make-load-form expressions into target fasls, which won't work in much the same way that host backquotes won't work, but is less trivially solved :-/ > Since your benchmarks show the performance loss for this in the > typical case isn't noticeable, you can still go ahead with the patch > if you like, but perhaps if you do you should do it by reimplementing > the DEFCONSTANT-EQX macro body in terms of DEFPARAMETER and EVAL-WHEN, > rather than immediately replacing all the DEFCONSTANT-EQX expressions > with DEFPARAMETER expressions. That wouldn't be ideal as a permanent > solution, of course, but as a temporary solution has the advantage of > making it easy to go either way (making the revised DEFCONSTANT robust > enough to do real DEFCONSTANT-EQX again, or replacing all > DEFCONSTANT-EQX calls with DEFPARAMETER) in the future. I'd aim not to touch defconstant-eqx, at least in the first instance, until I (or someone else :-) understands what's going on there. > > If that's OK, I'll prepare a revised patch and post it for a nod. > > suits me I'm on the case! Cheers, Christophe -- Jesus College, Cambridge, CB5 8BL +44 1223 510 299 http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar (str schar arg) (first (last +))) (make-dispatch-macro-character #\! t) (set-dispatch-macro-character #\! #\$ #'pling-dollar) |