Compiler Directives

A number of compiler features are controlled through compiler directives. You can introduce one or more of the following directives at the beginning of the program text:

bgidriver

bgifont

check_determ

code

config

diagnostics

errorlevel

heap

nobreak

nowarnings

printermenu

project

shorttrace

trace

Many of the compiler directives can be set both in the Visual Prolog development environment (from the menus), through command-line options and in the source code. If a compiler directive exists in the source code, its setting will override values set elsewhere.

Note, that most of the compiler directives are now obsolete for VPI Programs.

(1) bgidriver

When you want to link a particular BGI graphics driver directly into your executable BGI program, use the bgidriver compiler directive followed by the public name for the graphics driver file. This directive is only relevant for plain DOS.

bgidriver "_CGA_driver_far"

(2) bgifont

When you want to link BGI stroked character fonts directly into your executable BGI program, use the bgifont compiler directive followed by the public name for the font file. This directive is only relevant for plain DOS.

bgifont "_gothic_font_far"

(3)check_determ Options|Project|Compiler Options|Nondeterm Check

When you specify check_determ, the Visual Prolog system will give a warning for each program clause that results in a non-deterministic predicate. There are two kinds of non-deterministic clauses:

1. If a clause does not contain a cut, and there are one or more clauses that can match with the same input arguments for that flow pattern.

2. If a clause calls a non-deterministic predicate, and that predicate call is not followed by a cut.

You can use check_determ to guide the setting of cuts. Visual Prolog itself performs extensive tests to decide whether a predicate is deterministic or non-deterministic, so you don't need to fill your programs with cuts merely to save stack space (as is necessary in many other Prolog implementations).

If some predicates are non-deterministic, and you wish to squelch the warning messages, you can precede a predicate declaration by determ or nondeterm; these state that the predicate is to be deterministic or non-deterministic, respectively. For example,

    PREDICATES
        nondeterm repeat
        determ readname(string)

By default, all global predicates are treated as being deterministic. nondeterm allows you to declare a global predicate as non-deterministic. You can also use determ on database predicates intended to have no more than one clause. In this case, the compiler generates simpler code when accessing the predicate.

(4) code Options|Project|Compiler Options|Default for Local Calls

The code directive specifies the size of the internal code array. The default is 4000 paragraphs (16-byte units) for the 16-bit versions of Visual Prolog, otherwise 10000 paragraphs. For larger programs you might need to specify a larger size.

code = Number_of_paragraphs

where Number_of_paragraphs represents the number of memory paragraphs (16 bytes each) required in the code array. For example, the directive:

code = 1024

sets the size of the code array to 16 Kbytes.

The code directive has no influence on the size of an executable file, it simply controls how much memory the compiler should allocate for the compilation.

When the code size exceeds the value 4095, the compiler will switch over to generating FAR calls inside that module. For this reason, you should only use a code size above 4095 if it is really needed. For 32-bit code generation, the size of the code array is practically irrelevant. All code is NEAR, and the operating system will only allocate physical memory when the allocated virtual memory is actually used.

(5) config

This option is only relevant for old DOS textmode windowing applications !

To let a stand-alone application read a configuration file that defines default window attributes, keyboard setup, etc., place the directive:

config "<ConfigFileName>.cfg"

in your program. The application will read <ConfigFileName>.cfg and set the configurations the same way Visual Prolog does with its configuration file.

Various options are passed from the environment to the executable file; these will either be built in during compilation or read from the configuration file during start-up. Some of the values built into the execuatble file can be overwritten by corresponding settings in the configuration file. Here's an overview of these parameters:

	Passed during compilation	Read only from <Config>.cfg	Overwritten from <Config>.cfg
Stack Size	x		x
Heap Size	x
Snow Check	x		x
Keyboard Layout		x
Help Lines		x
Xedit Setup		x

(6) diagnostics Options|Project|Compiler Options|Diagnostics output

When you specify diagnostics, the compiler will display an analysis of your program containing the following information:

the names of the predicates used

