 | | floating point operation —Dennis Diehl
|
| | | I did some experiments with floating point operations and I was surprised when I tried this: int main(){ long t1; int i,j; float t; t1 = sys_time; for(j=0; j<1000; j++){ t=0.06; for(i=0; i<100; i++){ t=1.7*t; } } lcd_int((sys_time - t1)/1000); (...) (23 years ago, 28-Nov-01, to lugnet.robotics.rcx.legos)
|
| | | |
| | | | | Re: floating point operation —John A. Tamplin
|
| | | | | (...) I suspect that when you look at the assembler code produced by the compiler you will find in the first instance it was able to optimize the FP multiply out of the inner loop since it didn't depend on the loop induction variable. Ie, it simply (...) (23 years ago, 28-Nov-01, to lugnet.robotics.rcx.legos)
|
| | | | | |
| | | | | Re: floating point operation —Kekoa Proudfoot
|
| | | | (...) Compiler optimization? At least, a disassembly of similar code showed me that that seemed to be the case. The compiler can see that t is not used. Try returning t, or copying t to a global before you return from main. That will make things (...) (23 years ago, 28-Nov-01, to lugnet.robotics.rcx.legos)
|
| | | | |
| | | | | | Re: floating point operation —Kekoa Proudfoot
|
| | | | (...) I should clarify that this is true for the first version only. For some reason, the compiler does not optimize the second version in the same way. Anyways, what I see in the disassembly for the first version is a loop to 100 inside a loop to (...) (23 years ago, 28-Nov-01, to lugnet.robotics.rcx.legos)
|
| | | | |
