The RETURN of GOSUB

For other topics related to the FreeBASIC project or its community.
coderJeff
Site Admin
Posts: 2459
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

The RETURN of GOSUB

Postby coderJeff » May 08, 2008 12:27

Yes, that's right, GOSUB has RETURNed (well, in SVN anyway, but will be in the next release):

What's new about GOSUB/RETURN?:
- can be used in qb and fblite dialects
- allows recursion
- thread-safe (well, should be, but not heavily tested)
- will work with the ASM and C emitters
- generates a runtime error "RETURN without GOSUB" if RETURN was used but no GOSUB call was made

How to use:
- See wiki: GOSUB, ON GOSUB
- Because Return could mean return-from-gosub or return-from-procedure, Option Gosub and Option Nogosub must be used to enable and disable Gosub support. When Gosub support is disabled, Return is then recognized as return-from-procedure.
- The qb dialect has gosub/return support enabled by default
- The fblite dialect has gosub/return support disabled by default
- The fb dialect does not allow GOSUB
- See OPTION GOSUB, OPTION NOGOSUB, __FB_OPTION_GOSUB__

Special thanks to counting_pine for helping to get this addition tested and for cleaning up the "OPTION" statement in the qb and fblite dialects. All OPTION statements allowed in the fblite dialect are now also allowed in the qb dialect (to make porting code easier). Also thanks to v1ctor who provided an idea for how to GOSUB in the first place. (See http://www.freebasic.net/forum/viewtopi ... 4311#44311)
Qlink
Posts: 79
Joined: Jun 06, 2007 15:21

Postby Qlink » May 08, 2008 19:34

I'm wondering if someone can shed some light on what this whole GOSUB thing is for. I always thought it was a throwback to pre-QB modular programming, basically a GOTO that remembers where you started from. I think the only time I've used it is in QB's primitive ON ERROR command.

So, if you use GOSUB, teach me why!
jevans4949
Posts: 1130
Joined: May 08, 2006 21:58
Location: Crewe, England

Postby jevans4949 » May 08, 2008 19:51

GOSUB was used in original versions of BASIC, which did not have SUBs you could CALL, which were introduced in QBASIC.

The format was GOSUB <line number>. The interpreter saved the line number where the GOSUB was issued, and continued execution at the line number specified. On reaching a RETURN statement, it resumed execution at the line following the GOSUB.

This was OK with what were normally fairly small programs. The problems are / were:

(1) One could GOTO in and out of the block of code , or even GOSUB to multiple points in the subroutine.

(2) There were no local variables in the subroutines; all variables were global in scope and there was the potential of re-using something which the main path was expecting to be left alone - especially integers like I, J, K, used for loop counting or array indexing.

The main reason it's wanted is for backward compatibilty. It was the only way to have subroutines with GWBASIC and its predecessors, and QB was designed to run (most) GWB. (EDIT: and since it was there, old GWB programmers used it!)
Antoni
Posts: 1393
Joined: May 27, 2005 15:40
Location: Barcelona, Spain

Postby Antoni » May 08, 2008 20:52

GOSUB was used in QB as a sort of "inline" function inside a SUBs or FUNCTIONs, without the overload of passing parameters to an auxiliary procedure, as calling SUBs/FUNCTIONs was slow in QB...

For ON x GOSUB, it's plainly a GWB thing, as it hadn't a proper SELECT CASE. I have never seen it in QB code...

The only reason of implementing both in FB is compatibility with existing QB code.

PS: I once saw a QB source with fifty (aprox) GOSUBS in the main code and a single FUNCTION the guy probably copied from someone else. It requires a lot of attention to maintain fifty GOSUBS!
jevans4949
Posts: 1130
Joined: May 08, 2006 21:58
Location: Crewe, England

Postby jevans4949 » May 08, 2008 22:43

The problem with attempting to convert GOSUB subroutines to SUBs is that you have to check variables very carefully to determine whether they are intended to be changed in the sub, or whether it makes a difference, and work through every possible path. To do this, you need cross-referencing tools of the sort which don't come with PC Basics. So most people adopt the principle, "If it ain't broke, don't fix it!". If you are just bolting on some new standalone logic, well of course you can use a SUB.
MichaelW
Posts: 3500
Joined: May 16, 2006 22:34
Location: USA

Postby MichaelW » May 09, 2008 6:43

At the time, and properly used, gosubs could make QB code easier to read and the logic easier to understand. They allowed you to reduce clutter by moving entire statement blocks outside of complex logic structures, without the overhead of a procedure call. But today, with the advent of editors that support folding and the ability to replace gosubs with macros, there is little need for gosub.
coderJeff
Site Admin
Posts: 2459
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Postby coderJeff » May 09, 2008 13:19

Yeah, best not to bother about GOSUB for new programs. It is in the qb dialect purely for compatibility reasons and allowed (but not the default) in the fblite dialect to help make porting code easier. It won't ever be allowed in the fb dialect.

My hope is that it works and is bug free and we won't ever have to worry about it again. Some rough tests indicated that the setjmp/longjmp implementation (needed for the C emitter) is like 1000 times slower than the CALL/RET implementation (currently used with the ASM emitter). Some improvement might be made there in future, but better to not use GOSUB in the first place, imo.
E.K.Virtanen
Posts: 785
Joined: May 28, 2005 9:19
Location: Finland

Postby E.K.Virtanen » May 09, 2008 15:39

For a start, i think also that GOTO/GOSUB are not something that should be used (except in some 10 line long funny codes) but i still appreciate you guys made it for FB.
GOTO/GOSUB are something that belongs to basic anyway and many experienced basic coders has started from there.
Lachie Dazdarian
Posts: 2230
Joined: May 31, 2005 9:59
Location: Croatia
Contact:

Postby Lachie Dazdarian » May 09, 2008 23:01

The thread title would be a cool name for a game. :P
Skyler
Posts: 242
Joined: Sep 26, 2006 16:30

Postby Skyler » May 10, 2008 0:25

The RETURN of GOSUB
GOSUB, a mysterious monster resembling a plate of spaghetti, has arisen from the dark mists of time...

:P
jevans4949
Posts: 1130
Joined: May 08, 2006 21:58
Location: Crewe, England

Postby jevans4949 » May 10, 2008 0:30

And all you have to slay him is a Def Fnx ...
Skyler
Posts: 242
Joined: Sep 26, 2006 16:30

Postby Skyler » May 10, 2008 0:38

Or you can push him into the black /dev/null. *evil grin*
1000101
Posts: 2556
Joined: Jun 13, 2005 23:14
Location: SK, Canada

Postby 1000101 » May 10, 2008 16:26

Skyler wrote:The RETURN of GOSUB
GOSUB, a mysterious monster resembling a plate of spaghetti, has arisen from the dark mists of time...

:P


Erm, GOSUB creates just as much "spaghetti" as CALL. It just predates actual functions in BASIC is all. There is nothing inherently more or less "spaghetti" about it. I can make serious spaghetti with CALL, trust me.



jevans4949 wrote:The interpreter saved the line number where the GOSUB was issued, and continued execution at the line number specified. On reaching a RETURN statement, it resumed execution at the line following the GOSUB.


Technical point of clarification. That may have been true in the 50's on computers which didn't have a returning branching mechanism (ie: all they had were jumps) but on modern (post 50's) computers which have stack-based returning branching, GOSUB is the exact same as CALL. ie: on x86 computers it issues call/ret instructions and the compiler has nothing to do with it with the exception of generating the actual code.

</nitpick>

Anyway, GOSUB is a bit dated since it lack meaningful names. One could argue, "But in QB/FB you could have 'This_Is_A_Label_With_A_Meaningful_Name'" but in QB/FB cou can have actual functions so GOSUB is merely a tired relic from the past. Really, QB compatability is one thing but do we need GWBASIC compatability?


btw, clever topic title.
roook_ph
Posts: 402
Joined: Apr 01, 2006 20:50
Location: philippines
Contact:

when

Postby roook_ph » May 10, 2008 22:09

From the very start I disagree on people removing goto and gosub in freebasic . True final code must have limited globals and cleaner modules. But when I start a program or check functions these are useful function. You cant produce sub and functions as easily as putting gosubs and gotos. And when I can't copy others work i can program only with gotos(gosubs are not here yet) then change them to subs . In what fb version can I find it? When is the next release?
sir_mud
Posts: 1401
Joined: Jul 29, 2006 3:00
Location: US
Contact:

Postby sir_mud » May 11, 2008 0:38

GOTO hasn't and never will be removed from the default dialect, it has its uses. GOSUB however is generally outdated and only necessary for greater QB compatibility.

Return to “Community Discussion”

Who is online

Users browsing this forum: No registered users and 1 guest