Assorted WP-34S beginner questions

[Paul Dale]

(07-30-2014 05:44 AM)sa-penguin Wrote:  By deliberately limiting the precision to 4096 digits, and merging with 4 status bits, for example. Result fits into a 16-bit integer, instead of being spread over five bytes, and keeps al variables word-aligned.

I don't think the firmware ever uses this many digits -- the big mod function is the worst I believe which uses 820 digits. So this change should be beneficial. Be aware that bit fields are kind of expensive in THUMB mode (which we use), hence all the myriad access functions to centralise their use.

This change would reduce stack usage during computations. We've overflowed the stack a few times but not currently as far as I'm aware -- matrix and statistical distributions are the prime culprits here and I changed the internal precision on the former and moved the latter to XROM to avoid the issue. It would also save a number of bytes in the constants but not a huge number -- still every byte is precious.

Quote:There's also DECPUN (Decimal numbers per unit), which defaults to 3. Changing this should reduce the number of bytes needed to hold variables - at the expense of computing speed. According to DecNumber Tuning Parameters, anyway.

The impact of changing this is massive and detrimental. This one we did experiment with a little. The calculator is converting between DPD and decNumber formats all the time and making this a very expensive operation, which is what changing this does, hurts a lot. As mentioned above, the unpacked decNumber format isn't the problem generally.


- Pauli