While browsing through stuff, I noticed that some arithmetic will lead to wrong results if LOWPART and MIDPART are set to different values (not the case right now, but better safe than sorry). More concretely: both l and m use MIDPART in their calculations where LOWPART would be required. And l is calculated overcomplicated. As another note: I have not managed to compile to assembly code in order to check, but I should be surprised if the declaration of h,l,m as unsigned char instead of int would actually be of any benefit on a 32-bit processor. It introduces a dependency on the exact ranges of LOWPART and MIDPART and will usually lead to slower code (unless the optimizer manages to revert the "optimization" of the programmer). -- David Kastrup
David Kastrup wrote:
While browsing through stuff, I noticed that some arithmetic will lead to wrong results if LOWPART and MIDPART are set to different values (not the case right now, but better safe than sorry). More concretely: both l and m use MIDPART in their calculations where LOWPART would be required. And l is calculated overcomplicated.
The code is waiting to be replaced by a nibble-base solution with a pre-initialized maximum value (depth), but thanks anyway. Taco
participants (2)
-
David Kastrup
-
Taco Hoekwater