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