Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!wuarchive!zaphod.mps.ohio-state.edu!mips!prls!pyramid!csg From: csg@pyramid.pyramid.com (Carl S. Gutekunst) Newsgroups: comp.sys.pyramid Subject: Re: upgrading to OSx 5.od and gnu Message-ID: <129537@pyramid.pyramid.com> Date: 7 Oct 90 04:37:36 GMT References: <1990Sep28.205311.10896@swbatl.sbc.com> <129037@pyramid.pyramid.com> <1990Oct2.220117.11077@swbatl.sbc.com> Reply-To: csg@pyramid.pyramid.com (Carl S. Gutekunst) Organization: Pyramid Technology Corp., Mountain View, CA Lines: 36 >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.)