john@synsys.UUCP (John C. Rossmann) (10/02/89)
I'm trying to bring up GNU emacs 18.55 on a PS/2 under AIX 1.1. I'm using m-ibmps2-aix.h and s-usg5-2.h (or it might be s-usg5-2-2.h, I'm not where I can check right now). Anyway, when I build it "straight", with and without -O, everything builds but temacs blows up in the initial "inc_vers" command. One build ended with "Termination code 138", another with a segmentation violation. Next, I built it with "CANT_LOAD" defined to tell temacs not to try to dump in the lisp code. The unloaded version works, for the most part, but info mode can't find the top node and therefore won't work. The top level info file appears on the screen, but the initial --TEXT-- ... ... ^_ stuff is on the screen too, and none of the mode commands work. Elisp says something like "bad stringp - nil". Note that I built 18.55 on my own SysV386 3.2 system from the same source with no problems, and everything I've tried there works fine, including info mode. Info mode is important to me because I'm new to using emacs and I'd like to have the on-line doc access that info mode provides. The PROBLEMS file suggests that inadequate page space could be the problem, but the PS/2 I'm building emacs on has 8 megs of page space, and I did the build with no other activity on the system. If anyone out there has been able to do a "proper, normal" build under AIX PS/2 1.1, with correct runtime behavior afterward, I'd really appreciate hearing how you did it. Thanks. John Rossmann (uunet!synsys!john)
carciofi@SRC.Honeywell.COM (Jim Carciofini) (10/12/89)
I just got GNU emacs 18.55 working on an IBM PS/2 (model P70) under AIX 1.1 I used m-ibmps2-aix.h and s-usg5-2-2.h I also had to add the following in src/config.h after the "#include m-ibmps2-aix.h" line: /* AIX has ptys unlike most usg machine */ #define HAVE_PTYS /* Hack to get around apparent bug in AIX C compiler? "regex.c" appears to assume that C will extend the sign bit when a char is cast to an int. AIX C V1.1 does not do this. This hack does not work when compiler optimizations are turned on. Is there a better way to do this? */ #undef SIGN_EXTEND_CHAR #define SIGN_EXTEND_CHAR(x) ((signed char) x) The SIGN_EXTEND_CHAR problem caused most regular expresions to fail. Thus temacs broke while trying to load "inc-vers". I am new to C and dont know if this is the "right" way to fix this. I would like a "clean" fix that will work when I turn on compiler optimizations. Any ideas?
hue@netcom.UUCP (Jonathan Hue) (10/12/89)
In article <34525@srcsip.UUCP> carciofi@SRC.Honeywell.COM (Jim Carciofini) writes: >#define HAVE_PTYS >/* Hack to get around apparent bug in AIX C compiler? "regex.c" appears to > assume that C will extend the sign bit when a char is cast to an int. > AIX C V1.1 does not do this. This hack does not work when compiler > optimizations are turned on. Is there a better way to do this? */ >#undef SIGN_EXTEND_CHAR >#define SIGN_EXTEND_CHAR(x) ((signed char) x) It's not a bug - chars are unsigned in the PS/2's compiler. It shouldn't extend the sign when promoting to an int. When I brought up 18.52 I used something like the following: #define SIGN_EXTEND_CHAR(x) ((x) & 0x80 ? ((x) - 255) : (x)) -Jonathan
hue@netcom.UUCP (Jonathan Hue) (10/15/89)
In article <2896@netcom.UUCP> hue@netcom.UUCP I write: > >#define SIGN_EXTEND_CHAR(x) ((x) & 0x80 ? ((x) - 255) : (x)) That should have been 256, not 255. Seems like the (signed char) cast should have worked though. -Jonathan
meissner@twohot.rtp.dg.com (Michael Meissner) (10/16/89)
In article <2896@netcom.UUCP> hue@netcom.UUCP (Jonathan Hue) writes: > It's not a bug - chars are unsigned in the PS/2's compiler. It shouldn't > extend the sign when promoting to an int. When I brought up 18.52 I used > something like the following: > > #define SIGN_EXTEND_CHAR(x) ((x) & 0x80 ? ((x) - 255) : (x)) A usually more efficent way of sign extending characters (depending on how much branches cost in terms of hardware speed or compiler optimizations) is: #define SIGN_EXTEND_CHAR(a) ((((a) & 0xFF) ^ 0x80) - 0x80) The & 0xFF can be eliminated if you are sure that a is in fact a char variable and not an integer, since that automatically occurs in promoting an unsigned char to int. -- Michael Meissner, Data General. If compiles where much Uucp: ...!mcnc!rti!xyzzy!meissner faster, when would we Internet: meissner@dg-rtp.DG.COM have time for netnews?
lhf@aries5.uucp (Luiz H de Figueiredo) (10/17/89)
In article <MEISSNER.89Oct16114934@twohot.rtp.dg.com> meissner@twohot.rtp.dg.com (Michael Meissner) writes: >In article <2896@netcom.UUCP> hue@netcom.UUCP (Jonathan Hue) writes: > >A usually more efficent way of sign extending characters (depending >on how much branches cost in terms of hardware speed or compiler >optimizations) is: > >#define SIGN_EXTEND_CHAR(a) ((((a) & 0xFF) ^ 0x80) - 0x80) Why not use #define SIGN_EXTEND_CHAR(a) ( (int) (signed char) (a) ) I am missing something? ------------------------------------------------------------------------------- Luiz Henrique de Figueiredo internet: lhf@aries5.uwaterloo.ca Computer Systems Group bitnet: lhf@watcsg.bitnet University of Waterloo ------------------------------------------------------------------------------- eof