csg@pyramid.pyramid.com (Carl S. Gutekunst) (10/02/90)
>Has anyone tried to compile gcc-1.37.1 on a Pyramid under OSx 5.0d? I've compiled it here on a 9840 and an MIS 4/2, but targeted for a 68000. I've been quite pleased with it; on many local optimizations it does a better job than the GreenHills C we purchased from Oasys. And I was pleased to see that the large number of portability problems in gcc itself have been resolved. But it does emit bad code more than I'd like at this point. >when attempting to recompile with gcc ( in both universes). OK, maybe I'm just begging to be flamed, but I gotta ask: I can see writing a Pyramid CPU backend for gcc as a fun and useful pedagogical exercise. But why would anyone want to use gcc for production work instead of the Pyramid's native compiler? gcc doesn't generate anywhere near as good code (either local or global), and it has lots more bugs. If you want to write and compile strict ANSI C code, then I could see it; but ANSI C is the exception these days, and it's usually easy to convert to compile with K&R compilers. <csg>
adams@swbatl.sbc.com (Tom Adams - 235-7459) (10/03/90)
In article <129037@pyramid.pyramid.com> csg@pyramid.pyramid.com (Carl S. Gutekunst) writes: >or global), and it has lots more bugs. If you want to write and compile strict >ANSI C code, then I could see it; but ANSI C is the exception these days, and >it's usually easy to convert to compile with K&R compilers. That's exactly why I'm trying to get this working. Much gnu stuff is ANSI C, and there's a lot more code than I care to convert, *and* keep up to date afterwards. And while production use isn't the goal, I'd still like to be able to compare gcc and the CLE myself. Actually I just want the Pyramid and the Amdahl to play chess :) Torbjorn Granlund <tege@sics.se> was kind enough to send patches that correct the gcc problem I encountered. I'll forward them to whoever wants them. These patches corrected the gcc bootstrap error, but the gcc compiled gcc doesn't make any difference in the behavior of Xchess, and gnuchess 3.1. Does anyone have these guys running on 5.0{...d}? Interesting thought, using 68k targeted gcc on the Pyramid. We use the Oasys 68K assembler, and have assembler coders around. I suppose that generating S records from gcc is too much to ask for? Perhaps *I'm* begging to be flamed now? -- uunet!swbatl!adams or adams@swbatl.sbc.com Tom Adams: 314-235-7459: Southwestern Bell Telephone Advanced Technology Lab BOOKS WANTED: pre-1930 radio, electrical & scientific topics
chris@utgard.uucp (Chris Anderson) (10/04/90)
In article <129037@pyramid.pyramid.com> csg@pyramid.pyramid.com (Carl S. Gutekunst) writes: >OK, maybe I'm just begging to be flamed, but I gotta ask: I can see writing a >Pyramid CPU backend for gcc as a fun and useful pedagogical exercise. But why >would anyone want to use gcc for production work instead of the Pyramid's >native compiler? gcc doesn't generate anywhere near as good code (either local >or global), and it has lots more bugs. If you want to write and compile strict >ANSI C code, then I could see it; but ANSI C is the exception these days, and >it's usually easy to convert to compile with K&R compilers. 1. For the error and warning messages. Lots easier to scan through than lint's, and once you've gotten most of them to vanish, your lint checks are much smaller as well. 2. ANSI C even though gcc isn't quite up to the ANSI standard, it's close enough to be quite usable. And when you have a bunch of PC programmers who learned ANSI C instead of K&R, then it's easier to use gcc than teaching them K&R. 3. You need it for g++. Not that I have g++ running on a Pyramid, mind you, but when I do... (a side note, has anybody gotten good code out of g++ on a Pyramid? I'd like to talk to you if you have.) 4. Cross compiling environments. Other than that, no. Pyramid's cc is faster, produces better code, and has less bugs. Much like you said. You takes the good with the bad. Chris -- | Chris Anderson | | QMA, Inc. email : {csusac,sactoh0}!utgard!chris | |----------------------------------------------------------------------| | My employer never listens to me, so why should he care what I say? |
tege@sics.se (Torbj|rn Granlund) (10/04/90)
OK, maybe I'm just begging to be flamed, but I gotta ask: I can see writing a Pyramid CPU backend for gcc as a fun and useful pedagogical exercise. But why would anyone want to use gcc for production work instead of the Pyramid's native compiler? gcc doesn't generate anywhere near as good code (either local or global), and it has lots more bugs. If you want to write and compile strict ANSI C code, then I could see it; but ANSI C is the exception these days, and it's usually easy to convert to compile with K&R compilers. I have quite a different experience. GCC produces *much* better code that pyramid's native compiler. All examples I have tried are at least as fast, and sometimes twice as fast when compiled with GCC. Also, code sics is smaller. It is possible to construct programs that run faster when compiled with pyramid's compiler. Since the registers have virtual 32 bit addresses, pyramid's compiler doesn't allocate registers whose addres is taken to memory, while GCC does allocate then to memory. But who writes optimized code relying on hevy usage of such registers? I have had problems with pyramid's compiler, and there are still some workarounds in the GCC pyramid specific sources, to simplify bootstrapping. If anyone knows any bugs in the GNU C pyramid port, I'd be more than happy to fix them! -- Torbjorn Granlund
csg@pyramid.pyramid.com (Carl S. Gutekunst) (10/07/90)
>Interesting thought, using 68k targeted gcc on the Pyramid. We use the Oasys >68K assembler, and have assembler coders around. I suppose that generating S >records from gcc is too much to ask for? Not at all, if you're willing to be a little indirect. We have the old 'm68' 68000 tools from MIT, which we've enhanced considerably over the years. The m68 complier was terrible, so we replaced it with the Oasys/GHS /lib/ccom and a much mangled version of cc68. All the other tools -- as, ld, and so on -- we kept intact. We presently build all our 680x0 frontend firmware this way. For production work, we have a downloader that reads a.out files, but we do a lot of stuff with S records, too. Oasys has about the worst support of any software vendor I've ever dealt with, and we've now got a lot of iron besides the OSx machines upon which we would like to cross-compile 680x0 stuff. As we can't get Oasys to give us current releases for OSx, I'm not even going to ask about SPARC, MIPS, Nixdorf, and the SVR4 Pyramids. So I'm planning to do with gcc exactly what we do with GreenHills C: replace the /lib/ccom module, but keep everything else as is. (Including the old UNIX cpp, incidentally. We have too much code that "knows" that cpp does string subsitutions.) There are a few optimizations that GHS knows about that gcc does not, and which clearly affect performance, but I suspect that will change with time. (For example: GHS will load the addresses of frequently referenced static variables into registers. gcc uses full absolute addressing every time. The TITN-derived and SSI software that we use make use of static variables like they were free, and GHS wins big here. I suspect GHS would blow away gcc on the Neil Nelson benchmark, which uses only static variables.) Oh, and the gcc compiler runs about 10 times faster than GHS. (Whisper nicely in my ear at the PUG meeting next week, and maybe I'll make you a tape of the MIT tools we use. It's all PD. And you can come and throw eggs at my talk on Wide Area Networking.) <csg>