nip may be acting strange

[WildKeccak]

nip should be equivalent to swap drop, I think.

Welcome to zeptoforth Built for rp2040, version 1.5.5, on Sat May 25 04:30:52 PM CDT 2024 zeptoforth comes with ABSOLUTELY NO WARRANTY: for details type `license' ok compat import ok : have bl compat::word compat::find nip ; ok have ! . 536959628 stack underflow : have bl compat::word compat::find swap drop ; ok have ! . -1 ok

[tabemann]

On Wed, May 29, 2024 at 10:29 PM WildKeccak @.***> wrote:

nip should be equivalent to swap drop, I think.

Welcome to zeptoforth Built for rp2040, version 1.5.5, on Sat May 25 04:30:52 PM CDT 2024 zeptoforth comes with ABSOLUTELY NO WARRANTY: for details type `license' ok compat import ok : have bl compat::word compat::find nip ; ok have ! . 536959628 stack underflow : have bl compat::word compat::find swap drop ; ok have ! . -1 ok

Thanks for bringing this to my attention. I am very certain that NIP is equivalent to SWAP DROP, and my immediate suspicion here is that there is a bug in either COMPAT::WORD or COMPAT::FIND, because those have not been used nearly as much as NIP has been. (If NIP did not work there would be a lot of code which would not work, as I use it very liberally.)

Could you try this same experiment again, but before and after NIP and SWAP DROP could you put .S to dump the stack, because this smells like there is some major stack funniness with either COMPAT::WORD or COMPAT::FIND?

Thanks,

Travis

[WildKeccak]

Welcome to zeptoforth Built for rp2040, version 1.5.5, on Sat May 25 04:30:52 PM CDT 2024 zeptoforth comes with ABSOLUTELY NO WARRANTY: for details type `license' ok compat import ok : have bl compat::word compat::find .s swap .s drop .s ; ok have ! [ 536883138 -1 ] [ -1 536883138 ] [ -1 ] ok : have bl compat::word compat::find .s nip .s ; ok have ! [ 536883138 -1 ] [ -1 ] ok ok .s [ ] ok : have bl compat::word compat::find nip ; ok have ! .s [ ] ok abort ok have ~ .s [ 0 ] ok ok .s [ 0 ] ok

[WildKeccak]

Welcome to zeptoforth Built for rp2040, version 1.5.5, on Sat May 25 04:30:52 PM CDT 2024 zeptoforth comes with ABSOLUTELY NO WARRANTY: for details type `license' ok : have bl .s compat::word .s compat::find .s nip .s ; ok : have2 bl .s compat::word .s compat::find .s swap .s drop .s ; ok : test have ! .s ; ok : test2 have2 ! .s ; ok test [ 32 ] [ 536955376 ] [ 536955376 0 ] [ 0 ] [ ]stack underflow test [ 32 ] [ 536955376 ] [ 536955376 0 ] [ 0 ] [ ]stack underflow tes unable to parse: tes test [ 32 ] [ 536955376 ] [ 536955376 0 ] [ 0 ] [ ]stack underflow have ! [ 32 ] [ 536955376 ] [ 536883138 -1 ] [ -1 ].s [ ] ok test2 [ 32 ] [ 536955376 ] [ 536955376 0 ] [ 0 536955376 ] [ 0 ] [ ]stack underflow test2 [ 32 ] [ 536955376 ] [ 536955376 0 ] [ 0 536955376 ] [ 0 ] [ ]stack underflow test2 [ 32 ] [ 536955376 ] [ 536955376 0 ] [ 0 536955376 ] [ 0 ] [ ]stack underflow test2 [ 32 ] [ 536955376 ] [ 536955376 0 ] [ 0 536955376 ] [ 0 ] [ ]stack underflow test2 [ 32 ] [ 536955376 ] [ 536955376 0 ] [ 0 536955376 ] [ 0 ] [ ]stack underflow test2 ! [ 32 ] [ 536955376 ] [ 536883138 -1 ] [ -1 536883138 ] [ -1 ]

[tabemann]

There appears to be two things here. The first is that HAVE and HAVE2 look for the word at runtime not at compile-time, so nothing gets parsed and ! gets compiled into the TEST and TEST2 words instead. The second is that there is a bug in INTERNAL::PARSE-TO-CHAR which is utilized internally by COMPAT::WORD where, if (in this case) BL is not found in the parsed text,

IN does not get updated properly, which in your other testing was causing ! to be executed after HAVE or HAVE2 when executed in interpretation mode. I will fix INTERNAL::PARSE-TO-CHAR (it is a trivial change) and put out a new release containing this fix. However, to get the desired behavior, you will need to make HAVE and HAVE2 immediate by including [IMMEDIATE] before the ; at their ends.

Travis

Message ID: @.***>

[tabemann]

WildKeccak,

Try installing the latest release, 1.5.5.1 ( https://github.com/tabemann/zeptoforth/releases/tag/v1.5.5.1). It fixes the bug in INTERNAL::PARSE-TO-CHAR, and thus in COMPAT::WORD. However, be careful about how you use COMPAT::WORD in interpretation versus compilation contexts, which was part of what was giving you the stack underflows (and which incidentally would have written to outer space) when combined with ! .

Travis

Message ID: @.***>

[WildKeccak]

That does it, as far as I can tell.