Re: Interpreters and computationally intensive programs

kendall@centerline.com (Sam Kendall) writes:


      ...a practical interpreter allows the mixing of interpreted and
      compiled code. An ideal interpreter ... allows you to swap
      between interpreted and compiled code in the middle of execution,
      so that you can execute at full speed for a while, then swap some
      of your program into interpreted code, then continue executing.
      This assumes that interpreted execution gives you some benefit,
      such as better debugging, runtime checking, or exact arithmetic (as
      in the following citation).


This sort of mixing was supported in the most Lisp systems and in
particular the PDP-6 Lisp interpreter (late 60's) and its descendents
(Maclisp, BBN Lisp, Interlisp, etc.) starting in 1970 or earlier. For
example, the Macsyma system was run compiled (where some checks were
turned off) for speed, but when a bug was discovered, the developer could
override the compiled code with interpreted code, on a procedure-by-
procedure basis. Other Lisp-influenced systems also handled this
correctly (ECL, Muddle, ...). The current Emacs-Lisp system has three
forms of code: Lisp (interpreted tree), byte-compiled (interpreted
byte-encoded stack machine), and C code. Lisp and byte-compiled code are
completely compatible (although you could say that that's not really
compilation). There is currently no Lisp-to-C (and on to machine
language) compiler as far as I know, but I see no reason there couldn't
be. Main problem would be loading...


To respond to the consistency issue, yes, in Maclisp etc. there were some
bugs caused by differences in semantics between compiled and interpreted
code. The most egregious difference was the handling of scope of free
variables. At the time, it was thought that complete consistency would
cost too much. Things have improved since.


-s
--

Return to the comp.compilers page.
Search the comp.compilers archives again.