Hi david

 >> Yep, I believe you. I'm trying to do some signal processing
 >> on sound files. I've got it working nicely under QuickC but
 >> it is terribly slow. Lots of multiplications of floats
 >> required, which presumably means lots of reading and writing
 >> the floats in memory. What I need is a 32 bit compiler so
 >> that floats can be handled in registers.... don't I?

 dn> 32-bit registers may help a little, but not much in this case. What you want 
 dn> is a coprocessor and a compiler which can inline it. Unfortunately all the 
 dn> Borland and Microsoft compilers do is a little bit of inline floating point, 
 dn> but the vast majority of floating point operations are still library calls. 
 dn> You do get  a faster library by linking in the 80X87 library rather than the 
 dn> emulation library, but there's still the overhead of function calls. Your 
 dn> best bet then is to pull out the optimiser and find the well-trodden paths 
 dn> and rewrite it all in assembler. Since I know you're no stranger to assembly 
 dn> language, you'll probably feel more comfortable with that anyway. :-)


Hmmm, this has got me thinking. I rather figured that C, being such a
clever language, would do all the hard work for me, but looks like I've got
a little more to learn here! 
I have a 486DX so the coprocessor should be doing the work... right?

Encouraged by your message I decided to look into what QuickC was actually
doing with my floating point maths. Eeek! Shock horror! What did I find but
a whole lot of INT instructions!!! Double EEK!

Well no wonder it is going so slowly. Trying to find info about QuickC is a
rather roundabout affair, and after scouring the manuals for information
about the compiler and linker switches I finally found most of the
information in the online help file. It mentions specifying to the compiler
that you want to use the copro using the /FPi87 switch. But this still just
puts the copro library in, and each simple floating point operation still
involves many INTs to call the copro library. How very silly!

As for doing it in assembler, I am trying to avoid that. The whole point of
doing this stuff in C is so that I can concentrate on the algorithms and
develop stuff quickly via experiment. I'm trying to get reliable results
quickly. I'll go for the really quick results later. Besides that, I have
very little experience with the copro and even less at using inline
assembler with C. Although I'm confident that I could make it run a lot
faster than it currently does the real answer is to get hold of compiler
package that isn't so very silly.

 >> Will the GNU compiler help?

 dn> In this case, yes, since the 80X87 is supported directly by the compiler.

Hmmm, interesting. Will it make use of 32 bit registers too? (running under
OS/2) Or is it still 16 bits only.

 >> processed. And that is _very_ slow at the moment. I'm sure
 >> that it could be much quicker if the compiler knew how to use
 >> my 486.

 dn> Yup. :)

I hope you're right! It's quite pathetic at the moment. It takes about 10
minutes to do a few seconds of high quality audio. Mind you, that compares
well with the 10 hours required when I tried it with REXX. 

What commercial compiler package would give good floating point maths results?
In the meantime, who's got the GNU C package for OS/2 up here in Brisbane?

Simeon.

--- Sqed/32 0.87/r15030