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: https://technical.swissmicros.com/decoders/dm42/

You can then copy/paste the listing and post it in "code" tags.
rprosperi
Posts: 1703
Joined: Mon Apr 24, 2017 7:48 pm
Location: New York

Re: External stack

Post by rprosperi »

Thomas Okken wrote:
Sat Apr 06, 2019 6:19 pm
rprosperi wrote:
Sat Apr 06, 2019 3:38 pm
I think there could be merit to let the current local instance access the global variables, perhaps with GRCL / GSTO, to pass parameters between the environments, though I presume this could add significant complexity to the design, so perhaps not worthwhile.
It's unnecessary, too. If you know your function needs to access a certain global variable, then just don't use a local variable with the same name.
DOH (accompanied by a SMH)!

Got it, yes I understand. I re-read the above and this is clear to anyone that read it, and actually thought about it before suggesting improvements.

Thanks for your gentle reply :oops:

Good luck with your post-walk debugging.
--bob p

DM42: β00071 & 00282, DM41X: β00071 & 00656, DM10L: 071/100
Thomas Okken
Posts: 1100
Joined: Tue May 02, 2017 5:48 pm
Location: Netherlands
Contact:

Re: External stack

Post by Thomas Okken »

Fixed bugs, seems OK now. It handles locals hiding the indexed matrix, and the Ackermann function example works, within reason -- the RTN stack is currently limited to 1024 levels, which the Ackermann function will exceed for quite modest arguments!

I'm not pushing this to the Android and iOS app stores without some more testing, but for the brave and curious, here are test builds for Android, Windows, MacOS, and Linux: https://thomasokken.com/free42/download/test/

N.B. You may want to backup your state file before trying this. The state file format has changed, so while 2.1.2 will happily read older state files, older versions of Free42 will not read 2.1.2 state files.
Thomas Okken
Posts: 1100
Joined: Tue May 02, 2017 5:48 pm
Location: Netherlands
Contact:

Re: External stack

Post by Thomas Okken »

Update: 2.1.3: fixed memory corruption bug in SOLVE and INTEG, caused by the new stack logic.
dlachieze
Posts: 613
Joined: Thu May 04, 2017 12:20 pm
Location: France

Re: External stack

Post by dlachieze »

This is cool ! I was wondering if LSTO would support storage arithmetic but it's not necessary: once you have created the local variable with LSTO you can just use the standard STO+, STO-, STO* and STO/

I have installed the Android apk on my tablet and I have an issue with the state file: the first time I ran the v2.1.3 it worked fine, importing correctly the previous state file. However after that every time I launch v2.1.3 it displays a "State File Corrupt" message and starts with an empty memory.
DM42: 00425 - DM41X: β00066 - WP43: 00042
Thomas Okken
Posts: 1100
Joined: Tue May 02, 2017 5:48 pm
Location: Netherlands
Contact:

Re: External stack

Post by Thomas Okken »

Update: 2.1.4: Android only: fixed bug in state file reading that caused State File Corrupt
rprosperi
Posts: 1703
Joined: Mon Apr 24, 2017 7:48 pm
Location: New York

Re: External stack

Post by rprosperi »

dlachieze wrote:
Sun Apr 07, 2019 9:20 am
This is cool ! I was wondering if LSTO would support storage arithmetic but it's not necessary: once you have created the local variable with LSTO you can just use the standard STO+, STO-, STO* and STO/
Thanks for clarifying this Didier, I thought one had to continue using LSTO to access the local instance, but this confirms once a local var is created all references to that var are local for the life of that routine.

Gotta play later today...

Thanks again Thomas!
--bob p

DM42: β00071 & 00282, DM41X: β00071 & 00656, DM10L: 071/100
Thomas Okken
Posts: 1100
Joined: Tue May 02, 2017 5:48 pm
Location: Netherlands
Contact:

Re: External stack

Post by Thomas Okken »

To clarify how LSTO works under the hood: it creates a variable just like STO, except the variable is tagged with the current RTN level, so when a RTN is executed, it can scan the list of variables and delete all the ones with the current level.

