Are there any problems (besides being visually confusing) that one would encounter with nested "select case" routines, and if not, is there a limit to depth - i.e.- are 3 ok?
Thanks
Are there any problems (besides being visually confusing) that one would encounter with nested "select case" routines, and if not, is there a limit to depth - i.e.- are 3 ok?
Thanks
No problems that I know of, have done it many times though not that many levels (2-3).
I don't know if there's a limit, can't think of why there would be.
/Henrik.
The only limit I can think of is the "stack". But that's most likely the same stack we use for GOSUBs and nobody has complained about a limitation on that yet.
"Total deduction on my part without a shred of supporting evidence"
Robert
My Creality Ender 3 S1 Plus is a giant paperweight that can't even be used as a boat anchor, cause I'd be fined for polluting our waterways with electronic devices.
Not as dumb as yesterday, but stupider than tomorrow!
A select case statement expands to a sequence of 'If This Then That' constructs when run through the compiler. Since there is no limitation using the If then, I do not anticipate a limit on the nesting of select case statements. Gosubs are in a different category wherein the compiler can decide to use the stack - or in some cases - to use gotos to acheive the same functionality and is totally compiler dependent.
Ok, you got me on that one. How can GOTOs be used to achieve GOSUB logic?
The going part is not a problem, but how does it come back without using a stack or some such memory to remember where it came from?
Or does it replace the RETURN with a GOTO pointing to the statement following the GOSUB?
Robert
My Creality Ender 3 S1 Plus is a giant paperweight that can't even be used as a boat anchor, cause I'd be fined for polluting our waterways with electronic devices.
Not as dumb as yesterday, but stupider than tomorrow!
I dig many .LST files, and didn't see that compiler replaces GOSUB with GOTO.
ON DEBUG uses GOTO after each PBP line, but before GOTO saves address to DEBUG_ADDRESS and, DEBUG_ADDRESSU variables. So you can use them to load program counter to get back from where PC jumped.
Not the Pic basic compiler we discuss here. I've seen other compilers which do. The compiler knows which piece of code goes where in code space in the same way that the compiler knows which variables are used by a subroutine(locals). Therefore, it can compute a goto and return via another goto. It is dependent on the compiler writer who decides how to implement. Think of code more in terms of ASM and you will be able to figure it out.
Ok, I was thinking just on PBP compiler. But return with goto would be possible if you call function/subroutine from one place only. And for that you actually don't need function or subroutine.
You could extend gosub nesting that way.
Save program counter to variable, set it to the address
of a routine, and rewrite the incremented value at the
end of the routine.
In the early days, with single code pages, it sounds like
a reasonable way to extend the nesting a level.
If I remember correctly Darrel did that, it was 48 level software stack.
EDIT:
http://www.picbasic.co.uk/forum/showthread.php?t=151
Good idea lolThe thought of actually writing another stack still hadn’t cross my mind.
Bookmarks