Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
From: William Harold Newman <william.newman@ai...> - 2001-09-24 00:27:14
In the rewrite of the EVAL-WHEN/DEFSTRUCT/DEFUN mess going on in
flaky5_branch, I've done a fair amount of work on the compiler so that
it can emit ordinary functions directly, without the
FUNCTIONAL-KIND=:TOP-LEVEL wrappers which were always used before.
(As an example of what I'm talking about: The old implementation of
CL:COMPILE wouldn't ask the compiler for the address of the function
it was about to return, but would instead (1) ask the compiler for the
address of a :TOP-LEVEL function, (2) call the :TOP-LEVEL function,
and (3) return the result returned by the :TOP-LEVEL function.
The new code skips the three-step process, and lets the compiler
skip the generation of the little :TOP-LEVEL stub, instead just asking
the compiler for the function which is to be returned.)
I forced my way through bootstrapping with this, and it seem to work
OK, although there are still some known oddities about where debugging
information ends up and there are probably some other new bugs that I
haven't noticed. I think in the long term my changes should be an
improvement, since I think I'll be able to get rid of the :TOP-LEVEL
case completely, and since we don't need to generate useless confusing
:TOP-LEVEL stub code. But..
I've run into problems making this change in the byte compiler, and
I've become unmotivated to fix them. The way that the byte compiler
implicitly depends on FUNCTIONAL-KIND in various weird ways, and the
other stuff that I've seen about how much fun it is to understand,
debug, and maintain it, have really reduced my motivation to try to
deal with it. So, since we had a discussion a while ago on the list
and there were no very strong reasons to keep it, I've pretty much
decided to get rid of it.
If anyone has any compelling reasons to keep it, please speak up soon.
Otherwise, it dies, and if there turns out to a big need for a byte
compiler in the future, it would be possible either to resurrect the
current one, or just to write a byte-code backend for the main
compiler, partly from scratch and partly using the existing old byte
compiler as a model.
Currently my work on flaky5_branch is proceeding on the assumption
that the byte compiler will go away.
William Harold Newman <william.newman@...>
`I wanted to be a fascist dictator, but it's hard getting an interview
without the experience. I thought network management would be
a good stepping stone.' --- Robert Franklin
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C