Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!mit-eddie!bloom-beacon!gatech!ncsuvx!mcnc!rti!xyzzy!throopw
From: throopw@xyzzy.UUCP (Wayne A. Throop)
Newsgroups: comp.emacs
Subject: Re: Portability problem with gnu-emacs
Message-ID: <1231@xyzzy.UUCP>
Date: 26 Sep 88 18:28:29 GMT
References: <441@myab.se> <29698@bbn.COM>
Organization: Data General, RTP NC.
Lines: 43

> jr@bbn.com (John Robinson)
>> lars@myab (Lars Pensj|)
>>[...GNU emacs could be more portable if it arranged to initialize its
>>    pre-defined lisp routines via source like so: ...]
>>char lisp_code[] = {
>>23, 45, 76, 93, -34, 45,
>>...
>>};
>>... etc.
> But the problem may be that not all compilers support [...putting
> such objects in the text (that is, shared) section...].  [...]
> Also, signed chars
> (they appear in your example) may be a problem.  But I merely quibble;
> it's a great idea.  Needs elisp symbol-table hooking but not much more.

I agree that the method Lars points out is more portable, and  good
deal cleaner, even with the problems with signed chars and the fact
that it may be unshared data on some systems.  The code could be
generated based on a set of switches to control the signedness of the
range of character values, and most every system has some hack or
another to put unchanging variables into text space, even if it is the
old mouldy standby of tromping on the intermediate assembly code.  The
results of these hacks would still be far more aesthetic than the
massive hacks involved in unexec.

BUT, the real problem solved by unexec that is not solved by source
generation is that some of the values that go into the initialized
area are not known until after link time.  The addresses of primitive
routines, for example.  As long as the lisp object code refers to
absolute addresses (and I suspect it must do so for efficency
reasons), the initializing code cannot be generated for an object yet
to be linked, but only for the current *already* *linked* executable.
Which implies unexec, or some similar subtrefuge.  Most LISP systems
have similar problems.

All that said, I think unexec could be made a good deal cleaner, and
the machine dependancies could be isolated in a much more palatable
way.  But going all the way to generating source is probably Right Out.

-- 
A LISP programmer knows the value of everything, but the cost of nothing.
					--- Alan J. Perlis
-- 
Wayne Throop      !mcnc!rti!xyzzy!throopw