Subroutine stack state when using *goto inbetween *return calls

[quartz]

I’ve already tested this out, but I want to make sure I understand how this works.

When nesting subroutines by calling *gosub inside another *gosub, it looks like the *return command navigates after the latest *gosub call. And from there, you can *return all the way to the first *gosub call. Based on this behavior, it seems like CS keeps a stack of “return” locations.

Another thing I’ve noticed is that using *goto does not affect the state of the stack and calling *return after using several *goto commands works as expected (navigates back to the latest *gosub call).

My question is the following: Does CS have a limit to this stack and is there a number of *goto calls that can mess up with this behavior?

I’m asking because I want to implement a recursive style “for” loop, most of which will be called from nested subroutines. Imagine something like this:

*label for_example
*params array_size

*temp index = 1

*label iterate

*if (index <= array_size)
    *if (exampleArray[index] = 0)
        *comment do something
    *set index + 1
    *goto iterate
*else
    *return

[CJW]

You’ll eventually hit the hardcoded *looplimit, but IIRC this can be disabled/increased. Otherwise no, there’s no theoretical limit. Maybe a hardware one.

GitHub - ChoicescriptIDE/cslib is built around the gosub functionality and uses it extensively.