burton@server2.cs.psu.edu (Brian T Burton) (03/28/91)
The problem isn't the compiler at all, it's the subroutines in libm.a. (The compiler doesn't generate inline instructions for fsin etc unless the macro INLINE_MATH is explicitly defined). libm.a contains stub routines that contain the fxxx instructions. To speed things up, write your own versions of the functions that you need and call them instead of using libm. So does anyone know if there is source code for a good math library available on the net? Does GNU have on?
bennett@mp.cs.niu.edu (Scott Bennett) (03/28/91)
In article <s4cGl=da1@cs.psu.edu> burton@server2.cs.psu.edu (Brian T Burton) writes: > >The problem isn't the compiler at all, it's the subroutines in >libm.a. (The compiler doesn't generate inline instructions for fsin >etc unless the macro INLINE_MATH is explicitly defined). Well, I don't know about 2.0, but 1.0a's math.h generates the in-line transcendentals. > >libm.a contains stub routines that contain the fxxx instructions. Not unless 2.0 is screwed up. libm.a is supposed to contain the BSD math library. On a 68030/68882, libm.a takes about three times as long to calculate transcendentals as the in-line Fxxx instructions do. >To speed things up, write your own versions of the functions that No. Jeesh... >you need and call them instead of using libm. I don't think this should be necessary for most people. Simply comment out any #include <math.h> lines that you find and then compile with the -lm option added to your cc command. This will cause the compiler to generate function calls rather than assemble the Fxxx instructions in-line and will result in the BSD math library routines being linked into the executable module. As someone else pointed out weeks ago in this group, the BSD routines were written for VAXes, so the limits on the exponent range that the routines can handle are the same as the limits in the VAX hardware, which are much smaller than the limits of the 68882. However, for most people's purposes, they should be adequate. Perhaps this matter should be addressed in the FAQ article. It seems to be a recurrent issue. > >So does anyone know if there is source code for a good math library >available on the net? Does GNU have on? Scott Bennett, Comm. ASMELG, CFIAG Systems Programming Northern Illinois University DeKalb, Illinois 60115 ********************************************************************** * Internet: bennett@cs.niu.edu * * BITNET: A01SJB1@NIU * *--------------------------------------------------------------------* * "Well, I don't know, but I've been told, in the heat of the sun * * a man died of cold..." Oakland, 19 Feb. 1991, first time since * * 25 Sept. 1970!!! Yippee!!!! Wondering what's NeXT... :-) * **********************************************************************
burton@udun.endor.cs.psu.edu (Brian T Burton) (03/28/91)
>>The problem isn't the compiler at all, it's the subroutines in >>libm.a. (The compiler doesn't generate inline instructions for fsin >>etc unless the macro INLINE_MATH is explicitly defined). > > Well, I don't know about 2.0, but 1.0a's math.h generates the >in-line transcendentals. Actually, if you look at the code generated by cc without the -DINLINE_MATH option set, you'll see that it generates function calls. >> >>libm.a contains stub routines that contain the fxxx instructions. > > Not unless 2.0 is screwed up. libm.a is supposed to contain >the BSD math library. On a 68030/68882, libm.a takes about three >times as long to calculate transcendentals as the in-line Fxxx >instructions do. Actually, this is precisely what libm.a on 2.0 contains: ~ : 102 >otool -tv '/usr/lib/libm.a(trig.o)' /usr/lib/libm.a(trig.o): Text segment _sin: 00000000 linkw a6,#0x0 00000004 fmoved a6@(0x8:w),fp0 0000000a fsinx fp0 0000000e fmoved fp0,sp@- 00000012 movel sp@+,d0 00000014 movel sp@+,d1 00000016 unlk a6 00000018 rts _cos: 0000001a linkw a6,#0x0 0000001e fmoved a6@(0x8:w),fp0 00000024 fcosx fp0 00000028 fmoved fp0,sp@- 0000002c movel sp@+,d0 0000002e movel sp@+,d1 00000030 unlk a6 00000032 rts _tan: 00000034 linkw a6,#0x0 00000038 fmoved a6@(0x8:w),fp0 0000003e ftanx fp0 00000042 fmoved fp0,sp@- 00000046 movel sp@+,d0 00000048 movel sp@+,d1 0000004a unlk a6 0000004c rts 0000004e nop As you can see, these are not function calls, but stub routines which use the fxxx instructions. So I guess things are 'screwed up'. ++Brian
bennett@mp.cs.niu.edu (Scott Bennett) (03/29/91)
In article <b7aG4l#a1@cs.psu.edu> burton@udun.endor.cs.psu.edu (Brian T Burton) writes: >>>The problem isn't the compiler at all, it's the subroutines in >>>libm.a. (The compiler doesn't generate inline instructions for fsin >>>etc unless the macro INLINE_MATH is explicitly defined). >> >> Well, I don't know about 2.0, but 1.0a's math.h generates the >>in-line transcendentals. > >Actually, if you look at the code generated by cc without the >-DINLINE_MATH option set, you'll see that it generates function calls. > I've been hobbling around all day on the bloody stump left when I chewed everything off up to the ankle last night. When I got home, I did look at math.h and did see the cpp variable. In 1.0a, though, it is called NO_INLINE_MATH, and its use is the opposite. I.e. if you want function calls, you put -DNO_INLINE_MATH on your cc command. That is definitely better than what I recommended, namely, commenting out the #include <math.h> lines, which is sort of throwing the baby out with the bath water. >>> >>>libm.a contains stub routines that contain the fxxx instructions. >> >> Not unless 2.0 is screwed up. libm.a is supposed to contain >>the BSD math library. On a 68030/68882, libm.a takes about three >>times as long to calculate transcendentals as the in-line Fxxx >>instructions do. > >Actually, this is precisely what libm.a on 2.0 contains: > > ~ : 102 >otool -tv '/usr/lib/libm.a(trig.o)' > /usr/lib/libm.a(trig.o): > Text segment > _sin: > 00000000 linkw a6,#0x0 > 00000004 fmoved a6@(0x8:w),fp0 > 0000000a fsinx fp0 > [rest of horrible mess made by NeXT deleted --SJB] > >As you can see, these are not function calls, but stub routines which >use the fxxx instructions. So I guess things are 'screwed up'. They certainly do appear to be in 2.0. I will have to check this out in 1.0a when I get home. However, all is not lost. If NeXT has truly dumped the BSD math library and substituted an impostor without hiding the original somewhere under another name, check out the bsd-sources/lib/libm directory tree at uunet.uu.net. This tree contains the source modules for the BSD libm and is available for public consumption. Get it, compile it, save NeXT's mess in case you should ever need it for anything, and replace it with the real libm. > >++Brian Scott Bennett, Comm. ASMELG, CFIAG Systems Programming Northern Illinois University DeKalb, Illinois 60115 ********************************************************************** * Internet: bennett@cs.niu.edu * * BITNET: A01SJB1@NIU * *--------------------------------------------------------------------* * "Well, I don't know, but I've been told, in the heat of the sun * * a man died of cold..." Oakland, 19 Feb. 1991, first time since * * 25 Sept. 1970!!! Yippee!!!! Wondering what's NeXT... :-) * **********************************************************************