mjs (09/09/82)
If you wish to do large quantities of single-precision floating point calculations, then I suspect that FORTRAN is the language for you! If you wish to use C, however, the specification of what you cite as a conversion inefficiency follows (quoted from `The C Programming Language' by Kernighan & Ritchie, bottom of page 184, section 6.6 of the appendix): A great many operators cause conversions and yield result types in a similar way. This pattern will be called the ``usual arithmetic conversions.'' First, any operators of type `char' or `short' are converted to `int,' and any of type `float' are converted to `double.' Then, if either operand is `double,' the other is converted to `double,' and that is the type of the result. The passage goes on to detail the conversions for the integral data types. Please note that that appendix DEFINES the C language. What you suggest in terms of `fixing the compiler' amount to changing the semantics of the language. Martin J. Shannon, Jr. BTL MH (201) 582-3199
wje (09/09/82)
c For many machines (those with decent hardware floating point) it doesn't really slow things down too much to do all fp math in double. However, on the current generation of 16 bit micros such as z8000 and 68000 systems, you can't get fp hardware that runs fast enough to bother with. For these machines, the double fp really slows things down a lot. Onyx systems provided a switch -F for their C compiler that kept operations on single precision flts in single precision. Note that this is generally invisible to the program and does not affect portability, except to make programs slow down on some machines. I'm not saying that this is a particularly good idea, but it certianly makes some applications more practical. Incidentially, when Onyxes first came out, they had an AMD 9502 fpp chip. A few benchmarks showed that fp operations could be done faster in software! Result: no fpp chip anymore. Bill Ezell Software Innovations, Inc. decvax!sii!wje
thomas (09/09/82)
I don't mind having intermediate calculations done in double precision, but if you look more closely at the fragment of code in question, it went something like: mulf3 a,b,r0 ; multiply a*b and put the result into r0. ; note that this multiplication is done ; in SINGLE precision cvtfd r0,r1 ; change the answer to DOUBLE precision! cvtdf r1,c ; change the answer back to SINGLE precision and ; store it! Not only is this inefficient code, but it doesn't conform to the standard, either! =Spencer