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-FileOptimizing FUNCTION Calls
by
Rev 3 3/12/2018
_________________________
GFA allows two types of functions. There's the classic single line functions
defined with DEFFN and the more advanced multi-line style. The single line
functions defined with DEFFN always output slower floating point values.
There's no option to change this behavior and thus my advice is to avoid DEFFN.
If you are using DEFFN, then they should be recoded into multi-line functions.
The multi-line style functions are far more flexible and the return value can
be adjusted to output much faster integer values.
The $F% option must be entered as the first line of a function to have an
affect. It instructs the compiler to output the return value of the function as
an integer. The default output is a floating point value!
This default behavior is probably some throw back to the classic days of BASIC
where everything was floating point. Unless you care about it yourself at each
and every function, you will always get the slower floating point.
$F% does not specifically imply long type. The compiler actually checks the
variable at 'RETURN x' and adjusts the code automatically based on the variable
type. In other words the compiler will auto cast it to the correct integer
type. String functions are handled automatically by the compiler and $F% is
ignored.
To be more precise, the '%' (percent sign) means return any integer type, it
does not mean return only long type. The compiler does not report syntax errors
within compiler commands, it simply ignores them.
Not only does this speed up your functions but it reduces the code size of each
function. Option $F% eliminates two library calls, BSR FITOF (integer to float)
and BSR FFTOI (float to integer). Both of these add several lines of needless
assembler overhead to each function call made! Quite literally if $F% is
missing the function converts the output to floating point and then the
assignment to some variable converts it back. The effect of this at each call
of a function is, integer -> float -> integer, which is for sure not very
optimal.
Example code:
a%=@test !BSR FFTOI (flt to int)
PRINT a%
EDIT
FUNCTION test
$F% !this absolutely has to be the very 1st line!
RETURN 1.23456789 !BSR FITOF (int to flt)
ENDFUNC
A space between '$' and 'F%' will cause it to fail. Example:
$ F% !compiler fails to see the option
According to some French manuals $F| and $F& are valid options. These do not
work, in fact it will result in a float being returned! I've also seen $F$ and
$F! in other peoples source listings and they do not work either.
To be precise, no where in the compiler source code is a check for $F!, $F!,
$F&, or $F$. All of these produce slower floating point output. The compiler
has exactly one check for '$F%' only. Any books or manuals that state otherwise
are incorrect.
Here's a tip. GBE has a built in syntax check for all compiler commands. It
will find typos and misplaced compiler commands. GBE will even tell you if you
have placed $F% at the wrong line. To use this feature go to the 'Setup' drop
down menu and click 'Test $Options' so its check marked. Now, when you click
'Make', 'Run', or 'Test' it will report any incorrect compiler commands like
any other error and place the cursor at the offending line.
_______________________________________________________________________________
There is also two types of void. VOID and '~' (tilde), however VOID first
converts the result to a float then throws it away. The short form is faster as
the result is always an integer. Examples:
~@my_func !faster
VOID @my_func !slower
_______________________________________________________________________________
If your program is well tested and you are 100% sure all of your functions exit
with 'RETURN var', then you can use option $F<. This will further reduce the
code size, as it removes a test for missing ENDFUNC commands.