esp_05@jhunix.HCF.JHU.EDU (Stdnt 05) (12/05/89)
Does anyone have any experience with GNU C and using floating point math? From my brief experiences of trying to write some 3D animation in GNU C (or should I say my brief run-in with GNU C) I have uncovered an unreasonably large number of errors in the floating point handling. Admittedly, a number of them cleared up when I stopped using -mshort, even though I used -lpml16 whenever I used -mshort. Some of the errors include: cos(0) doesn't seem to work (x*x)+(y*y) doesn't work when -1<y<0 sqrt() doesn't work (with -mshort only); neither do related functions frexp and pow. Any ideas or suggestions? After comparing GNU C with an ancient copy of the original (c.1986) Megamax C, with Megamax C blowing GNU C away, I'll probably get Laser C next month anyway. Thanks, Eric
bammi@dsrgsun.ces.cwru.edu (Jwahar R. Bammi) (12/05/89)
In article <3497@jhunix.HCF.JHU.EDU>, esp_05@jhunix (Stdnt 05) writes: >Some of the errors include: > cos(0) doesn't seem to work > (x*x)+(y*y) doesn't work when -1<y<0 > sqrt() doesn't work (with -mshort only); > neither do related functions frexp and pow. > you have a very old copy. all of the above problems in the Fp support routines and pml were fixed some time ago. please grab yourself a new copy from dsrgsun.ces.cwru.edu or from the terminator archive. >Any ideas or suggestions? After comparing GNU C with an ancient copy >of the original (c.1986) Megamax C, with Megamax C blowing GNU C away, can you be more specific. in what sense did it "blow it away"? -- bang: {any internet host}!dsrgsun.ces.CWRU.edu!bammi jwahar r. bammi domain: bammi@dsrgsun.ces.CWRU.edu GEnie: J.Bammi
esp_05@jhunix.HCF.JHU.EDU (Stdnt 05) (12/06/89)
I just downloaded the copy of GNU C from terminator, oh, two weeks ago, the same time I downloaded the pml package. Maybe I should try drgsun. At any rate Megamax C blew GNU C away in speed and executable size (GNU C took twice as long, and the executables were around twice as large). The only problem with it is that it doesn't have stdlib functions, although without those I can still improvise. Eric
7103_2622@uwovax.uwo.ca (Eric Smith) (12/06/89)
In article <3497@jhunix.HCF.JHU.EDU>, esp_05@jhunix.HCF.JHU.EDU (Stdnt 05) writes: > Does anyone have any experience with GNU C and using floating point > math? From my brief experiences of trying to write some 3D animation > in GNU C (or should I say my brief run-in with GNU C) I have uncovered > an unreasonably large number of errors in the floating point handling. > Admittedly, a number of them cleared up when I stopped using -mshort, > even though I used -lpml16 whenever I used -mshort. > You don't mention what version of GNU C you're using. The latest version (1.36) is considerably better at floating point. The libraries are also considerably improved. I don't use floating point much, so I don't know how good the pml is, but I do know that the weird errors I used to get with printf(), etc. are gone now. > > Any ideas or suggestions? After comparing GNU C with an ancient copy > of the original (c.1986) Megamax C, with Megamax C blowing GNU C away, > I'll probably get Laser C next month anyway. I purged Laser C from my hard drive a while back. I found its libraries very incomplete and somewhat buggy, and the compiler itself was frustrating. It does have a nice math library, so if you're most concerned with floating point it might be OK for you. If you do a lot of porting of code from Unix, you might also want to look at Mark Williams C, which I hear is good. -- Eric R. Smith email: Dept. of Mathematics ERSMITH@uwovax.uwo.ca University of Western Ontario ERSMITH@uwovax.bitnet London, Ont. Canada N6A 5B7 ph: (519) 661-3638
apratt@atari.UUCP (Allan Pratt) (12/07/89)
esp_05@jhunix.HCF.JHU.EDU (Stdnt 05) writes: I just downloaded the copy of GNU C from terminator, oh, two weeks >ago, the same time I downloaded the pml package. Maybe I should try >drgsun. Bammi recently put GCC 1.36 on his server -- say "gcc -v" to find out what version you're using. >At any rate Megamax C blew GNU C away in speed and executable size >(GNU C took twice as long, and the executables were around twice as >large). The only problem with it is that it doesn't have stdlib >functions, although without those I can still improvise. When you say "executable size" do you mean the size of the PRG file? That's not a good indication. There can be any amount of information in the PRG file besides the program: symbol tables, debugging information, etc. If you use -g on the GCC command line, that's your answer: it generates LOTS of info for the symbolic debugger GDB (and UN*X's dbx). The right way to find out executable size is to dump the program's header and look at the size fields. The dump will look like this: 60 1a tt tt tt tt dd dd dd dd bb bb bb bb ... 601a is a magic number. tttttttt is the text (program) size in bytes. dddddddd is the data segment size in bytes. bbbbbbbb is BSS. Compare the SUM of text + data, because GCC might be putting strings in the text segment, while Megamax might put them in the data segment. Also make sure they're both talking about the same things: use -mshort for your comparison (even if the program doesn't work that way) if Megamax has 16-bit INTs. Of course, MegaMax C has *8* bit shorts, and some required keyword concerning modules or overlays or something, so I have no respect for it at all... ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
7103_2622@uwovax.uwo.ca (Eric Smith) (12/07/89)
In article <3526@jhunix.HCF.JHU.EDU>, esp_05@jhunix.HCF.JHU.EDU (Stdnt 05) writes: > I just downloaded the copy of GNU C from terminator, oh, two weeks > ago, the same time I downloaded the pml package. Maybe I should try > drgsun. > Yes, dsrgsun has slightly more up to date versions. > At any rate Megamax C blew GNU C away in speed and executable size > (GNU C took twice as long, and the executables were around twice as > large). The only problem with it is that it doesn't have stdlib > functions, although without those I can still improvise. GNU C executables are twice as large only for small files (the library is more complicated, and not as well organized, so it has higher overhead). For larger files I would expect the GCC to produce smaller code. And yes, GNU takes longer to compile; Laser is *really* fast. On the other hand, programs compiled with GNU execute faster, and the GNU optimizer is a *lot* smarter than Megamax's (GNU knows not only when to put things in registers, but also how to change multiplications into additions inside of loops, so that "for (i = 0; i < end; i++) a[i]=foo(i);" produces the same code as "for (p = a; p < a[end]; ++p) *p++ = foo(p-a);". One other note: the library as distributed has a serious bug in the compare routine for floats. That should be fixed soon; a temporary workaround is to use doubles instead of floats. This may have been causing your problems. -- Eric R. Smith email: Dept. of Mathematics ERSMITH@uwovax.uwo.ca University of Western Ontario ERSMITH@uwovax.bitnet London, Ont. Canada N6A 5B7 ph: (519) 661-3638
piet@cs.ruu.nl (Piet van Oostrum) (12/11/89)
In article <4470.257da18c@uwovax.uwo.ca>, 7103_2622@uwovax (Eric Smith) writes:
`
`One other note: the library as distributed has a serious bug in the compare
`routine for floats. That should be fixed soon; a temporary workaround is
`to use doubles instead of floats. This may have been causing your problems.
`--
I published a patch for this problem a month or so ago.
Here is the new source for ___cmpsf2:
.text
.even
.globl ___cmpsf2
___cmpsf2:
movel sp@(4),d0 | get a
movel sp@(8),d1 | get b
bpl cmpsf2_p
tstl d0
bpl cmpsf2_p
cmpl d1,d0
bgt cmpsf2_m
blt cmpsf2_1
cmpsf2_z:
clrl d0
rts
cmpsf2_p:
cmpl d1,d0
bgt cmpsf2_1
beq cmpsf2_z
cmpsf2_m:
movel #-1,d0
rts
cmpsf2_1:
movel #1,d0
rts | sigh
--
Piet* van Oostrum, Dept of Computer Science, Utrecht University,
Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands.
Telephone: +31-30-531806 Uucp: uunet!mcsun!hp4nl!ruuinf!piet
Telefax: +31-30-513791 Internet: piet@cs.ruu.nl (*`Pete')