Bug in FUNC and LNSTCK?

Post here to share useful tips and tricks, to ask questions about using your DM42 or to report software-related problems
mcc
Posts: 277
Joined: Fri Jun 23, 2017 5:10 am

Bug in FUNC and LNSTCK?

Post by mcc »

Hi,

before I wrongly post a bug report I want to make sure to correctly understand FUNC and LNSTK.

Suppose I want to create a function (FUNC), which works recursively. Let's take the N!-function
("born to be recursive") as an example. This function should be callable from an 4-Stack environment
as from a n-Stack environment (only NSTCK needs to be allowed).

I would start this function like so:

Code: Select all

LBL "FAC"
FUNC
LNSTACK
...
1
-
XEQ "FAC"
...
Would this create a new backup of the ever growing stack with each call until the "unsufficient memory" arise -
even for small "n" ?
Or did I miss something here?


This time: If someone does not like, what I am posting or rate my posting as superfluous, not worth a read or whatelse -
I would appreciate a private message or something before s/he decides to delete my post from the forum without
further notice.

Thanks.

Cheers!
mcc
DM 42 - SN: 00373, Firmware release v.:3.22. / DMCP 3.24. as compiled by SwissMicros
Thomas Okken
Posts: 1100
Joined: Tue May 02, 2017 5:48 pm
Location: Netherlands
Contact:

Re: Bug in FUNC and LNSTCK?

Post by Thomas Okken »

LNSTK doesn't save the entire stack; only L4STK does that, when called while NSTK mode is active.

However, FUNC does save the stack levels containing the function parameters (in NSTK mode), or all 4 stack levels (in 4STK mode), plus a few more state items, so it does have significant overhead.

I wouldn't recommend using FUNC in a recursive function, unless you know the maximum recursion depth won't be very deep -- which probably means it's fine in most cases in practice, but not so great for a recursive factorial implementation.

If you really need FUNC and deep recursion, you could split the function into two functions, with FUNC being called in the first function, and the actual recursive logic in the second. If the second function uses NSTK mode, it can be quite efficient; you're basically doing RPL-style programming in that case, so there's no need for any FUNC or L*STK calls, since everything, parameters, results, and intermediates, can be kept on the stack.
mcc
Posts: 277
Joined: Fri Jun 23, 2017 5:10 am

Re: Bug in FUNC and LNSTCK?

Post by mcc »

Hi Thomas,

thanks for your reply! :)

In the meanwhile I wrote a litte FUNCy :) program which does "lesser perfect things"
(read "is wrong") - after I have read your post I am sure it is. It gives some unexpected
(at least for me) error messages. May be this could be probably under some circumstances
:) signs of a bug in the firmware ( I am using ljubo's firmware )...

The program (NSTK enabled):
LBL "FAC"
FUNC
LNSTCK
X>0?
GTO 00
1
RTN
LBL 00
DUP
1
-
XEQ "FAC"
*
RTN
When I run this to calculate 10! I get:
"Invalid type" in the alpha register and
"Unsupported type" in the X register

I know, that the above program is wrong. But an error message in the X-register seems
a little odd to me....is this a "normal error" ?

Cheers!
mcc

POSTEDIT:
Would it be useful/possible to add a LXEQ command to execute
labled parts of a program as real subroutines, which return with RTN to the calling
part of the same program ?
Just a guess/idea into the blue...
DM 42 - SN: 00373, Firmware release v.:3.22. / DMCP 3.24. as compiled by SwissMicros
Thomas Okken
Posts: 1100
Joined: Tue May 02, 2017 5:48 pm
Location: Netherlands
Contact:

Re: Bug in FUNC and LNSTCK?

Post by Thomas Okken »

That's definitely a bug, and I am able to reproduce it in Free42. I'm looking into it!
Thomas Okken
Posts: 1100
Joined: Tue May 02, 2017 5:48 pm
Location: Netherlands
Contact:

Re: Bug in FUNC and LNSTCK?

Post by Thomas Okken »

mcc wrote:
Mon Mar 29, 2021 7:13 pm
Would it be useful/possible to add a LXEQ command to execute
labled parts of a program as real subroutines, which return with RTN to the calling
part of the same program ?
Just a guess/idea into the blue...
I'm not sure I understand. If you want to call a subroutine so that instead of returning to the caller, it returns to the caller's caller, you can just use GTO instead of XEQ.

UPDATE: Unless the second subroutine uses FUNC, L*STK, or LSTO. Then it really needs its own stack frame, i.e. it needs to be called using XEQ.
But I guess I don't understand what problem you're trying to solve. What's wrong with XEQ "FUN" RTN ?
mcc
Posts: 277
Joined: Fri Jun 23, 2017 5:10 am

Re: Bug in FUNC and LNSTCK?

Post by mcc »

Hi Thomas,

sorry if I messed it up languagewise...I am a happy user of "XEQ....RTN"! :)

When creating a complete new "FUN" instead of using an entry point marked with LBL nn
for the purpose of haveing a "fully fledged" subroutine for a main program I always
create an entry in the program menu of the DM42 which looks like it could be called separately -
which isn't useful in this kind of setup in each case.

Haveing the possibility to call LBL nn ... RTN sequences as they would be separate LBL "..."
parts would combine anything under one (or more) LBL - each visible to the user
and each is useable by the user also and does not eat up a place in the program menu.
And since this LBL nn-sequences are numbered I can have up to 99 of them (which is far more
then needed normally though).

Only my two LBLs...your program structure may vary... :) :)

Cheers!
mcc
DM 42 - SN: 00373, Firmware release v.:3.22. / DMCP 3.24. as compiled by SwissMicros
Thomas Okken
Posts: 1100
Joined: Tue May 02, 2017 5:48 pm
Location: Netherlands
Contact:

Re: Bug in FUNC and LNSTCK?

Post by Thomas Okken »

I'm sorry, but I'm not following this at all...
Thomas Okken
Posts: 1100
Joined: Tue May 02, 2017 5:48 pm
Location: Netherlands
Contact:

Re: Bug in FUNC and LNSTCK?

Post by Thomas Okken »

Thomas Okken wrote:
Mon Mar 29, 2021 11:13 pm
That's definitely a bug, and I am able to reproduce it in Free42. I'm looking into it!
I found the problem, LNSTK wasn't handling the case correctly where big stack mode was already active and DEPTH ≠ 4. This could lead to stack corruption and crashes. This was serious enough that I made a new release, 3.0.2.
mcc
Posts: 277
Joined: Fri Jun 23, 2017 5:10 am

Re: Bug in FUNC and LNSTCK?

Post by mcc »

Hi Thomas,

oh!...
Thank you for delivering a corrected release that fast, Thomas! :)

A question:
Am I "safe" to use my DM42 (that is: no crashes and/or data corruption) with the b2 firmware if I do not construct
recursive functions with NSTCK enabled and don't use FUNC and LNSTCK in the combo as in my "killer program"?
Or in other words: How far does this bug reach?

Cheers!
mcc
DM 42 - SN: 00373, Firmware release v.:3.22. / DMCP 3.24. as compiled by SwissMicros
Thomas Okken
Posts: 1100
Joined: Tue May 02, 2017 5:48 pm
Location: Netherlands
Contact:

Re: Bug in FUNC and LNSTCK?

Post by Thomas Okken »

LNSTK is unsafe when already in big stack mode. As a work-around, you could make LNSTK calls conditional: FC? 80 LNSTK.
Post Reply