HP Forums
HP 35S Memory questions - Printable Version

+- HP Forums (http://www.hpmuseum.org/forum)
+-- Forum: HP Calculators (and very old HP Computers) (/forum-3.html)
+--- Forum: General Forum (/forum-4.html)
+--- Thread: HP 35S Memory questions (/thread-9365.html)



HP 35S Memory questions - JeremyBeck - 10-25-2017 02:35 PM

I am working on my own programs for the HP35s to help me with an NCEES exam and I am trying to save on memory where applicable. I am having trouble figuring the exact memory used by equations. I read in a datafile issue that equations in programs used 3 bytes plus 1 byte for each character. Does this include instructions and numbers? I do know that instructions use 3 bytes and numbers use 35 bytes.
For example, in the following equation:
(IP(Q÷2)X180)-(COS(QX180)XB)►A
Do I calculate 3 bytes plus 1 byte x 30 characters for a total of 33 bytes or do I have to additionally add 3 bytes for each instruction IP(), COS(), etc. and 35 bytes for each number 180, 2, etc.?
In addition, other lines of my program have 180. Since numbers in program lines use 35 bytes would I save memory using π →DEG instead of 180 (6 bytes instead of 35 and using two program lines instead of one)?


RE: HP 35S Memory questions - Dieter - 10-27-2017 04:50 PM

(10-25-2017 02:35 PM)JeremyBeck Wrote:  I am working on my own programs for the HP35s to help me with an NCEES exam and I am trying to save on memory where applicable. I am having trouble figuring the exact memory used by equations.
(...)
Do I calculate 3 bytes plus 1 byte x 30 characters for a total of 33 bytes or do I have to additionally add 3 bytes for each instruction IP(), COS(), etc. and 35 bytes for each number 180, 2, etc.?

There is a simple way to check how much memory is occupied here: simply look at what MEM reports with and without that equation.

(10-25-2017 02:35 PM)JeremyBeck Wrote:  In addition, other lines of my program have 180. Since numbers in program lines use 35 bytes would I save memory using π →DEG instead of 180 (6 bytes instead of 35 and using two program lines instead of one)?

I'm not sure if any number will consume 35 (!) bytes (this can also be checked with MEM), but numeric constants in programs can often be written in several ways, and in my programs I like to use different techniques to both save memory and speed up program execution (lines with numbers are sloooow):

Instead of "0" often CLX can be used (but consider stack lift)
Instead of "1" you may use PI SGN
Instead of "2" try e IP
Instead of "3" use PI IP
Instead of "–1" try CLX NOT
etc.

So this PI R→D indeed is a good idea. You may also store some often-used constants in registers. For instance, for a statistical distributions program package I have 1 and 2 prestored in O and T , so that a short and fast RCLxT, RCL÷T, RCL+O or RCL–O can be used throughout the program. The two constants are of course coded like this:

e IP STO T SGN STO O

I assume the 180 stands for 180 degrees. This means that DEG mode has to be set. For a mode-independent setting arccos(–1) might be a better idea: CLX NOT ACOS and store this somewhere. This produces 180 in DEG and pi in RAD mode.

BTW, instead of IP(Q÷2) you may also try INT÷, which in a formula appears as IDIV(Q,2). Not sure if this saves memory, I assume it doesn't.

Dieter


RE: HP 35S Memory questions - JeremyBeck - 11-02-2017 11:07 PM

I have tried different combinations in order to see how much memory an equation uses on an HP35S and have some interesting results.
I entered an equation with just a single 0 and that took 38 bytes of memory (30,192-30,154). I also tried twenty zeros and that also took 38 bytes of memory.
I then tried the following:
Code:
(IP(Q÷2)X180)-(COS(QX180)XB)
Which also took 38 bytes of memory. When I added the store A to get
Code:
 (IP(Q÷2)X180)-(COS(QX180)XB)►A
That took 41 Bytes of memory. I then tried
Code:
0►A
Code:
 SIN(1)►A
and
Code:
COS(1)xSIN(1)
These took 38 Bytes of memory.
I have used my emulator to get these numbers. When I try an actual calculator I get 35 bytes instead of 38.


RE: HP 35S Memory questions - Thomas Radtke - 11-03-2017 02:55 PM

There are bugs about memory calculation. Try to bring emulation and hardware into the same state and compare again, if possible. Easiest way would be a reset.