HP Forums

Full Version: Slow HP48GX
You're currently viewing a stripped down version of our content. View the full version with proper formatting.

Sometimes after running a lot of programs my GX tends to get extremely slow. I can come out of this by doing a warm start.. ON and C together. Is there a reason for the sluggish behavior?

Are these programs leaving a lot of stuff on the stack? If so, clearing the stack probably will speed it up without having to do a warm start.


I observed this behavior when running thirdy-part programs written in SYS RPL or Assembly. And although Wayne is completely correct calling the attention to "trashed" data stuffing the stack (that would indeed slow the calculator down), I'd like to know if programs written this way are able to create variables or to "slice" memory in a way that the used space is not claimed back after the programs resume execution. If so, I guess that a warmstart would do. Anyway, are you willing to perform a test I was not able to so far? Before executing a warmstart, try [MEM], [ON][C] and [MEM] again. If the first [MEM] fix things out, you'll probably notice that the calculator is running in regular speed. If not, please check if the amount of free memory from the second [MEM] is bigger than the first one (I guess it will be).

And please, let us know what did you get!


Luiz (Brazil)

Luiz, you found the problem. After running the problem continuously I found that there was 1032 bytes less. Each time I run the program after that there was still less bytes available until I 'Killed' the program. Then it cam back to the original memory. Thanks. Even though the program created local variables it was just halted and this appears to have the 'variales ' in memory still.
Thanks, now all I'll do is include a 'KILL' function at the end of the program.

Hi, Rick;

That's good news. Anyway, there's something else to add to this particular fact you wrote about. Try this program: please, type it in and save it with any name.

« HALT 1 100 FOR X

Run it after saving it; it will halt prior to execute any command, right? At this very moment, purge it from memory. The program no longer exists, right? But the HALT indicator is still there. So go for it: press [left_arrow][CONT] and... What the h...!

Yeap! Any program you run in fact is copied in RAM and the copy is the one used to perform the program operations. I found this when debugging a program (late 80's) in an HP48SX and I realized that the altered program was not the one used after being saved, instead the original one. It was necessary to KILL program execution and start it again so the alterations made became effective. Than I tested the purging procedure I suggested above and I found that, in fact, the program is copied and maintained till it ends or is stopped. A halted program means a copy of it stored in memory and ready to go ahead.

Interesting, isn't it? You can write a program that purges itself as the first step and it will run anyway. Is it an impression of mine or I'm actually feeling some eyes widely open here...>>>8^O


Luiz (Brazil)

Edited: 31 May 2004, 11:54 a.m.

True. At least, it won't be completely removed from memory as long as there's a pointer to it (or any element of it) on the stack. For example, with a program stored in 'TempVar', you can start it with \<< 'TempVar' PURGE .... This is useful for running programs on a Kermit server from another calculator with the PKT command or from a Kermit program using REMOTE HOST, when the sequence is too many bytes for a single host command packet. For example, you can use the sequence 'TempVar' SEND "TempVar" "C" PKT.


Maybe the program in question had a HALT command inserted for debugging purposes? If so, then just edit out the HALT. Or use LeftShift CONT (on the [ON] key) to resume execution of a suspended program. Using KILL in a program will work, but it's rather drastic, as it applies to all suspended programs, not just the current one.