I haven't done any benchmarks yet, so I'm afraid I can't give you any numbers yet.

Free42 Decimal for PalmOS does not use the 68k's BCD instructions; it uses a set of C++ classes that implement base-10000 floating point using binary integer math. There is still some performance optimization left to do -- replacing 32-bit operations by their 16-bit equivalents wherever possible -- and that should help speed things up.

Theoretically, the impact of using Decimal vs. Binary should be less on the Palm than it is on the PC, since even the Binary version has to do all its floating point in software on the Palm (using MathLib). In practice, the Decimal version is still going to be significantly slower than the Binary. Whether or not it is fast enough is something everyone should try for themselves... As I said, I haven't done benchmarks yet, but I expect performance comparable to a real HP-42S on recent Palm models. I'll run some tests and post the results here in a few days.

UPDATE: I ran a couple of quick-and-dirty tests on my Palm Zire 21, and SIN runs at about the same speed as on my real HP-42S; INVRT is about 4 times faster than on the 42S.

SOLVE performs poorly, though -- about 10 to 15 times slower than on the real 42S. I guess I could blame Free42's higher precision for part of that (assuming linear convergence, Free42 will take twice as many iterations to converge than the 42S, because its mantissa has twice the digits) but it probably has to do with the fact that the transcendental functions in Free42 Decimal are only accurate to about 20 digits, which means they behave erratically in the final stages of convergence -- and that can force the solver to do dozens of additional iterations.

I have to look into the SOLVE issue a bit more. The solution may be to make it stop iterating once the 20th digit has settled down (instead of going all the way) -- or to change the transcendentals to be more accurate. Stay tuned!

UPDATE 2: I repeated my SOLVE benchmark (which makes heavy use of trig functions), this time after adding FIX 11 RND at the end of the function. With that modification, Free42's performance was on par with my real 42S (again, running Free42 Decimal on my Palm Zire 21, which has a 126 MHz ARM).

Changing Free42 Decimal's trig functions to be accurate to the full width of the internal representation will probably slow them down by only 20-25% or so, so that looks like the best way to fix this.

Meanwhile, if you find SOLVE to be too slow, I'd recommend adding FIX 11 RND (or SCI 11 RND) at the end of the function to be solved: the RND function rounds a number to the precision at which it is displayed, so FIX 02 RND rounds a number to the nearest one-hundredth, while SCI 02 RND rounds a number to 3 significant digits.

On a 16 MHz 68k Palm (like the m100, for example), performance will probably be about 5 times slower than on the Zire 21 -- at least, that's been the typical slowdown in my previous tests. This means that you're looking at HP-41 performance... Hopefully I can get even those old Palms to perform at 42S performance levels with some performance optimization in the BCD code.

- Thomas

*Edited: 27 Feb 2006, 7:53 p.m. *