buck@NRL-CSS.ARPA (08/03/84)
From: Joe Buck <buck@NRL-CSS.ARPA> Recently I ran some tests to calculate the cost of the phrase "all floating arithmetic in C is carried out in double-precision..." (K&R pp 184 section 6.2 -- to quote chapter and verse). It turned out to be really expensive. For instance, the code generated by the C compiler to evaluate "a *= b" cvtfd -12(fp),r0 muld2 r0,-20(fp) cvtdf -20(fp),-12(fp) turned out to be four times as expensive as the equivalent floating point operation mulf2 -20(fp),-12(fp) If memory is not a problem, you could declare some or all of the variables double and get rid of the cvt's, before going to a lot of trouble to convert the assembler output, or to modify the code. Since I don't see any reason why a muld2 should cost more than twice a mulf2, this should double the speed. I understand that the new ANSI standard will allow single precision computation, but it's not clear whether support for this would be required or optional. -Joe
mats@dual.UUCP (Mats Wichmann) (08/06/84)
All FP calcualtions in double? This hurts us even more on micros without FP hardware, and even WITH FP hardware. Yuck!!! We had to convert our compiler to IEEE floating point, because that is what the hardware supported. The penalty for float->double conversion is even bigger than for the DEC format floating point. The ANSI standard allows for, but unfortunately does *NOT* require, that floats can be handled as floats instead of converting to double. As someone pointed out a while back this whole thing is historical, dating back to a problem with the PDP-11 floating point instructions, and has been allowed to continue ever since.