[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Lucid 3.0.2 Optimization botch
- To: Jon L White <firstname.lastname@example.org>
- Subject: Re: Lucid 3.0.2 Optimization botch
- From: Gregor.pa@Xerox.COM
- Date: Mon, 22 May 89 09:52 PDT
- Cc: egdorf%zaphod@LANL.GOV, CommonLoops.pa@Xerox.COM
- Fcc: BD:>Gregor>mail>outgoing-mail-6.text.newest
- In-reply-to: <8905161245.AA25471@bhopal>
- Line-fold: no
- Reply-to: <Gregor.pa@Xerox.COM>
Date: Tue, 16 May 89 05:45:56 PDT
From: Jon L White <email@example.com>
The more desirable thing to do is to put the whole "dcode" down one
more level of indirection through the symbol-function cell of the
generic functon. This is effectively what PCL's 'make-trampoline'
function does, but unfortunately that is not a very efficient approach
when you consider how most compilers will compile it. Something akin
to the "mattress-pads" in John Foderaro's code (in the fin.lisp file)
could probably be done for many other implementations as well. I don't
know who wrote the Lucid specific parts of fin.lisp, but I can supply
the Lucid-specific code sequences of corresponding "mattress-pad"'s for
several machines to anyone who wants to give it a try.
If you rewrite the Lucid part of FIN to do this mattress-pad stuff then
I can install it in PCL and fix this longstanding problem.
Just doing the tail-recursive exit will probably make the matter
essentially moot for all practical purposes.
The problem crops up all the time here for people using PCL in Lucid