rowe@cme.nist.gov (Walter Rowe) (02/13/90)
In configuring X11R4 before rebuilding with the second set of fixes, I
see that LibraryCCOptions is defined as follows in sun.cf:
#define LibraryCCOptions /* don't want special floating point */
Is there a special reason for not wanting to compile the libraries
with the "-f68881" option other than the size of the files ?
I used to compile X11R3 with this option and never had any problems.
However, since it takes quite a long time to recompile the sources, I
would like to know this information in advance so as to avoid having
to compile it all twice.
Please respond to me directly as I am not a regular reader of this
newsgroup. I fully intend to post a followup with the responses I
get. Thanks!
BTW, here is the difference in size of the X11R4 server using GNU CC
vs using vanilla SUN CC.
norman 56# size bin{,-suncc}/Xsun
text data bss dec hex
499712 40960 3984 544656 84f90 bin/Xsun
606208 32768 10968 649944 9ead8 bin-suncc/Xsun
norman 57#
-wpr
---
Walter P. Rowe, <rowe@cme.nist.gov>
System Administrator, Robot Systems Division
National Institute of Standards and Technologyjim@EXPO.LCS.MIT.EDU (Jim Fulton) (02/14/90)
Is there a special reason for not wanting to compile the libraries with the "-f68881" option other than the size of the files ? We originally did compile them with -f68881, but if memory serves, took it out for the following reasons: o if you share libraries and somebody tries to use the library without having floating point hardware, they lose. o may have needed special crt0 or library (not -lm?) even if your application didn't use any floating point. The first one was the main reason. If that isn't a problem for you, go for it.
casey@gauss.llnl.gov (Casey Leedom) (02/14/90)
By the way, it should be noted that if you're compiling with GCC, the GCC equivalent of -f68881 (-m68881) is the default. When I started getting complaints from people about this after compiling R3 with GCC last year and requests that I ``fix'' the problem by recompiling with -fsoft (-msoft-float in GCC), I told them they were fixing the wrong problem. The problem was their workstations were missing floating point hardware. Given that the MC68881RC16C is only about $125 last time I looked, it's by far the most preferable solution unless you're a total pauper.
mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) (02/14/90)
>> Is there a special reason for not wanting to compile the libraries >> with the "-f68881" option other than the size of the files ? [I assume this is with Sun cc] > We originally did compile them with -f68881, but if memory serves, > took it out for the following reasons: > o if you share libraries and somebody tries to use the library > without having floating point hardware, they lose. > [...] > The first one was the main reason. I'd recommend -fswitch. This gives most of the benefit of -f68881 if you have a 68881, yet will still run perfectly well on a machine without one. Recommended for building binaries that want to use 68881s when available but may need to run without them. Of course, you should first convince yourself there's enough floating-point code that the difference is significant.... > If that isn't a problem for you, go for it. I entirely agree. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (02/15/90)
Does anyone have any figures on how much faster X11R4 runs with a 68881 on something like a Sun 3/50 with typical use? -- Jon Zeeff zeeff@b-tech.ann-arbor.mi.us or b-tech!zeeff
mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) (02/15/90)
> By the way, it should be noted that if you're compiling with GCC, the > GCC equivalent of -f68881 (-m68881) is the default. When I started > getting complaints from people about this after compiling R3 with GCC > last year and requests that I ``fix'' the problem by recompiling with > -fsoft (-msoft-float in GCC), I told them they were fixing the wrong > problem. The problem was their workstations were missing floating > point hardware. Given that the MC68881RC16C is only about $125 last > time I looked, it's by far the most preferable solution unless you're > a total pauper. (I'd recommend -fswitch. (I don't know the gcc equivalent.)) This strikes me as a somewhat arrogant attitude. There are several perfectly good reasons why the user may not be able to do this. The user may not have the authority to spend any money on the machine, and those who do don't see the need, after all, even you must admit that the software does not require the 68881. (Or do you lie when asked such questions?) Perhaps you think running X should be valuable enough that each user should shell out $125 of their own when there's no reason but your stubbornness why the software can't handle things just fine? The machine may belong to someone else. Here at McGill, for example, I know of a lab with some machines that belong to an outside organization, and while I don't know for sure that this is true, it strikes me as very plausible that making random hardware modifications could easily lose them the machines altogether. The user may not even know which end of a screwdriver to hold. This means calling in someone else to install the thing, which is likely to run the price up pretty steeply. Another possible reason requiring calling in someone to install it is that making hardware changes can cause the service company to break off the service contract. If I had been one of your users last year I'd've just brought over my own copy and built it with -fsoft. (-msoft-float, whatever.) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
casey@gauss.llnl.gov (Casey Leedom) (02/16/90)
| From: mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) | | > By the way, it should be noted that if you're compiling with GCC, the | > GCC equivalent of -f68881 (-m68881) is the default. When I started | > getting complaints from people about this after compiling R3 with GCC | > last year and requests that I ``fix'' the problem by recompiling with | > -fsoft (-msoft-float in GCC), I told them they were fixing the wrong | > problem. The problem was their workstations were missing floating | > point hardware. Given that the MC68881RC16C is only about $125 last | > time I looked, it's by far the most preferable solution unless you're | > a total pauper. | | (I'd recommend -fswitch. (I don't know the gcc equivalent.)) | | This strikes me as a somewhat arrogant attitude. There are several | perfectly good reasons why the user may not be able to do this. | | [[And much more flamage and non-linear verbage.]] Jesus man, chill out. First off, I run all these machines and it's my job to recommend what's best for these users in my view. That is after all what I'm paid for. Second of all, in this particular case there were only a few out of dozens of workstations that I support that didn't have 68881s. I see no reason to penalize all those other dozens of workstations for the benefit of a few under equipted workstations. Go to bed and get rested. You're way to tense. Casey
name@portia.Stanford.EDU (tony cooper) (02/17/90)
Another good reason to use fswitch is that the user may have a better floating point accelerator than the 68881 and fswitch lets that be used instead (the compiler has -fsky and -ffpa options as well as -f68881).
rowe@cme.nist.gov (Walter Rowe) (02/20/90)
OK, here are the responses I have gotten concerning whether you should or should not compile the X11R4 library code with the -f68881 option. The general concensus seems to be that you don't use this option because not all machines have the MC68881 floating point hardware. However, at my site I know that all the sun3 machines do have this, so I have opted to go ahead and use this option. I have other software that requires floating point anyway, so thats the way I am going to go. Others are welcome to read these responses and use them as they like. I would like to thank those who responded for taking the time to do so. Once again, the net has proved to be an invaluable source of information. Thanks to all! Walter Rowe <rowe@cme.nist.gov> ====================================================================== On Mon, 12 Feb 90, stolcke@jade.berkeley.edu (Andreas Stolcke) said: Andreas> I guess the only reason is that when you have different Andreas> machines on your network, both with and without 68881 Andreas> coprocessors, you don't want to keep two versions of the Andreas> libraries. Compiling with software floating point gives you Andreas> one set of libraries all can use, and since there is not much Andreas> FP intensive stuff in the libs anyway (is there?) that won't Andreas> even hurt your performance. Andreas> BTW, this issue is sort of independent of wether you use cc Andreas> or gcc to compile, both allow you to choose between Andreas> soft-float and 68881 support. cc, however, has the Andreas> additional possibility of switching things and run-time (the Andreas> -fswitch option). ====================================================================== On Tue, 13 Feb 90, mcmacken@watserv1.uwaterloo.ca (John R. F. McMacken) said: John> I used -f68881 on a Sun 3/60 SunOS 4.0.3. No problems so far ... ====================================================================== On Tue, 13 Feb 90, datri@convex.com (Anthony A. Datri) said: Anthony> Not all machines have 68881's -- they were optional for 50's and 60's. ====================================================================== On Tue, 13 Feb 90, mgf@Neon.Stanford.EDU (Michael G. Fitzpatrick) said: Michael> The reason that you do not want to use this flag when Michael> compiling libraries is that every program you may create Michael> later will have to be compiled with this -f68881 flag in Michael> order to successfully link with your libraries. To avoid Michael> this, it is better not to compile with -f68881. By the way, Michael> using gcc with the -m68881 flag does not cause this problem. ====================================================================== On Tue, 13 Feb 90, carlson@lance.tis.llnl.gov (John Carlson) said: John> 1) Sun 3/50s don't have floating point. John> 2) Very little of the server code is floating point, anyway.