RETURN command?

[droptail]

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,

[Bruce]

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.

[droptail]

Thanks Bruce.

[tenaja]

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.

[rsocor01]

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.

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

[tenaja]

So, according to your post then the number of nested gosubs will depend on the size of the stack. Is this correct?

Yes.

I am not familiar with this memory stack. Is this a part of the total PIC flash memory?

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:

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.

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.)

[MikeBZH]

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

[Acetronics2]

you may have more GOSUBs than RETURNs ...

so, no possible matching test by the compiler !

Alain

[Acetronics2]

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

[Ioannis]

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:

mysub:
    if x=3 then
        y=4
        RETURN
    elseif x=5 then
        y=6
        RETURN
    endif
y=10
return

Ioannis

[CuriousOne]

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.

[Ioannis]

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

[MikeBZH]

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.