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