On Sun, Dec 17, 2000 at 06:31:00PM -0500, Nathan Froyd wrote:
> On Sun, Dec 17, 2000 at 03:59:51PM -0600, William Harold Newman wrote:
> > It's my understanding that the main advantage of having an interpreter
> > was that people could work with the system even when their machines
> > were too small to install the compiler. Today, no one's very
> > interested in that, and I think it may be unsupported even in CMU CL.
> > (It's certainly unsupported in SBCL.)
> > Memory pressures still matter today, of course, but that doesn't
> > necessarily work in favor of the IR1 interpreter. Deleting the IR1
> > interpreter is mostly nice because it cleans up the source code, but
> > as a little bonus, it will also shrink the compiled system. And
> > another interpreter-related cleanup that I'd like to do shortly after
> > the IR1 interpreter is gone, i.e. straightening out the bootstrapping
> > issues so that the byte interpreter can run at cold init time so that
> > system code can be byte compiled, should shrink the system a lot. I
> > hope that the 0.7.x sbcl.core files can be be about 50% smaller than
> > the 0.6.x ones.
> My understanding of this and the previous parts of your message is that
> there are two different interpreters in CMUCL/SBCL: the IR1 interpreter
> and the bytecode interpreter (for .x86f files). You talk about ripping
> out the IR1 interpreter and letting IR1 be simply for compilation. What
> is there to replace it? Does there exist a separate interpreter (yet
> another one) somewhere?
> This looks like an awfully big system and I'm getting a little bit
> confused. Admittedly, I haven't read much of the documentation yet, but
> I have the following sense of things:
> * the repl grabs lisp input from the user, converts it to IR1
> * this icky IR1 interpreter evaluates it and returns the result.
> * bytecode is generated as a result of COMPILE-FILE
> * bytecode gets loaded as a result of LOAD and such
> Is this more or less correct? Am I missing any fine details as to why
> nuking the IR1 interpreter would or would not cause problems? Where
> does the fable native-code generation come in?
The REPL calls EVAL. Currently EVAL is implemented by sharing
IR1-producing code with the compiler, then interpreting the IR1.
When I nuke the IR1 interpreter, then EVAL will look more like
(DEFUN EVAL (FORM)
(FUNCALL (COMPILE NIL `(LAMBDA () ,FORM))))
although it won't be quite this simple, since it needs to
call MACROEXPAND and check for EVAL-WHEN, and since it's probably
worth handling some simple cases specially without calling
the compiler. As far as I can see, the only real problem caused
by nuking the IR1 interpreter is that this EVAL will be slower
than the current one, since COMPILE does not only IR1 conversion
but also translation into (native or byte) code. Since I've
never run across a good reason to run EVAL in a bottleneck
of your code, I don't think this will be important.
COMPILE and COMPILE-FILE ordinarily generate native code, not byte
code. Call DISASSEMBLE on a function and see. (Also see that the
native code contains a lot of extra loads and stores, alas.) Byte
code is generated if you declare (OPTIMIZE (SPEED 0)).
William Harold Newman <william.newman@...>
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C