Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!samsung!sdd.hp.com!apollo!rehrauer From: rehrauer@apollo.HP.COM (Steve Rehrauer) Newsgroups: comp.sys.apollo Subject: 68k compiler target defaults (was Re: bsd4.3) Message-ID: <4b9c0da5.20b6d@apollo.HP.COM> Date: 15 Jul 90 18:42:00 GMT References: <9007131550.AA25981@pan.ssec.honeywell.com> <1990Jul13.195714.6078@terminator.cc.umich.edu> Sender: root@apollo.HP.COM Reply-To: rehrauer@apollo.HP.COM (Steve Rehrauer) Organization: Hewlett-Packard Apollo Division - Chelmsford, MA Lines: 117 In article <1990Jul13.195714.6078@terminator.cc.umich.edu> rees@citi.umich.edu (Jim Rees) writes: >In article <9007131550.AA25981@pan.ssec.honeywell.com>, >thompson%pan@UMIX.CC.UMICH.EDU (John Thompson) writes: > > > e) do gcc and X11R4 compile with no more than the usual mucking around? > BeatsMe, but from comments on the net, I'd say no. > >I've got both these running here, and didn't have to do anything special >other than add "-A cpu,3000" to the CFLAGS (I wish Apollo would make this >the default). Interesting. Are you doing this for performance reasons, I assume? If not, then ignore me as I talk through my hat below... The so-called "CR1.0" 68k compilers (we've decoupled our OS and language releases, so I can't say "SR10.3" or some such -- "CR1.0" means revision 10.8 FORTRAN, 8.8 Pascal, 6.8 C), which are now in Beta test, will "sort of" have this. This is going to be a potentially confusing issue for our customers who use our compilers, so let me see if I can do a little advance hand-waving. We in R&D believe that all but a handful of our installed 68k customer base is running on "-cpu 3000" machines by now. What we hear from the field is that there's relatively few 100/300/320/400/420/460/660s still out there. So it's been, if not an actual thorn, at least a niggling splinter in our sides that the default machine target for the compilers has been "-cpu any". "-cpu any" code runs everywhere on any 68k nodes, but hardly well. We also realize that there's been an ever-proliferating, somewhat schizoid set of "-cpu" options to support new hardware. The now-announced 68040-based hardware waggled the temptation to add Yet Another "-cpu" option, but what to call it? "-cpu m040"? "-cpu some_HP_model_number"? We hope that what we've done for CR1.0 makes a bit more sense. First, we preserved all existing "-cpu" options, so nearly everyone can ignore the whole issue if they wish. Second, we added three new "-cpu" options: mathchip, mathlib and mathlib_sr10. ("THREE" new options? Are we insane?? Well, let me explain the rationale and then you decide.) Third, we made "mathlib_sr10" the default; more in a moment. "Mathchip" is merely a synonym for any of the following options (I'm not even sure all of these are documented): 3000, m881, 68881, 560, 330, 570, 580, 5700. Code will run optimally on a DN5xx (without FPX board), or any of DN330/550/2500/3x00/4x00 (without FPA board), when compiled "-cpu mathchip". "Mathchip", as the name implies, assumes that you have Motorola floating-point hardware (i.e.: a 68881/68882 chip) in your node. The 68040 hardware was the impetus behind "mathlib" and "mathlib_sr10". As some of you may know, the 68040 processor has floating-point support on-chip. Motorola chose not (actually, I suspect limits on physical die-size "chose not" :-) to implement the full instruction-set of their '881/'882 coprocessors. Unimplemented instructions can of course be emulated in kernel code (actually MUST be, so that existing code will run on an '040 node without recompilation), but that is SLOW. It's far better for the compilers to avoid generating such instructions. Hence, "mathlib" and "mathlib_sr10" both tell the compiler to assume that it can use floating-point instructions that an '040 can execute. "Mathlib" tells the compiler that f.p. ops that an '040 can't execute should be implemented via a new user-space f.p. library, supported in SR10.3 and above. "Mathlib_sr10" tells the compiler to use the existing f.p. library, which has been present as far back as anyone reading this cares about -- certainly at SR9.7 and above -- for those ops. The advantage of "mathlib" is that the interface to the new library has been crafted for speed. Code compiled "-cpu mathlib" will run nearly optimally on any node for which "-cpu mathchip" will generate optimal code. The advantage of "-cpu mathlib_sr10" is that the compiled code will be backwards- compatible with a much wider range of OS revisions, at some sacrifice of speed versus "mathlib". When you hear "mathlib" and "mathlib_sr10", think "new floating-point library" and "old floating-point library", respectively. The upshot is that "mathlib_sr10" is the default machine target for the 68k compilers at CR1.0. If you: - Have a PEB machine (e.g.: 320/420), or any of the "old" nodes that I mentioned at the outset of this, then to use the CR1.0 compilers you'd need to explicitly ask for "-cpu peb" or "-cpu any". Note that pre-CR1.0, you automatically got this; at CR1.0 and beyond, you won't. - Want to use the CR1.0 compilers to generate code that MAY need to run on a PEB or similarly "old" hardware, you should explictly ask for "-cpu any" to ensure that your code runs everywhere. Note that pre-CR1.0, you automatically got this; at CR1.0 and beyond, you won't. - Have a "-cpu 3000"-capable machine and have just been using the default compiler settings, and especially if you compile floating- point programs, you can continue to do nothing special. You should be pleased with the runtime performance boost of your code, though. - Have a "-cpu 3000"-capable machine and have been asking for "-cpu 3000" because your applications are performance-critical, you should probably continue to ask for "-cpu 3000" (or "mathchip" if you want to take the trouble to learn the new name). - Have one of the new 68040-based nodes (we're talking of the future now, of course), then the default will run nearly optimally, "mathlib" will run optimally, and "-cpu 3000/mathchip" may run optimally or nearly so (depending upon the mix of floating-point operations in your code). All of this stuff will be explained in more (and probably more lucid) detail in the release notes & man pages. I'm just a code-gen weenie, not a tech- writer. Hope I didn't bore everyone to tears; apologies for spending so much bandwidth on the issue. P.S. - We kicked around a number of names, and while we didn't exactly fall madly in love with "mathchip/mathlib/mathlib_sr10", we couldn't arrive at a better set that intuitively manages to convey what the compiler does with them. It's too late for the names to change, but if anyone has a better trio of names, I'd be happy to hear them anyway. :-) -- >>"Aaiiyeeee! Death from above!"<< | (Steve) rehrauer@apollo.hp.com "Spontaneous human combustion - what luck!"| Apollo Computer (Hewlett-Packard)