Re: Beware of modules.
On Fri, Jan 15, 1999 at 01:18:37AM +0100, Olivier Galibert wrote:
2- What we're talking about is function call (trampoline or
indirect)
vs. _inline_. The 30% slowdown of mule is mostly due to the fact that
moving to the surrouding characters is more complex than p++ and p--,
and you would want to change that to a _function_call_ ?
Not at all ... MULE was
stated as a POSSIBILITY, and there are obvious
reasons why that should be discounted. Something as fundamental as
MULE or MINIMAL_TAGBITS can not, of course, be modulized.
A lot of people are installing both the MULE and non-MULE version
of
xemacs on the same system. MULE and non-MULE modules won't be
compatible at all.
The obious solution is to have two architecture directories, one
for
MULE and one without. They will have to keep two versions of ellcc around
for the module compiler too, since it is installed in $(bindir) not into
$(archlibdir).
XEmacs isn't an editor written in C. XEmacs is written in emacs
lisp.
The C part is constituted of:
- the core lisp engine
- all the basic tasks involving the environment (accessing files,
drawing to screen...)
- some functions that could have been written in lisp, but would have
been too slow as a result
Part of the building process of XEmacs is called the undumping. A
bunch of lisp is loaded which "plugs" into the C level through static
oh
you meant unEXECing. The terminolgy you used confused me. What you
really mean is dumping, or unexecing. undumping is a double-take :-)
If you use modules for parts of the engine, you will need to find
some
way to link back said static variables to the lisp code. I wouldn't
even know where to start.
Depends. Dont forget that modules add in variables and
functions in the exact
same way they would if you had used (defun ()). If its not a problem for
Lisp functions its not a problem for subr's. I agree that loading modules
into the pure emacs is a bad idea, as they way in which the subrs and
variables are added will lead XEmacs to put them in the dumped version.
However, most of the pre-loaded stuff is supposed to be RELATIVELY autonomous
isn't it?
a- monolithic executable:
- the function is called
- page fault, the code is loaded in memory. A bit of read-ahead of
the code is done before and after the function
- the function runs
b- module
- the program sees that the function is not in memory
- the module is found and the function table is loaded (but not the
function code itself, usually)
- the function pointers are updated
- the function is eventually called. Go to a.
Perhaps you should have a look at
SVR4.2 or SVR5's dlopen() code. I will
check it again (and talk to the God who invented ELF and dlopen() in the
first place to make sure), but the last time I checked, things looked more
like:
b- module
- dlopen() is called on the module. Dynamic loader loads in module and
executed code in the .init section (static constructors, and other
user code if you know what you are doing).
- rtld binds addresses in the offset table to real addresses (code is
no longer position independant, it now has a bound address in a valid
text segment).
- text segment is a candidate for retirement like any other, although it
has a higher bias against discarding.
- function is called, accesses code in text segment and run it, or reloads
if the page was dropped.
This is the conceptual procedure, not an exact description. This is the case
on SVR3.2 and later. Is it THAT much less efficient in other environments?
--
J. Kean Johnston | "If equal affection cannot be,
Engineer, SPG | let the more loving one be me" - W.H. Auden
Santa Cruz, CA +----------------------------------------------------------
Tel: 831-427-7569 Fax: 831-429-1887 E-mail: jkj(a)sco.com