Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!mcnc!rti!xyzzy!meissner From: meissner@xyzzy.UUCP (Usenet Administration) Newsgroups: comp.emacs Subject: Re: Portability problem with gnu-emacs Message-ID: <1228@xyzzy.UUCP> Date: 26 Sep 88 00:26:21 GMT References: <441@myab.se> Reply-To: meissner@xyzzy.UUCP (Michael Meissner) Organization: Data General (Languages @ Research Triangle Park, NC.) Lines: 45 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. After spending a bit of time hacking an unexec to work on Data General MV computers, let me share some observations about GNU: 1) The lisp code smashes addresses + lisp type into one 32-bit word, which looks like (on a big-endian machine): 3 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 +-+-+-------------+----------------------------------------------+ |M|A| Type | Bottom 24 bits of address or lisp integer | +-+-+-------------+----------------------------------------------+ Where the top bit is used as a mark during garbage collection, and the second bit seems to be used also for garbage collection for arrays. The lisp type follows, and the lower 24 bits are dependent on the type, but are typically the bottom 24 bits of the address, or the integer value. 2) Because of the lisp format, you can't really initialize things, since C has no way of getting just the bottom 24 bits of an address. 3) You can't really relink, because addresses might change due to the new module being added. 4) For a word oriented machine like the MV, you have to be careful to store a byte address when creating Lisp Objects, and expect it to be in byte address form, since garbage collection plays funny games with pointers. 5) Gnu emacs also depends on preserving the value of static variables, and some malloc'ed data. 6) The normal unexec code depends on having a dumb linker which will not reorder data segments from the order encountered in the object modules. PS - for any DG/UX readers out there, I will try to make the DG/UX changes available in mid October (I won't be back until the start of October). -- Michael Meissner, Data General. Uucp: ...!mcnc!rti!xyzzy!meissner Arpa: meissner@dg-rtp.DG.COM (or) meissner%dg-rtp.DG.COM@relay.cs.net