RETURN command?

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

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