Return to APOLLO CVS log

Up to [CSRG BSD Unix] / 43BSD / contrib / emacs / etc

Annotation of 43BSD/contrib/emacs/etc/APOLLO, revision 1.1.1.1

1.1       root        1: The Apollo has a bizarre operating system which does not permit
                      2: Emacs to be dumped with preloaded pure Lisp code.  Therefore, each
                      3: time you start Emacs on this system, the standard Lisp code is loaded
                      4: into it.  Expect it to take a long time.  You can prevent loading of
                      5: the standard Lisp code by specifying the -nl switch.  It must
                      6: come at the beginning of the command line; only the -t and -batch
                      7: switches may come before it.
                      8: 
                      9: You must use m-apollo.h in the config.h file, together with
                     10: s-bsd4.2.h.
                     11: 
                     12: There is one remaining problem on the Apollo.  The system does not
                     13: come with a C preprocessor as a separate program.
                     14: 
                     15: The C compiler can be used in place of cpp, but you must fool it into
                     16: thinking that ymakefile is a C program.  This requires replacing the
                     17: rule for xmakefile in src/Makefile with the following:
                     18: 
                     19: xmakefile: ymakefile config.h
                     20:        rm -f xmakefile
                     21:        cp ymakefile ymakefile.c
                     22:        (cc -E ymakefile.c | sed -e 's/^#.*//' -e 's/^[ \f      ]$$//' -e 's/^ /        /' | \
                     23:        sed -n -e '/^..*$$/p' > xmakefile)
                     24:        rm ymakefile.c
                     25: 
                     26: It has also been suggested that you change etc/Makefile not to make
                     27: loadst.c.  I think it would be better to fix loadst.c than to turn
                     28: it off, but nobody has told me what, if any, problem it encounters.
                     29: 
                     30: 
                     31: Here is a design for a method of dumping and reloading the relevant
                     32: necessary impure areas of Emacs.
                     33: 
                     34: On dumping, you need to dump only the array `pure' plus the
                     35: locations that contain values of forwarded Lisp variables or that are
                     36: protected for garbage collection.  The former can be found by a
                     37: garbage- collection-like technique, and the latter are in the
                     38: staticprolist vector (see alloc.c for both things).
                     39: 
                     40: Reloading would work in an Emacs that has just been started; except
                     41: when a switch is specified to inhibit this, it would read the dump
                     42: file and set all the appropriate locations.  The data loaded must be
                     43: relocated, but that's not hard.  Those locations that are of type
                     44: Lisp_Object can be found by a technique like garbage-collection, and
                     45: those of them that point to storage can be relocated.  The other data
                     46: read from the file will not need to be relocated.
                     47: 
                     48: The switch to inhibit loading the data base would be used when it
                     49: is time to dump a new data base.
                     50: 
                     51: This would take a few seconds, which is much faster than loading
                     52: the Lisp code of Emacs from scratch.

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.