1. Oh, that so makes my head hurt.
   
2. Gosh, I wonder if my UCSD P-system floppies can still be read by anything...
   
3. Now we just need to teach it how to run Brevity, and old really, really, really light-weight 6502 OS and assembly environment
   

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.

(Reply to this) (Thread)

On the subject of the emacs-lisp compiler, is there a reason quote doesn't have a byte code? It's the most called non-byte-coded function on startup for me.

(Reply to this) (Thread)

Use 'sexp instead of (quote sexp).

(Reply to this) (Parent) (Thread)

I was talking about this, profiling results on startup from a recent XEmacs 21.5:

Calls Function Name                         Ticks/
===== ===========================================/
13212 (in internal-external conversion)       219/
 9232 quote                                     1/
 3701 equalp                                    1/
 3353 compare-strings                           8/
 2803 autoload                                  7/
 2343 (in expand-file-name)                    90/
 1900 (in char-byte conversion)                 0/
 1717 x-get-resource                            6/
 1508 put                                       1/
 1319 characterp                                0/
 1180 vectorp                                   0/
  995 keywordp                                  0/
  930                                           1/
  863 get-face                                  1/
  846 byte-code                                12/
  825 face-property                             3/
  […]

And if you look at lread.c, 'whatever is effectively a macro that expands to (quote whatever).

(Reply to this) (Parent) (Thread)

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.

(Reply to this) (Parent) (Thread)

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 'quote in 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 obarray and the load-history; the rest appear to come from (defalias …) and (provide ...) calls, which are more or less unavoidable, as I understand it.

(Reply to this) (Parent) (Thread)

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.)

(Reply to this) (Parent) (Thread)

It's not eval'ing its args. Here's the function:

DEFUN ("quote", Fquote, 1, UNEVALLED, 0, /*
[...]
*/
       (args))
{
  return XCAR (args);
}

I am reasonably sure putting a C breakpoint on Fquote and saying leval "(backtrace)" is a sensible way of working this out.

save-excursion and any number of other functions use UNEVALLED and have assigned byte-codes. Looks like I need to go code something and see what breaks.

(Reply to this) (Parent) (Thread)

"UNEVALLED" means "I am a special form, not a function."

(Reply to this) (Parent) (Thread)

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.

(Reply to this) (Parent) (Thread)

Since your profile data shows that the time spent in quote is much less than 0.5% of the total time, …

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-restriction are some of them, and their code is not amazingly more complex than that of quote. The question was curiosity on my part.

(Reply to this) (Parent) (Thread)

Will I be smacked down for suggesting you simply use Spidermonkey or Rhino? :-)

(Reply to this) (Thread)

Given that I'm studying electronic engineering and looking to get into embedded systems programming, this is actually pretty damn cool!

(Reply to this) (Thread)

Chris Toshok went the other way, just last week.

(Reply to this) (Thread)

(Reply to this) (Thread)

HAHAHA, YES!

(Reply to this) (Parent) (Thread)

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.

(Reply to this) (Thread)