Buyers remorse of HP 48

[Jonathan Busby]

As others have stated, in terms of HP calculators that use HP in-house designed custom CPUs, the Saturn based calculators are the fastest in terms of overall raw speed. But, the UI / GUI is slower due in part to the fact that there's much more for the CPU to do to display a proper graphical GUI on the 131x64 pixel display ( and there's no GPU ), whereas one or two line HP calculators have much less to deal with when it comes to the UI / GUI. But, this isn't the main reason that the HP48 series GUI is slow : It's slow due to mainly three different things. Firstly, the GUI on the HP48 series makes heavy use of slow Sys-RPL routines under the hood, especially ones that operate on composite objects ( Particularly lists, and also "meta" objects on the stack produced by =INNERCOMP ) and also slow Sys-RPL local variable accesses. Secondly, said GUI code isn't very efficient in terms of minimizing "junk" or intermediate composite objects in TEMPOB, which leads to more garbage collections, and this leads to further slow-downs / pauses. Thirdly, said garbage collection events are *slow* due to the naïve algorithm used.

Years ago, when I posted a Saturn assembly language fix to the HP49 list-processing bug, I went even further and re-wrote the entire HP48 list-processing subsystem in mostly Saturn assembly ( although the code hasn't been published ). I did test the code and the speedup was *massive*

Also, the way the HP48 series garbage collector is implemented in Saturn assembly is *slow*. It performs *four passes* ( technically *seven* passes, but I'm keeping it simple here ) over TEMPOB :

1. The first pass iterates over all TEMPOB memory slots and modifies each one's link / marker field so that the end of the TEMPOB slot can be detected during the GC.
2. The second pass performs a mark-and-sweep over said TEMPOB slots using all the root pointers and adjusts pointers that reference addresses in TEMPOB accordingly to reflect their new addresses after TEMPOB has been compacted.
3. The third pass removes unreferenced TEMPOB slots which involves a lot of slow memory block moving.
4. The forth pass once again iterates over the ( now compacted ) TEMPOB slots and modifies each slot's link / marker field and returns it back to its usual form.
   

The above, in addition to being slow in general, has a worst case running time of \(O(n^{2})\) due to the method used to check if the TEMPOB slots are still referenced. Now, garbage collection, even a simple mark-and-sweep algorithm, doesn't have to be this slow. A long time ago I also re-wrote the GC algorithm in two different ways that sacrificed a little memory space for a *huge* speed-up, and I reduced the worst case running time to only \(O(n)\) or \(O(n \cdot log(n))\), depending on the version used. One version used a kind of direct-mapped hash ( the \(O(n)\) version, but it used much more memory during the GC operation** ) and another version used a type of self-balancing binary search tree ( the \(O(n \cdot log(n))\) version, which used much less memory during the GC operation ). I did test both algorithms and the tests demonstrated that the new algorithms were much, much faster.

( ** NOTE : I did play around with using free memory in a bank in port 2 as scratch memory for the GC algorithms, although I never really finished implementing it )

In conclusion, I think that the original HP48 software dev team cared more about space than speed, and that is why the HP48 is sluggish when it comes to the GUI. I'd recommend that you install Raymond Del Tondo's awesome SpeedUI library if you can get your hands on an HP48G/G+/GX

Regards,

Jonathan