Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!ukma!gatech!mcnc!rti!talos!kjones
From: kjones@talos.UUCP (Kyle Jones)
Newsgroups: comp.emacs
Subject: Re: Portability problem with gnu-emacs
Message-ID: <305@talos.UUCP>
Date: 21 Sep 88 14:47:15 GMT
References: <441@myab.se> <394@augean.OZ>
Reply-To: kjones@talos.UUCP (Kyle Jones)
Organization: Philip Morris Research Center, Richmond, VA
Lines: 47

In article <441@myab.se> lars@myab.se (Lars Pensj|) writes:
>Why is gnu-emacs implemented with the self dump feature?  I know that
>it speeds up the start-up, but it is extremly unportable.

Dumping compiled code also helps keep down GNU Emacs' virtual memory
usage (which in turn speeds startup time a bit more.)  Code common to
all invocations of the editor will be shared among concurrent Emacs
sessions, instead of being duplicated in-core.  Since GNU Emacs is BIG
even for Emacs-style editors, this is a big win.

As for portability, let us not forget that GNU Emacs is targeted for
the (not yet completed) GNU operating system. As such, it is
sufficient that the dump feature work with the BSD executable file
format that the GNU system ultimately will use.  The real task will be
to port the operating system once it is completed.

>A suggestion:
>Let temacs write the compiled lisp code into a file 'code.c' in the following
>format:
>
>char lisp_code[] = {
>23, 45, 76, 93, -34, 45,
>...
>};
>
>And then relink a new emacs with 'code.o'. 'temacs' can be linked
>with an empty 'lisp_code' defenition.

It's not just the lisp code that needs to be dumped but the entire
initilized lisp system e.g. interned symbols, internal pointers to
lisp objects, symbol -> function definition relationships, initialized
keymaps, and so on.  I can't see how this idea can be made to save
this information, since all the other .o files with which 'code.o' will be
linked already will have all external variables initialized to 0.

In article <394@augean.OZ> idall@augean.OZ (Ian Dall) writes:
>Would it be possible to translate the preloaded lisp to C in the format of
>the lisp callable C functions already there.
>...
>This is of course a harder problem. Would there be fundamental restrictions
>on the allowable lisp code to do this?

I have read that the Kyoto Common Lisp compiler does just that.  GNU
Emacs Lisp is clearly less complex than full Common Lisp so the
situation is workable.

kyle jones