Many of the properties on this page relate to optimizations relevant to much older processors than you will find in modern computers (386, 486 and early Pentiums).
BranchOpt - The optimization of branch statements provides for a slightly smaller program size and increases the performance a little bit. However, compile time increases, and therefore this option can disabled partially or completely. Suggestion: Disable (None)
Full Optimization for Exe, Gll & Lg32 - The time consuming process of optimizing the branch statements can be enabled for the creation of stand-alone EXEs only. Compiling in memory in the IDE will not result in branch optimization. Suggestion: Disable
Here you can adjust how much code the BASIC must generate, to the avoid the multiplication statement of the 80x86 processor when a value is multiplied by a constant. GFA-BASIC 32 replaces the code through a series of Shl, Add, Sub and Lea statements. This requires more code. However, modern processors are already optimized.
The slider setting 1 = left allows only very short replacement codes (10 bytes). This is the setting when you need a smaller program. A slightly higher performance is obtained with the second setting (up to 20 bytes increase) on a Pentium 100. The third setting (up to 30 bytes) is on a Pentium a little slower and the program a little larger, however for a 486 bit this setting results in faster execution. (The Pentium is, of course, still faster than the 486, but slower than the same Pentium with setting 2). The fourth setting inserts sequences to 40 bytes.
The settings: 1 = space, 2 = optimization for Pentium, 3 = optimization for 486, 4 = especially suitable for programs that are often used on 486's.
Here with Pentium all Pentiums are meant, except the old Pentium 60/66 Conventions, as well as the i486-DX4. These processors have rapid multiplication built-in.
This setting only affects programs that are using many integer multiplications with constants. Suggestion: Disable
This option is for the rare case that a program uses the Bswap function and the program is run on a 80386 computer. Normally, the processor is able to execute the Bswap statement (the exchange of the four byte in an integer) very quickly. However, for these the Bswap is emulated using
xchg al, ah : . rol eax, 16 : . xchg al, ah.
Not only is this emulation longer in code size, but also significantly slower. Note that 80386-computers running Windows NT or Windows 95 are not numerous. Suggestion: Disable
This option is for the not so rare case that a programmer wants some more control over Type conversions. In the past BASICs have always converted between different numeric formats automatically (Double <-> Int etc.). VBA introduced an automatic conversion of string values to numeric (an OLE internal Val) and vice versa. This automatic conversion can lead to difficulty in finding bugs, and is in conflict with prior versions of GFA-BASIC. With this optionselected the automatic conversion of strings in numbers is disabled. This does not apply to operations with Variants or Objects. Suggestion: Enable.
Inserts code to check for every access to an array to determine if the index is within the range of the array. If the index is not within array bounds an error message is displayed. Un-selecting this option turns off the array bounds error checking and removes checks for the correct number of dimension of the array. Note This may speed up array manipulation but invalid memory locations may be accessed and result in unexpected behavior or program crashes.
Note Enabling these optimizations may prevent the correct execution of your program.
Addition - If this option is chosen, floating-point additions, or subtractions, are calculated at the compile level. For example:
a = a + 100 - 99 is compiled to a = a + 1.
This usually has no influence on the result of calculations. However, through the limited number of digits of the internal floating-point values, there will be a small divergence as the sum (a, 100 and -99) vary in magnitude. So if a is smaller than _epsDbl*100, so a+100==100. But if a is greater than _epsDbl, then a+1 is not equal to 1, however mathematically correct. Without this optimization only the first two digits of variable a are considered. Only some mathematical calculation methods will be affected. Almost all programs can have this optimization set. Suggestion: Enable
Multiplication - Like the optimization option for floating-point additions and subtractions, there is an optimization for multiplication. Negative effects for this optimization should be even less than that of the addition/subtraction, because the multiplication is more insensitive to magnitude differences. Suggestion: Enable
Division - This option optimizes floating-point division. Division by a constant is replaced by a multiplication of the reciprocal of the constant. For example:
a = a / 10 becomes a= a * 0.1
However, since the number of digits of a Double data type is limited, and the computer works with binary values, the value 0.1 cannot not accurately be represented, so that the division by 10 and multiplying it by 0.1 returns slightly different results (deviation around 1E-16). A reciprocal of division of values of the power of two results in an exact floating-point value (like /8 and *0125). The reason for this optimization is, as almost always, the speed. Suggestion: Disable
SinCos - The Intel processors (Pentium, 486, 387th ..) have built-in functions for sine, cosine and tangent. The values of these functions is to +- 2^63. Greater values (> 1E18) don't result in an error message from the processor, and the return value is 0. A program must test this explicitly. Using this setting uses the processor functions of Sin / Cos / Tan, which are minimally faster (and minimally shorter), but without this test. A value range overrun for Tan leads then to a floating-point stack error and in the case of Sin / Cos mostly to completely absurd errors, because the argument is returned unchanged (Sin (1E40) = 1E40?) Suggestion: Disable
Improve Float Consistency
The Improve Float Consistency option improves the consistency of floating-point tests for equality and inequality by disabling optimizations that could change the precision of floating-point calculations.
By default, the compiler uses the coprocessor’s 80-bit registers to hold the intermediate results of floating-point calculations. This increases program speed and decreases program size. However, because the calculation involves floating-point data types that are represented in memory by less than 80 bits, carrying the extra bits of precision (80 bits minus the number of bits in a smaller floating-point type) through a lengthy calculation can produce inconsistent results.
With this option the compiler loads data from memory prior to each floating-point operation and, if assignment occurs, writes the results back to memory upon completion. Loading the data prior to each operation guarantees that the data does not retain any significance greater than the capacity of its type.
When some other floating point instruction is executed before the IF clause, the equality test is correct, though. To force a reload you could use: ~0‘ some instruction. Suggestion: Enable.
Report FP-errors early - This option results in a small increase of the size and program execution time. If checked, the compiler generates the fwait assembly statement, in particularly with a conversion of floating-point values to integer values. A floating-point error is not reported before the next floating-point statement or in a fwait. The impact of this option is that an (overflow) error is reported a little earlier. Only in extreme cases, the activation of this option is useful for finished programs. Suggestion: Disable
Determines whether Assert, Trace or Debug.Print code is inserted:
In IDE and Gll - Only when the program is compiled in memory in the IDE or as a Gll.
In IDE, Gll, Exe and Lg32 - Inserts code for Assert / Trace / Debug.Print in both the IDE and in the EXE/GLL/LG32 output file.
Never (except Gll) - No insertion of Assert / Trace / Debug.Print code at all except in Gll output files.
It is possible to set the Compiler Properties for each individual program by including the $Compiler command in the program listing.
The Editor Tab, The Printer Tab, The Extra Tab, Compile To Exe/Create Exe Tab
{Created by Sjouke Hamstra; Last updated: 01/12/2021 by James Gaite}