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)
|