aks@HUB.UCSB.EDU (Alan Stebbens) (01/10/91)
> Has anyone gotten GNUemacs to work on an IBM RS6000 running AIX? I'm > having a terrible time getting it to work. The m- and s- files > supplied are for AIX on an RT, and they just dont work. Help! I've seen this request so many times now (since I'm also waiting for The Big Fix), that it seems appropriate to post a summary of what's available, and what the current state seems to be. There is a package prepared by "Steve Roseman, Lehigh University Computing Center, LUSGR@VAX1.CC.Lehigh.EDU" at byron.u.washington.edu, in the file /pub/aix/RS6000/gnuemacs/emacs-aixV3.shar.Z", for which we (fellow RS6000 and Emacs users) should all grateful. This package helps, but, there is still some work to be done. If you are FTP-impaired, send an email request and I'll mail the package. These are the two configuration files: s-aix3-1.h, and m-ibmr2.h (I changed it on my system to be m-ibmrs6000.h -- not many people know the architecture by the former name). Also included in this package are some patches to sysdep.c, and x11term.c, and a new file called "unexaix.c" (which doesn't work), and the config in m-ibmr2.h disables the code anyway. In my opinion, the m- config file is a bit "hacky", containing many defines which should properly be considered part of the s- config file. But, once you modify config.h to include these two files, you will get a "temacs" which will execute, and if you execute "temacs -l loadup.el", at that point, you will have a running emacs with the standard emacs-lisp libraries loaded. Although the startup time is slightly longer than a preloaded emacs, it's kinda neat to watch how incredibly fast emacs loads everything on an RS6000. The only impediment to a preloaded Emacs for the RS6000 is that unexaix.c doesn't really work yet. For those who are curious: on the RS6000 architecture, the text segment starts at address 0x1000000, and the data segment starts at 0x2000000. As Emacs loads its "preload" libraries (from "loadup.el"), the pure data portion of the data segment is filled with the loaded lisp code on the assumption that during the dump, the pure data portion of the data segment will become "part" of the text segment and thus shareable. The current problem is that an assumption was made that if the pure data cannot be remapped into the text segment, then the reasonable default would be to "join" them by assuming the address hole between the data and the text would be filled with zeroes on the output file and subsequent executable. See the addresses above; compute the difference between them; that's a BIG hole and it is *not* a good default to try to write zeroes for that size of an address hole. The short-term solution is to just create a new executable with the data segment "as is" and non-shareable; the new executable need only to have its new "end_data" address moved to the end of the loaded "pure data". The best solution would be figure out if and how it is possible to remap the pure data into a separate shared text segment, leaving the non-shareable data in its own data segment. Any AIX gurus out there care to take a poke? Hope this helps. Alan Stebbens <aks@hub.ucsb.edu> (805) 893-3221 Center for Computational Sciences and Engineering (CCSE) University of California, Santa Barbara (UCSB) 3111 Engineering I, Santa Barbara, CA 93106