[futurebasic] Re: GOSUB Crash

Message: < previous - next > : Reply : Subscribe : Cleanse
Home   : August 2001 : Group Archive : Group : All Groups

From: Richard Goodman <bhomme@...>
Date: Sun, 5 Aug 2001 08:04:36 -0700
Thanks for the interesting discussion, Larry. As a matter of fact, when I
replaced my GUSUB routine with a local FN, there was no obvious decrease in
speed. Indeed, the entire process of composing and displaying of the music
in Sebastian occurs lightning quick on my 350 MHz G-3. It may slow down as
I add more and more computations, but for now, it's pretty fast.
Consequently, I won't bother to investigate the "GP2" FN.

Richard

Larry S. wrote:

<<<<<<< Richard Goodman <bhomme@...> asked
on Wed, 1 Aug 2001 09:25:40 -0700:

 > 3. Is it permissible to have a GOSUB inside a local FN that
 > routes program flow to a subroutine outside the local FN and
 > then comes back inside the local FN when the RETURN of the
 > subroutine is reached?

It has always been deprecated.  It's "immoral". So I fear no code
priest will hold your hand, help you and rescue you when you get
into trouble.

But you can probably make it work if you think carefully
about "variable scope".  You are entering the deep crevasse between
compiler preformance and compiler documentation.

The compiler ref man recommends GOSUB use *within* a FN when you
want a construct much faster than a normal FN and/or something that
has convenient access to all the variables available in the FN.

But even that recommendation is provisional.  Responding to a
request of mine, Gariepy and Purves created a new sort of FN
"GP2" that has 4 times less overhead than today's FNs and turns
out to be **faster** than GOSUB (on PPC).

Now, if you are wanting a subroutine that is extremely fast and
uses only *global* variables and scratch variables
(ie does not need the FN's local variables) then I would
highly recommend this Gariepy-Purves FN. It combines
 -- the global availability of the "wayward" GOSUBS
 you were contemplating, with
 -- even better speed.

Unfortunately this is for hardy pioneers only until the
Gariepy-Purves FN is implemented and documented. (Hint! Hint!)
As things stand, you'll need a modicum of inline PPC
assembly language.

You can get to all this provisional stuff by looking up my last
post on that subject:

 Re: FN_Overhead_studies,  Sun May  6 13:13:04

in our archives at

     ftp://topo.math.u-psud.fr/pub/lcs/fb/

(no Netscape access!) and working backwards from there.

There are many other tricks one can play including a faster
GOSUB (for PPC), but I won't go on unless you make a
clear request.

Cheers

Larry S.

PS.  Is anyone perfectly clear on what GLOBALS GOSUB
accomplished in FBII?  It has vanished from FB^3

PPS.  In the early days one got a morality bonus for
using GOSUB in place of GOTO.  Now you get one for using
FN instead of GOSUB.
(Hey, it'll soon be time to deprecate FNs too ;=)>>>>>>>