Floating point curiosity

[Paul Dixon]

Dear all,
I always assumed that the FPU was only used if I explicitly used floating point maths in my code but I've always had an FPU so I'd never tested it. Last week I came to run a PB3.5 program on a 486SX machine with no FPU. The program has NO floating point in it, it's mostly ASM and the only PB code is to count how many times the ASM code has run and print it. The machine reports 'No 8087' as expected. I tried "set 87=true" to fool it into starting the program, but it then crashes. If I compile with the Emulated maths package the code runs very slowly, if I compile it with the Procedure maths package it's 25% faster, but still MUCH slower than it should be. If I swap the 486SX for a same speed 486DX which has an FPU then the program runs at around the speed I'd expect (5 times faster than on the 486SX) but there is still a slight speed penalty if compiled using Procedure FP.
Now the questions. Why is the execution time varied at all by changing from Emulated FP to Procedural FP when there is no use of floating point in the program? How can swapping the 486SX2-50 for a 486DX2-50 (the only difference I'm aware of is the Hardware FPU) cause the speed of program which uses NO Floating Point to increase 5 fold?

Thanks,
Paul.

[Mel Bishop]

It all comes down to WHERE the number crunching actually takes
place. The math-co in a DX processor is designed and optimized
to do the math and the processor automatically sends this info
to the math-co for processing and gets the results. In an SX
machine, since the math-co is disabled or not there, the CPU
itself has to do the number crunching. Since the CPU is not
really optimized for number crunching (i.e. math) things are
naturally slower.


------------------

[Paul Dixon]

Dear all,
I found the problem by disassembling the resulting exe file. Although I was VERY careful to avoid any floating point maths and even any non-integer variables, I did have a single instruction, incr n&& , which incremented a quad integer. It appears that PB3.5 uses the floating point unit to do this. Worse, it takes 5 times longer to do this one increment in the absence of FP hardware than to run the 70 ASM instructions I was looping around. Changing this one variable to n& speeded things up 600% and now Procedure or Emulator options make little difference.

Paul.