Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!uwvax!ai!neves
From: neves@ai.WISC.EDU (David M. Neves)
Newsgroups: comp.emacs
Subject: Re: GNU Emacs performance
Message-ID: <3668@spool.WISC.EDU>
Date: Tue, 9-Jun-87 14:55:55 EDT
Article-I.D.: spool.3668
Posted: Tue Jun  9 14:55:55 1987
Date-Received: Fri, 12-Jun-87 04:05:59 EDT
References: <8706091546.AA01577@icst-cmr.arpa.ARPA>
Sender: news@spool.WISC.EDU
Reply-To: neves@ai.WISC.EDU (David M. Neves)
Distribution: world
Organization: U of Wisconsin CS Dept
Lines: 19

> 
>?   2.  Lisp code.  Significant parts of the GNU functionality is written
>?       in LISP.  Unfortunately, the LISP is interpreted, not compiled.
>Semi-true. The `lisp' is `compiled' but not to machine code. So while
>the `compiled lisp' *is* interpreted, all the parentheses and symbol
>scanning/lookups have been done. It is much like emulating another 
>machines assembly language by `executing' the `object code'.
I believe a more accurate analogy would be to Pascal's P-code.  GNU
emacs compiles down to a pseudo code of an abstract stack machine
which is then interpreted.  

"all the parentheses and symbol ..."  This scanning occurs during
reading of Lisp s-expressions, not during execution or compilation.
When an s-expression is read in from a file it is turned into a binary
tree structure with leaf nodes as pointers to atoms (not strings!).
Parentheses do not exist in this internal representation.
David Neves, Computer Sciences Department, University of Wisconsin-Madison
Usenet:  {allegra,heurikon,ihnp4,seismo}!uwvax!neves
Arpanet: neves@cs.wisc.edu