|Command||flash.basic Definition/BASIC Program
Applicable release versions: AP 6.0 FlashBASIC
|Category||BASIC Program (486)|
|Description||converts Pick/BASIC source code into a list of binary instructions called object code.
The "run" verb initiates a program called an interpreter which reads these instructions one at a time and executes the desired actions. Taking this interpretive approach provides swift translation from the Pick/BASIC source, platform independence, small object size, and reasonable performance.
If better performance is desired, the Pick/BASIC compiler can produce "FlashBASIC", or native assembly code from a standard Pick/BASIC object. This FlashBASIC code may subsequently be run in the Pick environment in the same manner as a regular Pick/BASIC program with the exception that FlashBASIC code runs significantly faster.
The "o" option with the "compile" or "basic" verbs invokes FlashBASIC. When complete, the native code produced is appended to the standard interpreted object code. Because FlashBASIC generates machine-specific code, such code must be recompiled when moved to a different platform. Furthermore, FlashBASIC code cannot call interpreted code, or vice-versa. In other words, if a mainline program is compiled with the "o" option, all of its subroutines or "entered" modules must also be created as FlashBASIC.
Choosing a FlashBASIC Level:
The "o" option may be followed by a number, from 1 to 9, which indicates the FlashBASIC (optimization) "level". If not specified, the level defaults to 1, which gives a large performance increase while minimizing compile time and object size. Higher levels increase object size by as much as 100% over that achieved with level 1, and increase compile time exponentially. Furthermore, levels above 1 yield relatively small performance increases for most applications. High levels also tend to use very large amounts of Unix swap space. If the system runs out of swap space, FlashBASIC retries with a lower level. Line numbers (for error messages) and the state of variables within the debugger are also not guaranteed when using a level greater than one. Finally, the exact behavior of a specific level above one is undefined and may be different on different platforms or releases.
Pick Systems advises running routines with various levels to see if the run-time performance increase is worth the compile-time and object-size trade-offs. The best candidates for higher levels are small modules (less than about 200 lines) which have little or no string manipulation and lack significant amounts of screen or disk I/O. Using a level of 9 can cut in half such programs' run time as compared to their speed at level one, while not taking an unreasonably long time to compile.
Producing FlashBASIC without source:
FlashBASIC may be used on an application lacking source code by using the "w" option when compiling (see "compile" for specific instructions.) Therefore, an applications vendor need not ship source code or even a new version of the object code. Customers equipped with FlashBASIC can compile their current applications "as-is". However, it is suggested that future applications be shipped with a Pick/BASIC program, PROC, or macro, that automatically produces the FlashBASIC code at the customers site.
Shipping FlashBASIC code is only recommended when a vendor wishes the code to run on a single platform, and when media size is not an issue.
Compiler Options for use with FlashBASIC:
b Array bounds checking is off by default with FlashBASIC. (It is always generated in the interpreter.) Using the "b" option while compiling adds this feature to the FlashBASIC code, but increases compile time by about 20%, and slows down run-time array accesses.
c Eliminates EOL's (end-of-lines) in both FlashBASIC and interpreted code. Using this with FlashBASIC decreases compile time by 20%, and decreases run-time slightly. However, this prevents the ability to single-step in the debugger.
f Uses floating point arithmetic
h By default, the FlashBASIC compiler attempts to create native code that can be shared by all users. Using the "h" option forces the module to be loaded locally, and is typically used for modules that will be used by only one or two people at any given time.
k This option, when used without the "h" option, forces shared code to remain loaded until the machine is shut down. This option should be used for programs needed by most users of the system. It reduces memory usage and load time drastically when applied to multi-user situations. See the "shpstat" program for monitoring the status of shared programs.
o Triggers the FlashBASIC compiler.
w This option is used when producing FlashBASIC code without source.
Performance Tips for FlashBASIC:
To obtain the best possible run-time performance and compile-time, Pick Systems advises breaking up applications into many small modules. FlashBASIC removes the traditional run-time overhead of large numbers of call's and is able to create more efficient code when the modules are smaller. Furthermore, an application broken into several small modules takes considerably less time to compile than the same application stored in a single item.
The Pick/BASIC "@(x,y)" function speeds up from 10-20 times if the "term" definitions are compiled with the "o" option. For instance, if the current terminal is an IBM 3151 terminal, the "term ibm3151 (co" command compiles and produces FlashBASIC code for the terminal driver. This creates a hidden module for use with FlashBASIC code. For best results, use this feature with high baud rates and/or fast display devices.
Avoid user exits. Standard Pick/BASIC routines compiled with FlashBASIC will probably run just as fast, and possibly faster, than the same routines coded in virtual assembly.
Avoid disk I/O. If an application has read-only tables, it is best to read them all into memory at the beginning of the program rather than reading them piece-meal throughout execution. When reading an item, do a "matread" into a dimensioned array, rather than using several "readv's".