Back when I was writing the emacs-lisp compiler, I considered adding an AppleSoft BASIC front-end for it that would directly emit emacs-VM bytecodes. Fortunately, I reconsidered.
However, I now demand that someone implement JavaScript in xscreensaver so that it can run 6502 demos.
I considered adding an AppleSoft BASIC front-end for it that would directly emit emacs-VM bytecodes
You're a good man for not doing it. We'd have to write an Emacs boot-virus if you had. But you're a bad, bad man for thinking it.
On the subject of the emacs-lisp compiler, is there a reason
quotedoesn't have a byte code? It's the most called non-byte-coded function on startup for me.Use 'sexp instead of (quote sexp).
I was talking about this, profiling results on startup from a recent XEmacs 21.5:
And if you look at
lread.c, 'whatever is effectively a macro that expands to(quote whatever).It's not a function, it's a special-form, which must be handled explicitly by both the compiler and interpreter. The interpreter must be doing something really dumb if it ever calls it as a function.
Well, maybe, but the interpreter appears to have always done it-I'm not sure what else it's supposed to do when handed a cons with
'quotein initial position.The 9,000 calls at startup are mostly a result of the autoload infrastructure--two calls to quote for each autoloaded function, three for each autoloaded macro-plus the byte-compilation boilerplate infrastructure (three calls per file). But this only comes to 6364 calls, comparing with
obarrayand theload-history; the rest appear to come from(defalias ...)and(provide ...)calls, which are more or less unavoidable, as I understand it.It doesn't make any sense that it's calling quote. It's not a function, it's a special form. If the interpreter called it like a function (eval'ed its arg) then... it wouldn't be quote. So it's obviously special-casing it, or nothing would work. Special-forms are the things that are left after you've expanded all the macros that can't be implemented as functions because they don't follow the funcall rules of argument evaluation (e.g., lambda, quote, if, or.)
(I refuse to go debug this for you. There are some things I just won't do. But I suspect that it's not really calling it, and whatever you used to generate those stats is wrong.)
It's not eval'ing its args. Here's the function:
I am reasonably sure putting a C breakpoint on
Fquoteand sayingleval "(backtrace)"is a sensible way of working this out.save-excursionand any number of other functions use UNEVALLED and have assigned byte-codes. Looks like I need to go code something and see what breaks."UNEVALLED" means "I am a special form, not a function."
The lisp interpreter engine treats C functions that are declared UNEVALLED very differently from normal functions. Here's the relevant code:
http://cvs.xemacs.org/viewcvs.cgi/XEmacs/xemacs/src/eval.c?annotate=1.95#3635
In particular, it doesn't do all the work to eval the args and setup a lisp frame, and the cost of the C function call is tiny.
When you byte-compile a function that has (quote x) or 'x, the byte-compiler knows to eliminate the quote. If you use M-x disassemble on the function, you'll probably see it's used the 'constant' bytecode.
However, an .elc file is not a pure-binary format. It's a sequence of eval-ed statements, and it probably has statements that look something like this:
(defalias 'foo #[nil "bytecode here" [symbol-table here]])
All the uses of 'foo are going to call the interpreter's (quote).
Since your profile data shows that the time spent in quote is much less than 0.5% of the total time, this is probably not worth worrying about.
That proportion was not to be trusted, it was a debug build. But happily, with optimisation, things look even better.
There are several other special forms with byte codes;
save-excursion,save-window-restriction,save-restrictionare some of them, and their code is not amazingly more complex than that ofquote. The question was curiosity on my part.Will I be smacked down for suggesting you simply use Spidermonkey or Rhino? :-)
Given that I'm studying electronic engineering and looking to get into embedded systems programming, this is actually pretty damn cool!
Chris Toshok went the other way, just last week.
HAHAHA, YES!
do you still code emacs lisp now?
actually i just learned emacs lisp about 2005, while being a pro Perl coder since 1998. Emacs lisp is truely fantastic for text processing. Afaik, nothing beats it.