Will a program function correctly if a RETURN command is encountered, but there was no GOSUB command preceding it? i.e., will it just skip over the RETURN command without a hitch? Or must you always return to a subroutine?
Thanks,
Will a program function correctly if a RETURN command is encountered, but there was no GOSUB command preceding it? i.e., will it just skip over the RETURN command without a hitch? Or must you always return to a subroutine?
Thanks,
James
If you call or gosub a routine, make sure it lands on the return instruction to get back. If you use goto to get there, and it lands on return, you'll really have some odd things happening. It will not skip over or ignore the return instruction.
Just organize your routines and use goto, call, gosub, etc accordingly to save yourself a lot of headaches.
Last edited by Bruce; - 16th May 2010 at 22:44.
Bruce is totally correct, but I'll expound a bit so you know the details.
The "stack" is a set of memory locations that the PIC uses. It is a small amount of memory; some PIC's only have 4 or 8 locations it can store.
When you "Call" a sub, the return address is PUSHed onto (put in for later use) the stack. Subsequent calls are pushed on, with the newest address values remaining at the top. If you have too many calls without a return, you experience Stack Overflow. Most PICs will Reset when this happens--the datasheet tells you the size of the stack and the results of an overflow.
When you "Return" from a sub, the newest address on the stack is POPped off (pulled off for immediate use) and the program goes there. If the stack is empty, it will either go to address location "0" or a random place depending upon the processor. The datasheet usually tells you what to expect.
So if you Return without a Gosub, the result is usually similar to a Reset...but, as I said, this may vary from mcu to mcu, and the datasheet is the best place to look for a definite answer.
Last edited by tenaja; - 16th May 2010 at 23:26. Reason: Add "full stack" note.
Very good explanation. This kind of posts is what makes me come back to this forum.
So, according to your post then the number of nested gosubs will depend on the size of the stack. Is this correct? I am not familiar with this memory stack. Is this a part of the total PIC flash memory?
Robert
Yes.
No. It is RAM, not Flash, but if you look in the datasheet under Memory Organization, you'll see it is not counted in the advertised RAM size. This is from the 12F683 d/s:I am not familiar with this memory stack. Is this a part of the total PIC flash memory?
Note with this device, with an overflow condition, after 8 returns, you return to "0", which is a reset. Also note that different PICs have different sizes, behaviors and commands. (i.e. Some allow you to push/pop, others do not.)2.3.2STACK
The PIC12F683 family has an 8-levelx13-bit wide
hardware stack (see Figure2-1). The stack space is
not part of either program or data space and the stack
pointer is not readable or writable. The PC is PUSHed
onto the stack when a CALL instruction is executed or
an interrupt causes a branch. The stack is POPed in
the event of a RETURN, RETLW or a RETFIE
instruction execution. PCLATH is not affected by a
PUSH or POP operation.
The stack operates as a circular buffer. This means that
after the stack has been PUSHed eight times, the ninth
push overwrites the value that was stored from the first
push. The tenth push overwrites the second push (and
so on).
Note1: There are no Status bits to indicate stack
overflow or stack underflow conditions.
Hi,
The strange thing is that the PBP compiler does not detect a missing RETURN instruction at the end of a sub.
No warning or error is raised. With a complex program it can take some time before this kind of vicious bug is detected.
Maybe something to correct with a future release of PBP (if any ?)
MikeBZH
you may have more GOSUBs than RETURNs ...
so, no possible matching test by the compiler !
Alain
************************************************** ***********************
Why insist on using 32 Bits when you're not even able to deal with the first 8 ones ??? ehhhhhh ...
************************************************** ***********************
IF there is the word "Problem" in your question ...
certainly the answer is " RTFM " or " RTFDataSheet " !!!
*****************************************
Hi, Mike
I do not think I'ts a cultural practise, but an old time heritage ...
Have a look to the very first HP programmable calculators programming examples ( HP27C i.e. )
: the memory was very small and you had to spare as much space as you could to get a decent running program ...
If you deal with aerospace things, try to get infos about the processor used aboard the famous Grumman F14 ( called 944 ??? https://www.framboise314.fr/le-premi...u-f-14-tomcat/ ) ...
You are one of the " arduino generation " with plenty of wasted program space !!!
nowadays, we find processors with Huge memory and people do not care about wasting hundreds of addresses.
Now, in the end, I kind of feel you are confusing Basic subs and C functions ...
Try to think BASIC or C ... but do not mix them together !!!
Alain
************************************************** ***********************
Why insist on using 32 Bits when you're not even able to deal with the first 8 ones ??? ehhhhhh ...
************************************************** ***********************
IF there is the word "Problem" in your question ...
certainly the answer is " RTFM " or " RTFDataSheet " !!!
*****************************************
I do not see any safety problem with multiple entries in a sub.
It is up to the programmer to write correct code and debug it. Say you want 5*6 and accidentally write 5**6. This is valid in PBP but whose fault is now. Compiler's?
Also valid is the conditional exit from a sub with many returns that depend on the conditions. Not efficient programming but for the sake of example:
IoannisCode:mysub: if x=3 then y=4 RETURN elseif x=5 then y=6 RETURN endif y=10 return
Last edited by Ioannis; - 12th March 2022 at 10:38.
The main issue that SUB routines are just plain labels, there is no separate category like where you define that this code is SUBroutine, so for sure,there will be no conditional checks for matching number of gosub-returns.
Why this should be checked? I really do NOT want them to be checked so that I can conditionally choose where and when to exit the sub!
Ioannis
Hi Guys !
As I said previously, OK, everybody writes his own code as he likes.
It is not a matter of memory or old processors or any specific language.
It is a matter of writing a clean, easily understandable, easily readable code, which can be maintained by you of somebody else years after without too much pain.
End of the discussion for me. I have many projects to develop.
MikeBZH.
Bookmarks