whether a predicate is local, global or defined externally

whether a predicate is deterministic or non-deterministic

the size of the code for each predicate

the domain types of the parameters

the flow patterns for each predicate

The diagnostics will also produce a listing of which domains are treated as reference domains, and for which domains the compiler generates internal unification predicates. These predicates are generated when you unify two terms in certain non-simple ways. As an example if you are writing L1=L2 where both L1 and L2 are bound to a list, the compiler needs to test all the elements of the list for equality.

Here's an example of a diagnostics display:

DIAGNOSTICS FOR MODULE: /usr/pdev/test/flow1.pro

Size of PROCONST segment=1705 bytes

Under Options | Global | Environment, it is possible to log the diagnostics output into a file.

(7) errorlevel Options | Project | Compiler Options | Errorlevel

The compiler directive errorlevel enables you to control how detailed the error reporting should be. The syntax is:

errorlevel = d

where d is one of 0, 1, or 2, representing the following levels:

d	Level of Error Reporting
0	Generates the most efficient code. No cursor information will be placed in the code and only the error number will be displayed in an error occurs.
1	This is the default. When an error occurs, its origin (module name and include file, if applicable) will be displayed. The place where the error was detected within the relevant source file will also be displayed, expressed in terms of the number of bytes from the beginning of the file.
2	At this level, certain errors not reported at level 1, including stack overflow heap overflow, trail overflow, etc., are also reported.

In a project, it is the error-level option in each module that controls that module's detail of saving the cursor information. If, however, the error-level option in the main module is higher than that of the sub-modules, Visual Prolog might generate misleading error information. For example, if an error occurs in a module compiled with error level 0, which is included in a main module compiled with error level 1 or 2, the system will be unable to show the correct location of the error. Instead, it will indicate the position of some previously executed code.

(8) heap Options | Project | Compiler Options | Heap Size

Note: this is relevant only if you are going to implement a DOS TSR program.

The heap directive specifies how much memory your .EXE file should allocate when it is started from DOS. If you don't use the heap directive, or if you set it to the value 0, the program will allocate all available memory. This is normally the right way to do it, but if you want to implement a RAM-resident Visual Prolog program, your program should only allocate the necessary memory. The format is:

heap = Number_of_paragraphs

(9) nobreak Options | Project | Compiler Options | Break Check

Note: this is only relevant for DOS textmode programs.

In the absence of the nobreak compiler directive, the Visual Prolog system will generate code to check the keyboard before each predicate call, to ensure that the Ctrl+Break key combination has not been pressed. This slows down program execution slightly and takes up a little extra program space.

The nobreak directive prevents this automatic generation of code. When nobreak is in operation, the only way to escape an endless loop is to reboot the computer (DOS, Phar Lap) or kill the process in some other way. nobreak should only be used after a program has been thoroughly tested.

(10) nowarnings Options|Project|Compiler Options|Single variable

The nowarnings directive suppresses the warnings given when a variable occurs only once in a clause.

Note: This directive is only included for completeness. If a variable occurs only once, either it is a mistake or it should be replaced by the anonymous variable - or a variable starting with an underscore.

(11) printermenu Options|Project|Compiler Options|Print menu in DOS .EXE

Note: this is only relevant for DOS textmode programs.

When this compiler directive appears in the program, Visual Prolog will place code in the executable file for handling the Alt-P key. This means that the user will be able to send screen output to the printer or capture it to a log file.

(12) project Options|Project|Compiler Options|.SYM File Name

The project compiler directive is used in modular programming modular programming. All Visual Prolog modules involved in a project need to share an internal symbol table. If the project is called MYPROJ, the symbol table will be placed in a file called MYPROJ.SYM. The project directive must appear on the first line of a module to specify which project that module belongs to. For example, the following line of code states that a module belongs to the MYPROJ project:

project "myproj"

The project name is not allowed to have a path or an extension.

If the name of the .SYM file is given in the VDE or as option to the commandline compiler, the project directive will be ignored.

See page 257 for complete details about modular programming.