Has anybody else noticed that PBPL (PBP2.50a) multiply and divide routines are ALL 32 bit?
I was running my latest program tonight trying to figure out why it was quite a bit slower than it used to be. Come to figure out that all of that math that I thought I might be saving by not using DIV32 gets used up by the new 32 bit routines...
Not that it's a bad thing...but...
Heck, only a few of the calculations I do in the program really NEED the full 32 bits of precision. Most of them are byte/byte or word/byte, very few are Long/Long or Long/Byte.
I did some quick figuring by looking at my .lst file for an 18F4620 using the new 32 bit routines.
IF my figuring is right, a 32/32 bit divide can take anywhere from 628 - 1868 cycles.
32/32 bit multiply, up to 298 cycles.
neither of those figures include setting up the system variables, jumps into and out of the routines and any housekeeping that PBP does, so they're obviously longer.
If I'm doing word/byte division, I figure it should only take roughly 388-1028 cycles. Quite a bit of savings to be had there.
In my case especially. My loop can only run about 4 times per second as it is, mainly because of all of that 32 bit math involved (92 divisions/mods, 35 multiplies, numerous adds and subtracts, and a handful of shifts that already take the place of ^2 multiply/divides).
So, I guess my question is, can I have my cake and eat it too? Short of writing extra math routines on top of PBP's built-in routines, is there any way to short-circuit PBP into using quicker methods that don't use all 32 bits while keeping the option open to using all of those 32 bits?
Bookmarks