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