jkh@meepmeep.pcs.com (Jordan K. Hubbard) (10/28/89)
Apologies for the cross-post, but I figured that this might be of interest (or perhaps known to) both camps.. Anyway, I've compiled the whole X11R3 suite (well, it's closer to X11R4 Beta, really.. Hmmm.) with GCC 1.36 with the following flags: CCOPTIONS = -fcombine-regs -fstrength-reduce -ftraditional -DNOSTDHDRS -fforce-addr -fforce-mem -fcaller-saves -pipe And everything went smoothly with nary a hitch (I have everything from libc.a to libdbm.a compiled with gcc too, so I don't need to worry about pcc struct return problems). Well, almost without a hitch. Xterm, which once worked fine, now mysteriously refuses to do cursor motion properly while using the alternate screen. That is to say if you have your termcap/terminfo entry set up to use the alternate screen and you invoke vi or emacs, scrolling and screen positioning go all to hell. This is very odd considering that GCC seems to have done an exemplary job on other code 3 times as complex. In any case, I'm quite impressed that gcc has done as well as it has (especially considering that it's generating COFF encapsulated BSD binaries on our system V box!) but would like to get rid of this last nagging problem. Has anyone else seen it? Oh, in case anyone is curious, here are some typical code size savings (to say nothing of speed, which we're still in the process of benchmarking) that we've gotten with gcc over our standard pcc based compiler: GCC Compiled: /usr/bin/X11/xman: 225080 + 76048 + 15472 = 316600 /usr/bin/X11/xmh: 245560 + 74528 + 15796 = 335884 /usr/bin/X11/mwm: 474936 + 127864 + 20544 = 623344 (Mr Big). /usr/bin/X11/xterm: 233272 + 88464 + 28612 = 350348 PCC Compiled: /usr/bin/X11/xman: 279088 + 82280 + 15936 = 377304 /usr/bin/X11/xmh: 305652 + 80776 + 16212 = 402640 /usr/bin/X11/mwm: 614604 + 131604 + 20504 = 766712 /usr/bin/X11/xterm: 277024 + 95476 + 28620 = 401120 Not too shabby, eh? Over 140K saved with mwm alone! Jordan PCS Computer Systeme GmbH, Munich, West Germany UUCP: pyramid!pcsbst!jkh jkh@meepmeep.pcs.com EUNET: unido!pcsbst!jkh ARPA: jkh@violet.berkeley.edu or hubbard@decwrl.dec.com
jv@mh.nl (Johan Vromans) (10/30/89)
In article <1124@pcsbst.UUCP> jkh@meepmeep.pcs.com (Jordan K. Hubbard) writes: > Anyway, I've compiled the whole X11R3 suite (well, it's closer to X11R4 > Beta, really.. Hmmm.) with GCC 1.36 with the following flags: > > CCOPTIONS = -fcombine-regs -fstrength-reduce -ftraditional -DNOSTDHDRS ... ^^^^^^^^^^^^^ The pre-processor option is spelled "-traditional". "-ftraditional" does *NOT* influence the pre-processor, but also doesn't yield a message about being an unknown compiler option. Johan -- Johan Vromans jv@mh.nl via internet backbones Multihouse Automatisering bv uucp: ..!{uunet,hp4nl}!mh.nl!jv Doesburgweg 7, 2803 PL Gouda, The Netherlands phone/fax: +31 1820 62944/62500 ------------------------ "Arms are made for hugging" -------------------------
jordan@morgan.COM (Jordan Hayes) (10/31/89)
Jordan Hubbard <jkh@meepmeep.pcs.com> writes:
GCC Compiled:
/usr/bin/X11/mwm: 474936 + 127864 + 20544 = 623344 (Mr Big).
PCC Compiled:
/usr/bin/X11/mwm: 614604 + 131604 + 20504 = 766712
Not too shabby, eh? Over 140K saved with mwm alone!
% size /usr/local/bin/X11/mwm
text data bss dec hex
262144 24576 3696 290416 46e70
Hmmm. Looks like I got you beat by a mile! We shared-library-ified
libXt and libXm, and are using the OpenWindows sharified libX11 from
Sun, and we just bought back a ton of space ...
/jordan
(the real one)