Optimized Stack Operations - Printable Version +- HP Forums (https://www.hpmuseum.org/forum) +-- Forum: HP Calculators (and very old HP Computers) (/forum-3.html) +--- Forum: General Forum (/forum-4.html) +--- Thread: Optimized Stack Operations (/thread-12502.html) Pages: 1 2 |
Optimized Stack Operations - deetee - 02-25-2019 06:35 AM Hello all! I'm developing a scientific RPN calculator with OLED Display, ATTINY85, 16 keys and a CR2032 battery - and I'm almost done. As (flash) memory is (always) short (8.192 bytes) I have to implement a lot of functions by using the calculator itself (and not some bloated math library). This can be done by calling basic subroutines (one byte commands) for stack operations. For example to calculate the cosine of x (cos(x)) I have to use the (intrinsic) sine function and calculating sqrt(1-sin(x)*sin(x)) with stack operations - and use these steps: Code: SIN ENTER * CHS 1 + SQRT Many other functions are implemented like this: Code:
This already works but it is far from beeing optimized - because I'm not really a specialist in stack operations. Unfortunately every operation costs 2 bytes of flash memory - and - slows down the code execution (running with a slow framerate (to save battery power) of 10 fps every calculation step needs 100 milliseconds). So please help me to optimize those stack operations - every better sequence of commands or any idea is highly appreciated. Thanks in advance. deetee RE: Optimized Stack Operations - ijabbott - 02-25-2019 07:57 AM Couldn't you call a common subroutine to handle both sine and cosine? They are nearly the same apart from an x offset. RE: Optimized Stack Operations - grsbanks - 02-25-2019 08:03 AM OLED display running off a CR2032? What kind of battery life are you expecting to get out of that? RE: Optimized Stack Operations - deetee - 02-25-2019 08:42 AM Power management is essential - so I implemented automatic dimming, display off and finally deep sleep. Running on a single battery (CR2032) my calculator draws a current of 10 mA (bright display with a lot of "8s"). With a battery capacity of at least 200 mAh it can calculate approximately 20 hours. After dimming the current falls to 5.5 mA, after deactivating the display 1.1 mA are needed. In sleep mode it consumes less than 0.25 mA. With a battery capacity of at least 200 mAh it lasts more than a month in sleep mode. And finally I plan to use 2 (parallel) batteries. RE: Optimized Stack Operations - Thomas Klemm - 02-25-2019 08:45 AM (02-25-2019 07:57 AM)ijabbott Wrote: They are nearly the same apart from an x offset. It was also my idea to use \(\cos \theta = \sin \theta + \frac{\pi}{2}\): Code: PI Maybe you already keep \(\frac{\pi}{2}\) as a constant. Another benefit is that you don't have to deal with the sign of the square root if \(\cos \theta < 0\). Cheers Thomas RE: Optimized Stack Operations - deetee - 02-25-2019 09:04 AM Wow - I did not expect to be so blind in this early stage. Now I calculate COS with: Code: CHS 90 + SIN I'm looking forward when you improve my GAMMA-function. :-) Thanks RE: Optimized Stack Operations - grsbanks - 02-25-2019 09:14 AM Exactly how are you calculating sin()? If you're using CORDIC then it should produce both sin() and cos() simultaneously anyway, thus giving you tan() as well while you're at it. RE: Optimized Stack Operations - deetee - 02-25-2019 09:45 AM Actually I'm using something odd - but it makes sense for saving memory: I use one subroutine to calculate exp(), sin() and asin() - all have "similar" Taylor polynoms: Code:
RE: Optimized Stack Operations - grsbanks - 02-25-2019 09:50 AM But by using this and therefore the stdlib math library (I see a "double" type in there), you're far from saving memory! Using CORDIC you just need a few constants and everything is calculated using addition, subtraction, bit shifting and table look-ups. Not a float or double in sight. RE: Optimized Stack Operations - deetee - 02-25-2019 09:57 AM I didn't know CORDIC - but it seems very interesting. Do you have a good link for programming CORDIC? - WIKI seems to be to "theoretical". Thanks for the hint. RE: Optimized Stack Operations - grsbanks - 02-25-2019 10:00 AM I can't remember exactly where I found it but I did find documentation on the 'net that enabled me to write my own math library with up to 24 digits of precision. It's there if you look in the right places It's not yet ready for prime time because, well, life kind of took over a while back, but when it is ready it'll be open source. RE: Optimized Stack Operations - grsbanks - 02-25-2019 10:09 AM This document was a great help to me. RE: Optimized Stack Operations - Leviset - 02-25-2019 12:37 PM Do a search on Cordic in the Forum as there many, many references RE: Optimized Stack Operations - Thomas Klemm - 02-25-2019 03:19 PM (02-25-2019 09:04 AM)deetee Wrote: Now I calculate COS with: You can also use: Code: 90 + SIN Quote:I'm looking forward when you improve my GAMMA-function. :-) Viktor T. Toth has implemented the Gamma function for a lot of calculators. So you might find some inspirations. Cheers Thomas RE: Optimized Stack Operations - Thomas Klemm - 02-25-2019 03:26 PM (02-25-2019 09:57 AM)deetee Wrote: Do you have a good link for programming CORDIC? - WIKI seems to be to "theoretical". This might be something for you: Exploring the CORDIC algorithm with the WP-34S Cheers Thomas RE: Optimized Stack Operations - rprosperi - 02-25-2019 08:04 PM While your question is broad and there are many ways to contribute (as you see above) one reference tool that may be useful is Tony Hutchins' XYZT Tables document, which shows the quickest way (least number of basic RPN instructions) to go from one stack configuration to another. It's much harder to explain than it is to grasp once you see it. Gene shared a link here. A must-have document when dealing with stackrobatics. RE: Optimized Stack Operations - Massimo Gnerucci - 02-25-2019 09:03 PM (02-25-2019 08:04 PM)rprosperi Wrote: While your question is broad and there are many ways to contribute (as you see above) one reference tool that may be useful is Tony Hutchins' XYZT Tables document, which shows the quickest way (least number of basic RPN instructions) to go from one stack configuration to another. It's much harder to explain than it is to grasp once you see it. Not working anymore. Use Pedro's instead RE: Optimized Stack Operations - rprosperi - 02-25-2019 09:49 PM (02-25-2019 09:03 PM)Massimo Gnerucci Wrote: Not working anymore. Thanks for fixing that Massimo. I actually uploaded a copy of the PDF to OneDrive to share, and then thought 'hey, someone must have done this before now', then searched and found Gene's post and saw the thread had other discussion that may be of interest to the OP, so just posted that link. Absolutely should have verified the link first though... (smacking forehead). RE: Optimized Stack Operations - deetee - 02-26-2019 06:57 AM (02-25-2019 03:19 PM)Thomas Klemm Wrote: Viktor T. Toth has implemented the Gamma function for a lot of calculators. This helped me a lot - now I calculate GAMMA with a shorter and more "stack friendly" formula (with a precision of at least 3 digits): Code: GAMMA (due to formula of Nemes) But I still think that some bytes are to save with optimized stack handling. Thanks RE: Optimized Stack Operations - Thomas Klemm - 02-26-2019 09:16 AM (02-26-2019 06:57 AM)deetee Wrote: But I still think that some bytes are to save with optimized stack handling. Code: 1 + ENTER ENTER ENTER 12 * ROTup 10 * INV – INV + If there's also a SWAP or X<>Y command some of the ROTup commands could be replaced. Cheers Thomas |