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

[Ioannis]

I am not an expert on compiler code writing but I think this is hard or not possible to happen.

Ioannis

[tenaja]

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


Why, or how would it?

You are allowed to put labels in the middle of a sub so you can do a conditional goto, etc. So, a label is not an acceptable terminator for a sub. So what would you use?

I haven't kept up with pb's recent changes, but if it doesn't have functions with parameters, there's no way to easily force an error if you skip a return.

Especially since you can have many Return statements shielded by conditional blocks.

The best way to force correct programming is through functions. Last I looked, PB didn't have them.

[Acetronics2]

you may have more GOSUBs than RETURNs ... ;)

so, no possible matching test by the compiler !

Alain

[rsocor01]

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

This is not a bug. The programmer should put a RETURN at the end of every SUB routine. There can be some conditional RETURN commands too. You should organize your program such that every SUB routine has a RETURN command at the end of it.

[MikeBZH]

Maybe the real issue is the language itself.

It would be more convenient to formally identify each sub routine by a keyword, for example "sub" instead of assuming that a label is the entry of a sub.

So, instead of writing for example :

foo:
<instructions with or without labels>
return

one would write :

sub foo :
<instructions with or without labels>
return

and the compiler could easily verify that every sub has a return. The verification process should be the same as with IF THEN ELSE ENDIF for example.

But, of course, PBP is already defined...

MikeBZH

[Acetronics2]

Hi, Mike

May be you should understand what PBP and Generally Basics do at the machine low levels when it reaches such commands ...
that would help you to understand what possible and what not ...

having an eye upon assembler is always a great help ... even when using Basic/compiled languages ... ;)

Alain

[HenrikOlsson]

You can have one entry-point (Label) and multiple exit points (Returns) or multiple entry-points (Labels) and a signle return. Both are valid and very useful. For example, my SK6812 RGBW LED code uses the following to provide three different, very short, delays:

SevenNops:
@ NOP
@ NOP
FiveNops:
@ NOP
@ NOP
@ NOP
@ NOP
@ NOP
NoNops:

RETURN

GOSUB NoNops gives four instruction cycle delay (250ns @ 64MHz), FiveNops gives 9 and SevenNops 11 cycles delay. I'd happily trade that for proper function calls with arguments any day but the way it does work is neither strange or wrong :-)

/Henrik.

[Acetronics2]

You can have one entry-point (Label) and multiple exit points (Returns)

/Henrik.

Hi, Enrik

I suppose here the "right" Return is selected through some conditionnal choice ... as , once the sub is entered, the first encountered Return loads the program counter the return address memorized on top of the stack by the " Gosub " command ... so, there can't be " active " multiple returns ( thanks God ! ) ;)

did I miss something ???

Alain

[HenrikOlsson]

You didn't miss anything. My point is basically that it's not as simple as just telling the compiler to count the number of GOSUB and RETURN statements and generate an error they don't match.

[MikeBZH]

Hi,

Frankly, I am surprised and a little bit shocked by this kind of practice.
But it may be a matter of "cultural feeling".

I have spent years and years in developing aerospace products. In this world where the readibility of the code and the safety are the keypoints one cannot imagine a sub with more than one entry point and more than one return point.

This is why I was surprised that PBP does not detect a sub without a return.

Yes, I know, most of us work in other areas or are makers or hobbyists. But good practices are good practices.

Now, everybody is free to do what he prefers :)

MikeBZH

[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. https://www.hpmuseum.org/3qs/273q.jpg )
: 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-premier-microprocesseur-le-mp944-du-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.