Topic       : The GFA-Basic Compendium
Author      : GFA Systemtechnik GmbH
Version     : GFABasic.HYP v2.98 (12/31/2023)
Subject     : Documentation/Programming
Nodes       : 899
Index Size  : 28056
HCP-Version : 3
Compiled on : Atari
@charset    : atarist
@lang       : 
@default    : Document not found
@help       : Help
@options    : +g -i -s +z
@width      : 75
@hostname   : STRNGSRV
@hostname   : CAB     
@hostname   : HIGHWIRE
@hostname   : THING   
View Ref-FileCompiler Option $P
by Lonny PursellWWW: http://gfabasic.net/

Rev 3  3/12/2018
_____________________________

This option control the way subroutines are compiled. The best way to explain
its use is via examples. Be prepared to see some assembler listings. ;o)

$P<   Optimize routines with no parameters and locals (compiler default state)
      Recursion might fail, also RESUME and RESUME NEXT cannot be used.
$P>   Compile all routines as GFA routines

The original compiler manual is a little vague on these commands. It only has
an effect on subroutines without parameters and locals.

Subroutines with parameters or locals are always compiled as GFA subroutines,
meaning parameters, locals, and recursion is supported.

Subroutines without parameters and locals can be compiled into simple 68k
subroutines. This will speed up such subroutines, but recursion could cause
stack problems.

Typically the default state of the compiler is fine, so you don't have to do
anything. The only time you would have to use $P> would be if you have a
subroutine that's called recursively and it has no parameters and locals. In
the event that would be the case it's best to wrap the subroutine like so:

$P>                     !optimize off
PROCEDURE get_dir_tree  !calls itself
  ' blah
RETURN
$P<                     !optimize back on

Note: If the subroutine which is called recursively happens to have parameters
or locals then $P> is automatically applied.

Here's a GFA listing we will compile twice and dis-assemble as an example, so
we can see the actual difference:

GOSUB no
GOSUB yes(2)
PROCEDURE no       !proc with no parameters and locals
  CLS
RETURN
PROCEDURE yes(x%)  !proc with a parameter
  CLS
RETURN

Here's what it looks like in the dis-assembler with symbols:

          ;$P< dis-assembly example (listing #1)
STARTADR: lea    STARTADR-$100(pc),a0
          lea    $0100(a0),a7
          jsr    INIT.l
          jsr    _NO.l
          pea    $0002.w
          jsr    _YES.l
          bsr    END
_NO:      bsr    CLS            ;compiled as a simple 68k routine
          rts

_YES:     bsr    GOSUB
          lea    -$8000(a5),a0
          bsr    VALPARI
          bsr    CLS
          bra    RETURN

Here's the same listing, but with compiler option $P> added:

          ;$P> dis-assembly example (listing #2)
STARTADR: lea    STARTADR-$100(pc),a0
          lea    $0100(a0),a7
          jsr    INIT.l
          jsr    _NO.l
          pea    $0002.w
          jsr    _YES.l
          bsr    END
_NO:      bsr    GOSUB          ;forced to be a gfa routine
          bsr    CLS
          bra    RETURN

_YES:     bsr    GOSUB
          lea    -$8000(a5),a0
          bsr    VALPARI
          bsr    CLS
          bra    RETURN

As you can see in listing #2, procedure _NO contains more code and will be
slower. Procedure _YES is always compiled as a GFA subroutine since it has a
parameter.