When LSTO creates a variable with a name that already exists, the new variable is marked "hiding" (as in, it is hiding another variable), and the older variable is marked "hidden." When a variable is deleted, its "hiding" flag is checked, and if it is set, the first matching "hidden" variable is found and un-hidden.

Variable lookups work just as before, except they now check the "hidden" flag and ignore all variables that are so marked. Since all variable lookups are done by searching the variables table by name, everything else is taken care of without any further logic.

The only special cases have to do with REGS (like STO, LSTO enforces the requirement that REGS must be a matrix) and INDEX (when the indexed matrix is hidden, the matrix pointers IJ are saved, and when it is un-hidden, they are restored).

And finally, CLV can be used to delete local variables, should you ever want to, but it will not delete locals from a lower stack level, only from the current one. And globals, of course, if they're not hidden.
User avatar
ijabbott
Posts: 253
Joined: Fri Dec 15, 2017 2:34 pm
Location: GB-MAN

Re: External stack

Post by ijabbott »

Thomas Okken wrote:
Sun Apr 07, 2019 4:47 pm
To clarify how LSTO works under the hood: it creates a variable just like STO, except the variable is tagged with the current RTN level, so when a RTN is executed, it can scan the list of variables and delete all the ones with the current level.
Just to clarify something, by "RTN", do you mean any return to the caller (e.g. reaching an END instruction), or only via the RTN instruction?

Also, what happens to the variables if you halt execution and don't continue?
Thomas Okken
Posts: 1100
Joined: Tue May 02, 2017 5:48 pm
Location: Netherlands
Contact:

Re: External stack

Post by Thomas Okken »

ijabbott wrote:
Sun Apr 07, 2019 5:16 pm
Thomas Okken wrote:
Sun Apr 07, 2019 4:47 pm
To clarify how LSTO works under the hood: it creates a variable just like STO, except the variable is tagged with the current RTN level, so when a RTN is executed, it can scan the list of variables and delete all the ones with the current level.
Just to clarify something, by "RTN", do you mean any return to the caller (e.g. reaching an END instruction), or only via the RTN instruction?

Also, what happens to the variables if you halt execution and don't continue?
END has exactly the same effects as RTN. In fact, the implementation of END simply calls the implementation of RTN.

There is also a non-local kind of RTN, when a math error occurs in a function called by the solver. This causes immediate return to the solver, and any intervening stack levels are popped, and their local variables cleared.

When you halt execution and don't continue, the RTN stack contents remain, but it is cleared by program editing, and by GTO, XEQ, and RTN in run mode.
rprosperi
Posts: 1703
Joined: Mon Apr 24, 2017 7:48 pm
Location: New York

Re: External stack

Post by rprosperi »

@Godwin - The DM42 Encoder/Decoder will need to be updated to allow processing of the new LSTO command. Is the proper byte code needed from Thomas, or how the heck do you know what to use?

I thought I found a bug in Free42 for a moment, and then a bug in the Decoder (while trying to import) for a moment, and then I realized the above needs to happen. At least something useful came out of it...

@Thomas - My casual (certainly non-rigorous) testing of the new local variables works fine so far. I made a dumb little test program framework to hack and drive around to see what's happening (adding multiples levels, etc.) and all is well. Below is the program for anyone that wants to dabble and explore LSTO and its effects (don't expect much here):

Code: Select all

00 { 153-Byte Prgm }
01▸LBL "LOCAL"
02 9
03 STO "V1"
04 "Should be [9]: "
05 ARCL "V1"
06 AVIEW
07 PSE
08 XEQ "SUB1"
09 "Should be [9]: "
10 ARCL "V1"
11 AVIEW
12 RTN
13▸LBL "SUB1"
14 RCL "V1"
15 3
16 ÷
17 LSTO "V1"
18 "Should be [3]:"
19 ARCL "V1"
20 AVIEW
21 PSE
22 XEQ "SUB2"
23 RTN
24▸LBL "SUB2"
25 RCL "V1"
26 3
27 ÷
28 LSTO "V1"
29 "Should be [1]: "
30 ARCL "V1"
31 AVIEW
32 PSE
33 END
--bob p

DM42: β00071 & 00282, DM41X: β00071 & 00656, DM10L: 071/100
Post Reply