Post Reply 
program execution speed as library vs variable HP50G
10-03-2017, 10:22 AM
Post: #8
RE: program execution speed as library vs variable HP50G

another way would be to uncover the memory bank in question, run your code there directly and then cover the memory bank.

This is a little slower than using unnamed LAMs for you routines but it does not consume any extra memory in TempOb.

However, there a couple of pitfalls (for the 50g). If you uncover a bank than it is strictly forbidden to call a FLASHPTR directly as it will crash your machine. However, it is possible (depending on the code that the FLASHPTR calls) to run some short FLASHPTR routines from TempOb by putting the FLASHPTR into a secondary, copy it to TempOb and run it from there.

It does require some overhead at the beginning but it significantly speeds up your routine, especially if your routine calls a lot of subroutines as the memory bank is uncovered.
Access is as fast, as if your library would be stored in Port0!

And yet another approach for only one routine:
Copy it at the beginning of TempOb (bottom of TEMPOB) where normally the VirtualStack resides. Then call your routine directly via ML calls – no overhead at all but you must ensure that your routine is there and valid when you call it because the O.S. might overwrite it.

Both ways are used extensively in the message library and in GUISLV/GUIMES and they significantly speed up execution.

Visit this user's website Find all posts by this user
Quote this message in a reply
Post Reply 

Messages In This Thread
RE: program execution speed as library vs variable HP50G - Software49g - 10-03-2017 10:22 AM

User(s) browsing this thread: 1 Guest(s)