A better approach than compiling Lisp into C code is to optimize the byte
code interpreter. Here's something that I wrote earlier in a response to
Martin:
This way for example, you could convert unaligned accesses into aligned ones
[1],
substitute in array values from the constant array so as to avoid an extra
indirection, check some parameters so they don't have to be checked at
runtime,
etc. Another likely place for speed up is in function calling, which
currently is
notoriously slow. There also probably speed ups that could be made in symbol
value access.
[1] what I mean to say is that the string of byte code instructions should be
expanded into an array of integers, which will tremendously speed up access
to those values.
SL Baur wrote:
Subject: Re: dlopen for xemacs
Date: Mon, 20 Apr 1998 15:05:33 -0400
From: Joshua Rowe <rowe(a)eksystems.com>
To: SL Baur <steve(a)xemacs.org>
References: <9801152235.AA13534(a)meta.eksystems.com>
<m2n2djg4dy.fsf(a)altair.xemacs.org>
SL Baur writes:
> I don't recall if I ever got back with you on this. We've integrated
> dlopen into XEmacs and have been hacking on it. William Perry has
> done some further work on it, particularly with regards to portability
> and configure issues. The latest word is that Richard will be using
> a version of it in FSF GNU Emacs as well.
>
> Thanks for kicking things off.
Sure thing.
Maybe I should have posted this to a mailing list/newsgroup, but I
really don't pay attention to things like that. Forward this and
forget it if you wish.
I'm not sure if I ever told you the intent of the code. Maybe you can
find someone to figure out the specifics:
It is much more useful to use native compiled code if you don't have
to recompile xemacs whenever the code changes.
It is good to keep most of the code in xemacs in lisp form.
It would be good to have a lisp->native-machine-code compiler.
It is now possible to load native code without recompiling xemacs.
The lisp->native-machine-code compiler can be platform independent by
outputting xemacs-standard C - ie it uses all the C macros in lisp.h,
etc - and compiling that code into a shared library which can then be
dlopen'ed.
The actual code that is output can be very simple for a first pass -
there is already a byte compiler. Take a piece of byte compiled code
and output the C that gets run for that bytecode. bytecode.c has the
operations and the C actions. Output those C actions.
I'm not sure exactly how much faster the code could become in this
fashion, but I believe it could be _much_ faster if someone wrote a
lisp->C instead of my current suggestion of lisp->bytecode->C.
For example, from disassemble bbdb-add-hook:
0 constant boundp
1 varref hook
2 call 1
3 goto-if-not-nil 9
would become:
Lisp_Object * bbdb_add_hook_constants;
DEFUN ("bbdb-add-hook"...)
{
/* variable declarations, including constant's */
Lisp_Object v1, v2;
int op;
/* other stuff, including initialize the stack */
do switch (op = FETCH) {
0: /* constant boundp */
PUSH(bbdb_add_hook_constants [0]);
1:
v1 = bbdb_add_hook_constants [5];
if (!SYMBOLP (v1))
v2 = Fsymbol_value (v1);
else
{
v2 = XSYMBOL (v1)->value;
if (SYMBOL_VALUE_MAGIC_P (v2))
v2 = Fsymbol_value (v1);
}
PUSH (v2);
2:
DISCARD (1);
TOP = Ffuncall (op + 1, &TOP);
3:
op = FETCH2;
if (!NILP (TOP))
{
pc = op;
break;
}
} while (1);
...
}
--
jmr -
http://meta.eksystems.com/~rowe
Just because you're paranoid doesn't mean they're not after you.
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS dpu s: a--- C++++$ ULOU++++$ P+ L++++$ E+++$ W++ !N- !o>+ ?K
w---(++) O+ M-- V+++$ PS+ PE Y PGP- t+ 5 X+++ R>+ !tv b+++ DI++ D- G e
h++ r y
------END GEEK CODE BLOCK------
--
This message composed using voice recognition software and foot pedals.
(No keyboards were harmed while composing this message.)