| What Is A Compiler?
Auto Loading The Compiler |
Using The Compiler
The Compiler Accessory |
The Compiler
How The Compiler Works |
Troubleshooting
Compiler Extension Commands |
This approach is known as interpretation, and is used by the standard STOS basic. Whenever a program is run, each instruction is checked against a dictionary stored somewhere in the St's memory, and the appropiate machine code routine is subsequently executed.Another solution to the problem might be to hand the text over to a professional translator. This person could re-write the entire document in English, which you could then read directly. The same idea can aldo be applied to a basic program. In this case, the translator corresponds to a seperate program known as a compiler. The STOS Basic compiler converts the complete STOS Basic program into machine code, producing a new version which can be executed immediately without the need for further translation.
The main advantages of a compiled program over an interpreted one can be summarised like this:
This statement is actually misleading because the real size of an interpreted program is far larger than you would initially expect. Take the game Orbit for instance. Although this is apparently only 60k, if you were to create a run-only version you would need to include all the seperate program modules contained in the STOS folder. The total size of the program would therfore be a surprising 270k. Contrast this with a compiled version of the same program. The final length of Orbit after compilation is around 130k, which is over 140k less than the interpreted version. So although a copiled program may look larger than an interpreted one, it's often considerably smaller.
RUN "CONFIG.BAS"When the main menu appears, click on the next page icon. You can now add COMPILER.ACB to the list of accesories which will be loaded on start-up. Click the mouse on the first free space of the accessory list and enter the line:
COMPILER.ACBIt's a good idea to add the following function key definitions to the standard list. This will simplify the process of loading and saving compiled programs considerably:
F14(shift-F4) fload "*.CMP" F15(shift-F5) fsave "*.CMP"You can now save the new configuration file onto your working copy of STOS Basic using the 'SAVE ON DISC' command. Then copy the COMPILER.ACB onto the language disc so that STOS basic can pick it up off the root directory as it boots up.
ACCLOAD "COMPCOPY"press HELP and select COMPCOPY with the appropiate function key. Now press G to load the entire contents of the folder into the ST's memory. You will then be prompted for a blank disc, which should be placed into drive, and the compiler files will be copied onto your new disc.Depending on the format of your drive, you will be left with either 200k or 480k on each disc. This should prove more than adequate for all but the largest STOS programs. Despite this, it's still possible that you may occaisionally run out of memory. Try removing a few other accessories to save some space.Incidentally, the STOS compiler does NOT allow you to swap discs during the compilation process. So don't try to compile a program from drive A to drive B if you are limited to a single drive.
ACCLOAD "COMPILER"You can now enter the compiler accessory from the [Help] menu in the normal way, at which point you will be presented with the control panel.The main features of the control panel are controlled theough a set of five 'buttons'. These can be activated by simply moving the mouse pointer over the appropiate are and clicking once on the left mouse key.Below follows an explanation of these buttons:
The source button is used to determine whether a program is to be compiled either from memory or the current disc. Clicking on the box underneath toggles between the two possiblities.1) MEMORY
This option informs the compileer that you wish to compile the program you are currently editing. Any of the four program segments may be compiled independently without affecting the conents of the others. Compiling from memory is very fast, but it does consume a large amount of memory.2) DISC
Some programs are simply too large to be compiled directly from memory. In these cases, it's convienient to compile a program from a file on disc. Obviously this is slower than the memory option, but most STOS programs can still easily be compiled within a matter of minutes. Before using this feature, remember to ensure that the COMPILER folder is accessible from the current drive. Also note that the DISC option will be selected automatically whenever memory is running short.
the DEST button selects the eventual destination of the compiled program. Programs may be compiled either to memory or directly into a file on disc.1) MEMORY
This option compiles the program into memory. note that the memory used by this feature is completely seperate from your original program. So you can subsequently save the compiled program onto the disc without losing your current STOS Basic program.2) DISC
If you choose the disc as the destination, the code will be compiled straight into a file without taking up any valuable memory. Since it's much slower than the MEMORY directive, it's only really suitable for compiling particularly large STOS Basic programs.
The compilation process is started when you click on the COMPILE button with the mouse. As your program is compiled, a horizontal bar grows across the screen. When this completes it's journey, the compilation has been successfully concluded. But if an error is detected, the compiler is terminated and you are returned to the STOS basic editor.Occaisionally, errors will be generated from supposedly bug-free programs. The reason for these errors is that the interpreter is only capable of detecting an error in the line which is currently being run. So if an error exists in a section of code which is rarely executed, it can easily be missed. Since the compiler tests the whole program, rather than just the current line, it is able to discover all the syntax errors in your program at once.
This option exits the compiler accessory and returns you to the editor.
This allows you to choose whether the compiled program is to be run either from STOS Basic or directly from the GEM desktop.1)BASIC
This is the default, and generates a compiled program which can only be run within the STOS Basic system. Files produced with this option have the extension "*.CMP"2)GEM
The GEM directive allows you to create a program which can be run independently of the STOS Basic system. These programs have the extension "*.PRG", and can only be executed from the GEM desktop. Furthermore, since they consist entirely of machine code, they cannot be listed or amended from STOS Basic. Programs in this format can be sold or distributed in any way you like. Depending on the facilities used, the GEM run version of the file will be between 40 and 80k larger than the equivalent STOS run program.
Whenever the compiler is loaded, a number of configuration seetings are read from a special OPTIONS.INF file in the COMPILER folder. These settings provide you with the ability to fine tune the program to your particular needs. They can be changed at any time by simply clicking on the OPTIONS button from the menu. From here, the following options are selectable.
This option is used to set the frequency of certain internal checks. Although the co-ordinates of a STOS sprite are updated using interrupts, the sprites on screen are only moved prior to the execution of a basic instruction. While this is happening, STOS also checks for CONTROL + C and tests whether the pulldown menus have been accessed by the user.1)COMPILER TEST OFF
This completely removes the tests from the compiled code. The result is that the program completely ignores CONTROL + C, refuses to open your menu's and does not automatically update your sprites when they are moved. Set against this however, is the fact that the final code will be about 10% faster.2)COMPILER TEST NORMAL
A check is performed before every branch such as GOTO, NEXT, REPEAT, WEND, ELSE and THEN. Tests are also carried out prior to slow instructions such as PRINT and INPUT. This setting is used as the default.3)COMPILER TEST ALWAYS
Adds a test before every STOS Basic instruction, leading to particularly smooth sprite movements. As you would expect, programs compiled this way are slightly slower than with NORMAL or OFF settings.Note that these settings can be changed directly from your STOS Basic programs.
These options allow you to tailor the default environment of the compiled program which is to be run from the desktop. They have no effect on any programs compiled for use within STOS Basic.1)RESOLUTION MODE
This directive allows you to select between Low or Medium resolution when you program is executed from the desktop using a colour monitor. To change the resolution simpy click on the relevant icon. Note that if your program is subsequently run on a monochrome monitor, this option is completely ignored.2)BLACK AND WHITE ENVIRONMENT
Chooses between normal or inverse graphics when a Gem-run program is executed on a monchrome monitor. NORMAL: Uses white text on a black background.INVERSE: Produces a black text on white paper display.3)DEFAULT PALETTE
This allows you to assign the colours which will be initially used for your graphics.The first icons select one of the 16 possible colours to be set (4 in medium resolution). Click on the ++ box to increment the colour number by one, and to decrement the colour by one click on the -- box.The rightmost icon buttons set the exact hue of this colour.Click on a + to add one to the red, green or blue component to the colour respectively.- buttons subtract one from the appropiate colour value.For speed you can simply step through the values by pressing the right mouse button. But for subtle single steps use the left button. This applies for any other option that uses + and - icons.
4)FUNCTION KEYS
The window used for the STOS function key assignments will normally be drwan on screen during the initialisation process. This adds a slightly unprofessional feel to your program. You can avoid this effect using the following directive from the compiler menu.ON: The function key window is automatically drawn at the top of the screen during initialisation.OFF:The function key window is omitted.5)CURSOR
Activates or deactivates the text cursor when the program is initialised. This setting can be changed at any time from within your compiled program using the CURS ON/OFF commands.6)MOUSE
The MOUSE option allows you to decide whether the mouse will be turned on or off as a default. As you might expect, you can reactivate the mouse using the STOS Basic SHOW instruction.7)LANGUAGE
Toggles the language used for any system messages between English and French.8)MAIN MENU
Returns you to the main compiler menu.9)NEXT PAGE
Displays the next page of options (see below).a)LOAD OPTIONS
Loads an existing set of options from an OPTIONS.INF file from the disc.b)SAVE OPTIONS
Saves the current options to an OPTIONS.INF file in the COMPILER directory.c)LOADED CHARACTER SETS
The compiled program normally includes all three of the STOS character sets. But if you only intend to run your program in a single resolution, the character sets used by the remaining modes will waste valuable memory. The STOS compiler therefore lets you select precisely which character sets are to be loaded.WARNING! Any attempt to run your program in the wrong resolution after this option has been set will crash the ST completely.
d)LOADED MOUSE POINTERS
As with the character sets, you can use this option to omit the data used by the mouse pointers in the resolutions your program will not be using, again, improper use will cause a crash.e)WINDOW BUFFER SIZE
The windowing system used by STOS Basic, normally keeps a copy of the entire contents of all windows which your program has defined. If your program dosen't use windows, then this memory will be completely wasted. The default setting is 32k. This can be altered in 1k steps by clicking on the '++' and '--' boxes. You can calculate the memory needed by your windows by using the following simple rules:Each character position, takes up two bytes in medium/high resolution and four bytes in low resolution. In low resolution the main STOS screen holds 1000 characters, so the memory taken by this screen is 1000*4 or 4000 bytes. If you change this setting, don't forget about the function key window and the file-selector!, these use about 8k of memory.f)SPRITE BUFFER SIZE
Before a STOS sprite is copied to the screen, it is first drawn into a seperate memory buffer. If you are really pressed for space and you are only using the smallest sprites, you can reduce this buffer to around 1k.Again, be very careful with this, because one cock-up will crash your ST.Well, i think thats about it for this issue, in third part we'll look at how the compiler works.
SOURCE DESTINATION COMMENTS MEMORY MEMORY Very fast, but uses the maximum amount of memory. DISC MEMORY Slower, but uses considerably less memory. MEMORY DISC Slightly slower than disc to memory but the memory usage can occaisionally be less. DISC DISC Uses very little memory.The only limit to the size of your program is the amount of available disk space. This is quite slow on a single floppy. Wen you get an out of memory error, you should try each of the above options in turn. If you still have problems, you will need to reduce the size of the program in some way.The easiest solution is to get rid of the permanent memory banks which are used by the program. These can be defined during program initialisation using the RESERVE command and loaded seperately from disc. Your programs initialisation phase will now include the following steps:
10 gosub 1000 20 a(10)=50 30 end 1000 dim A(100):returnThis causes an error because when the compiler checks line 20, it has yet to encounter the DIM statement at line 1000. It therefore generates an erroneous error message. The solution to this problem is simply to dimension all arrays at the start of the program. So you can fix the above routine by replacing line 10 with:
10 DIM A(100)
on A goto 1000,10000+a*5,500will produce a syntax error. This should be replace by:
on A goto 1000,10010,500
10 print "hi there" 20 goto 10 30 prunt "this is an error"If you try to run this program using the interpreter, then the spelling mistake at line 30 will be missed, since it is never actually executed. But if you compile it, the compiler will detect it and ask you to correct it.
10 dim b(15) 20 for b(3)=1 to 10 30 reserve as screen b(3) 40 next b(3)The difficulty can be avoided by either using a simple variable as the index, or defining the banks explicitly outside the FOR..NEXT. For example:
20 for i=1 to 10 30 reserve as screen i 40 next i
10 dim a(10000),b(10000) 20 for i=0 to 10000:a(i)=i:next i:rem load an array 30 comptest off:timer =0:print "compiler test off" 40 for i=0 to 10000:b(i)=a(i):next i 50 print "loop executed in";timer/50.0;" seconds" 60 comptest on:timer =0:print "compiler test on" 70 for i=0 to 10000:b(i)=a(i):next i 80 print "loop executed in ";timer/50.0;" seconds"Try stopping program with Control+C after the compiler tests have been switched off. The program will terminate around lline 60, since this is the first time the Control + C test has been performed.