External stack

Contributions to this software library are always welcome. Please ensure that you post program listings rather than .raw files. They give a reasonable idea of what your program does without having to load them into a DM42 and you can also include comments in your code. Check out the following link for a decoder/encoder: http://www.swissmicros.com/dm42/decoder/

You can then copy/paste the listing and post it in "code" tags.
Thomas Okken
Posts: 618
Joined: Tue May 02, 2017 3:48 pm
Contact:

Re: External stack

Post by Thomas Okken » Sun Apr 14, 2019 3:01 pm

mcc wrote:
Sun Apr 14, 2019 1:26 pm
In this context I would like to suggest a "LMVAR" command, wich works similiar
to the LSTO-command and would create variables which evaporize into thin
air, when the program has ended.

Would this be possible?
Yes, that's possible, and you don't even need a new command for it.
Say you have a function FOO with MVAR parameters X, Y, and Z. You want to set X to 123 and Y to 456, and solve for Z with starting guesses 10 and 20.
In a program, you would do this:

Code: Select all

PGMSLV "FOO"
123
LSTO "X"
456
LSTO "Y"
10
LSTO "Z"
20
SOLVE "Z"
Note that this would not work in RUN mode, since the stack, including all local variables, is cleared when you execute GTO, XEQ, RTN, SOLVE, or INTEG from the keyboard.

mcc
Posts: 211
Joined: Fri Jun 23, 2017 3:10 am

Re: External stack

Post by mcc » Sun Apr 14, 2019 5:24 pm

Hi Thomas,

if I understand it correctly, this would make the coding of the calling
program, which uses PGMSLV, dependant on the nameing and the count
of the program FOO.
So (for example) I had to reprogram a plotting program each time
the function to be plotted uses another set of variables.

And -- as you already mentioned -- MVAR called in a program directly
(RUN mode) will still "pollute" the memory with its leftovers.

My intention was just to prevent this.

Cheers,
mcc
DM 42 - SN: 00373, Firmware v.:3.14. / 3.14. as compiled by SwissMicros

Thomas Okken
Posts: 618
Joined: Tue May 02, 2017 3:48 pm
Contact:

Re: External stack

Post by Thomas Okken » Sun Apr 14, 2019 6:21 pm

mcc wrote:
Sun Apr 14, 2019 5:24 pm
if I understand it correctly, this would make the coding of the calling
program, which uses PGMSLV, dependant on the nameing and the count
of the program FOO.
Correct. There's no way around that.
mcc wrote:
Sun Apr 14, 2019 5:24 pm
And -- as you already mentioned -- MVAR called in a program directly
(RUN mode) will still "pollute" the memory with its leftovers.
True. There's no mechanism for creating global variables that magically disappear when you are done with them. I guess that might take the form of directories, where you create a work area, and create the variables you need there, and finally delete the directory and all its contents once you are done with it.

Directories are on my "nice to have but still not convinced that the rather large effort is worth it" list.

User avatar
wiljea
Posts: 13
Joined: Tue Sep 04, 2018 4:20 pm

Re: Local variables & partial stack preservation

Post by wiljea » Wed Nov 13, 2019 7:18 am

For an interesting application of LSTO to realise a temporary partial preservation of the stack before any intermediate calculation see my working example of nov 12 at viewtopic.php?f=19&t=271#p12423.

For the purpose of calculating some new quantity (ending in the X register) derived from other physical constants (by internal calls in the same program), I had to developed simple Push (“PshST”) and Pop (“PopST”) subroutines to reinstate the unperturbed remaining stack (Y, Z, T and LastX registers) through the use of temporary local variables (“Ys”, “Zs”, “Ts”, “Ls” and “LBLxx”) where this last variable contains momentarily the numeric label xx referring precisely to a given target subroutine “LBLxx” where you can freely perform whatever complicated calculations you need, providing that it ends by a call to “PopST”. As it is explained, the calling order is important to respect the consecutive RTN order precedencies which allows the proper timely creation and disposal of these local variables. And what the example shows clearly is that within the very same program you can repeat this at different points without any risk of interference (side effect or memory corruption). You simply need to invoke “PshST” passing a different numeric label xx to address another subroutine invoked by the indirect call XEQ IND “LBLxx” and where a different calculation is performed also terminated by the same call to “PopST”. Note that in the actual implementation, there was no need or intent to preserve the content of the original T register (since it is pushed out of the stack by the introduction of the new X value), but that would be easy to include if needed eventually.

As said before, let us know about your initiatives on this subject of dynamic memory (and thanks again to Mr. Thomas Okken for the implementation of local variables)!

ADDED NOTE (Nov 17, 2019): for an interesting and more thorough implementation (using nested subroutines), look at my last version of this program (Const0) providing physical constants (including recent exact definitions and related calculations in compliance with the latest SI revisions of May 20 2019) with the new display (through alpha register) of the corresponding physical units, together with a brief description (an added NOTE describes also the approach): viewtopic.php?f=19&t=271#p12446.
DM42 SN: 03090
HP-29C, HP-41C, HP-15C, HP-33s, HP-35s, WP 34S, Free42, DM42
(Fortran, C++, Mathematica, Maple, Python, …) Physics aficionado

Post Reply