RETURN command?

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

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