> RC>    Last time I tried this sort of thing neither QuickC nor TurboC
 > RC> could do anything reliably with numbers greater than 64K.  QuickC
 > RC> wanted to consider everything as a plain int, TurboC would printf() a
 > RC> single long int, but when you tried multiple long ints in the one call
 > RC> it would get confused about where on the stack the various parameters
 > RC> were.

 > Ah! Thanks for the tip. I'd noticed some other strange things
 > with printf(), but being a beginner I presumed they were my
 > fault.

Don't take it too seriously. I can't explain what both you or Russell have
experienced, but I've used both TC 2.0 onwards and Quick C v1.01 onwards
and have _never_ had problems with printf() and longs. I can't see how
they'd be marketable, let alone passed the simplest product acceptance
tests with these sort of bugs. Quick C is MSC's "little brother",
and the only difference is the lack of the optimiser pass. I've used every
version of MSC since v4.0 (and 2.0 before that - never used 3.0) and also
never had any problems with it in this respect. The compiler wasn't - and
still isn't - bug free, but the bugs it did have tend to be obscure or
experienced as a result of being a little too liberal with optimising
switches.

Like you, I'd be inclined to assume 'user error' until I'd traced it right
into the runtime library and nailed the exact problem before writing it off
as a compiler or runtime library bug. There's already too much 'mystery of
the unknown' theorising going on where programming is concerned to
encourage it further. (Sorry, it's a sore point - I've been involved in too
many programming projects where 'I dunno why it works, but it does' type
fixes have failed myserably in the field - either it is fixed or it isn't,
and leaving a job half-done or half-explained is not doing it at all, imho.
Robust code is code you can trust because you KNOW it works, and why).


 > RC>    I recommend that you (if possible) use a professionally written C
 > RC> compiler, IMHO the GNU C++ compiler (EMX port for DOS and OS/2) fits
 > RC> the bill well.  It's available here for download or FREQ at V32bis for
 > RC> anyone who wants it.

 > 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?

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


 > Will the GNU compiler help?

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


 > The program is pretty simple, but
 > I'm trying to implement a FIR filter of 1000 or more taps...
 > which means at least 1000 float multiplications per byte
 > 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.

Yup. :)


  cheers,
  david

---