Bartels User Language - Programmer's Guide Chapter 3 Programming System

Contents

3.1.1

Program Storage

3.1.2

Machine Architecture

3.2.1

Mode of Operation

3.2.2

Compiler Call

3.2.3

Error Handling

3.3.1

Mode of Operation

3.3.2

Program Call

3.3.3

Error Handling

3-1

User Language Machine Instruction Set

3-2

Key-driven Program Call

3-3

Event-driven Program Call

3.1 Conventions

The Bartels User Language programming system consists of the Bartels User Language Compiler and the Bartels User Language Interpreter. The Compiler translates User Language source code into User Language machine code (programs or libraries), performs static library linking and generates information required for dynamic linking. The User Language Interpreter is used for (dynamically linking and) executing User Language machine programs. Since the User Language Comiler and the User Language Interpreter are applied time-independent (i.e., they are implemented in different program modules), the following conventions are required for correct program access.

3.1.1 Program Storage

The Bartels User Language Compiler stores successfully translated User Language programs (or libraries) to the ulcprog.vdb file of the Bartels AutoEngineer programs directory. The name of the machine program emerges from the program source code file name. The current User Language Compiler version and a caller type coding (determining the compatible Bartels User Language interpreter environments) are stored with the machine program code. The Compiler also stores any information required for dynamic link processes (i.e., library linking to be applied at program runtime). When calling a program, the User Language Interpreter loads the machine program with the specified name from the ulcprog.vdb file of the Bartels AutoEngineer programs directory. The program's User Language Compiler version is checked to ensure compatibility with the current User Language Interpreter version (otherwise the Interpreter might not understand the program structure). The caller type coding stored with the program is used to check whether the index variable types and system functions referenced by the program are implemented in the current User Language Interpreter environment. During program load, the Interpreter automatically performs all of the required dynamic link processes. The libraries to be linked with the program are checked for compatibility as well.

3.1.2 Machine Architecture

The machine architecture implemented in the Bartels User Language corresponds to a stack machine. The instruction set of this stack machine contains load commands (for loading variable values and/or constants), ALU commands (for activating the arithmetic-logic unit of the machine), store commands (for assignments), function call commands and stack management commands.

The instruction set of this machine is listed in table 3-1. The stack columns provide information on how many stack arguments are required by each instruction and how the stack size changes when executing the instruction.

Table 3-1: User Language Machine Instruction Set

3.2 Compiler

The Bartels User Language Compiler translates User Language source code into User Language machine programs and/or User Language libraries. User Language machine programs can be executed by the User Language Interpreter. User Language libraries usually are generated from frequently used source code. User Language library machine code can be linked to other User Language machine code (programs or libraries). Library linking can be done either statically (at compile time by the User Language Compiler) or dynamically (at runtime by the User Language Interpreter). As an advantage of the User Language library concept, frequently used source code needs to be compiled just once and can subsequently be referenced through linking, which is much faster than compiling.

3.2.1 Mode of Operation

At the compilation of User Language source code the User Language Compiler performs comprehensive syntactic and semantic consistency checks, removes redundancies from the program and/or library, and finally produces - in very compact form - a source code equivalent User Language machine code (User Language program and/or User Language library). The built-in linker of the Compiler performs static library linking and generates information for dynamic linking on request. This is applied with the subsequently described sequence of operations.

Syntax Analysis and Semantic Check

The first phase of the compilation process performs syntactic analysis. A parser pass is applied to handle formal problems, i.e., to check whether the sequence of words and symbols from the source code represents a syntactically valid User Language program and/or library. With this parser pass, semantic checks are performed in order to ensure consistency and uniqueness of the source's variable, parameter, and function definitions. As a result, this first parser pass (pass 1) generates an internal symbol table, which is required for the semantic test performed in the second parser pass (pass 2). The semantic test includes a context-sensitive analysis of the source code text to suppress the misuse of the defined program objects, i.e., the semantic test checks on the validity of the usage of names as well as the admissibility of the operations on the defined objects.

Machine Code Generation

The source code equivalent machine code is constructed already whilst running the semantic test, i.e., with the second parser pass (pass 2). The machine code generated by the Compiler corresponds with a valid machine program and/or library only if the semantic test was completed without errors.

Linker

The built-in linker of the Compiler performs static library linking and generates information for dynamic linking on request.

The static link process (Compiler option -lib) binds machine code from required User Language libraries to the machine code currently to be translated. The requested libraries are checked for Compiler version compatibility. References to library machine code such as global function and/or variable addresses are resolved with consistency check.

The dynamic link process (Compiler option -dll) only simulates machine code binding. As a result, dynamic link library relocation tables for resolving references to dynamic link libraries at runtime is stored with the machine code. The information provided with these relocation tables is later used by the User Language Interpreter to check library compatibility when performing dynamic link processes at runtime. Note that User Language library modifications require the recompilation of all User Language programs and/or libraries containing dynamic link requests to the changed library.

Optimizer

The optimizer of the User Language Compiler can be activated using the Compiler option -O. The optimizer frees the machine code from redundancies and modifies the machine code in order make it more efficient. The optimizer recognizes and eliminates unused code segments as well as unreferenced function, variable, and parameter definitions. It changes variable references to constant accesses if possible (Constant Propagation), and it accomplishes algebraic optimizations. In most cases optimization considerably reduces machine code's memory and runtime requirements.

The optimization introduces a very useful side effect: optimizer-modified machine code can be checked for special programming errors, which the Compiler otherwise would not have been able to recognize.

Machine Code Check

After generating the machine code, the Compiler checks it again for fatal errors, which the Compiler eventually is able to recognize by analyzing the machine code. Such errors are division by zero, endless loop constructs and endless-recursive function calls.

Listing File Output

The User Language Compiler can be caused optionally to produce a listing file. The specifications in this file can be useful for locating errors occurred at runtime (i.e., with the program execution) only. The complete listing file content is composed of general program and/or library specifications (name, version, caller type), dynamic link request information, static link library reference listings, tables of the definitions (functions, variables, structures, etc.) used throughout the machine code, and the machine code listing (i.e., the list of the machine instructions including source text and machine code line number specifications).

The listing option -l of the User Language Compiler supports different modes for making the output more or less verbose. With this option, it is possible to, e.g., restrict output for User Language library documentation purposes (library function reference).

The -ld option allows for the specification of an alternative output directory for the listing files created with the -l option. This option is useful when applying make utilities for automatically compiling modified User Language programs as it allows to keep the source directories clean. With the BAE software, a makefile is provided in the baeulc directory. This makefile defines the dependencies between User Language programs and include files and works with listing files in a subdirectory (lst).

Machine Code Storage

With the final phase of the compilation process the machine code generated by the User Language Compiler is stored to the ulcprog.vdb file in the Bartels AutoEngineer programs directory. Each machine code is named according to the destination element name specified with the Compiler call (see Compiler options -Source, -cp, -cl). At the storage of machine code special database classes are assigned to User Language programs and/or User Language libraries, respectively.

Special User Language Compiler options allow for the deletion of User Language programs (option -dp) and/or libraries (option -dl) stored to ulcprog.vdb. With this option, it is possible to cleanup ulcprog.vdb from obsolete and/or redundant machine code.

3.2.2 Compiler Call

The translation of an User Language program and/or an User Language library is started with the User Language Compiler call.

Synopsis

The User Language Compiler must be called from the operating system shell. The synopsis for calling the Compiler is:

ulc [-wcon|-wcoff] [[-S[ource]] srcfile...]
    [-lib libname...] [-dll libname...]
    [{-cp|-cl} [dstname...]]
    [-I[nclude] includepath...] [-D[efine] macroid...]
    [-O[0|1]] [-e[0|1]] [-w[0|1|2|3|4]] [-t[0|1]]
    [-l[0|1|2|3|4|5]] [-ld listingdirectory]
    [-dp prgname...] [-dl libname...]
    [-ulp prgfilename] [-ull libfilename]
    [-log logfilename]

On syntactically wrong Compiler calls, the correct ULC command syntax is displayed, and the compilation process is aborted.

Options

Command line options of the User Language Compiler consist of the dash (-) or slash (/) start character followed by the option specification. Single-character option specifications optionally followed by a mode or toggle number are often known as switches or flags. Such special options can be grouped as in /l2Ow3 or -O1w3l2, which both select listing mode 2, activate the optimizer, and set the warning severity level to 3.

Wildcard Option [-wcon|-wcoff]

The wildcard option is used to activate or deactivate wildcard processing at the specification of file and/or element names. On default wildcard processing is activated, i.e., omitting the wildcard option leaves wildcard processing activated. Option -wcon can be used for explicitly activating wildcard processing. With wildcard recognition activated, the character ? can be used for matching any arbitrary character, and the character * can be used for matching an arbitrary number of arbitrary characters. Option -wcoff can be used to turn off wildcard processing. Wildcard recognition must be deactivated for explicitly processing names containing wildcard characters such as scm_? or ged_*.

Source File Option [[-S[ource]] srcfile...]

This option is used for specifying the file name(s) containing the source code to be compiled. File name specifications can contain a directory path, i.e., the source file names need not reside in the current directory. Wildcards are supported with the source file name specification if wildcard recognition is activated (see option -wcon above). Source file names can be specified with or without file name extension. On source file name specifications without extension the Compiler automatically assumes and/or appends file name extension .ulc. I.e., source file names with non-default extension must be specified with their extension, respectively. It is possible to, e.g., generate User Language libraries from include files usually named with extension .ulh. The type of User Language machine code to be generated is designated with either option -cp (User Language programs; see below) or option -cl (User Language libraries; see below). The name of the machine code element to be generated is derived from the source file name by stripping the directory path and the file name extension from the source file name. Non-default destination program and/or library element names can be specified with options -cp and -cl (see below). The -Source and/or -S option keywords are not required with source file specifications where file names cannot be intermixed with other name specifications, e.g., if source file names are the first names specified on the ULC command line. However the -Source (and/or -S) option can be used for explicit source file specification to avoid ambiguities in case where source file names are not the first name specifications on the ULC command line. At least one source file specification is required if neither option -dp nor option -dl (see below) is specified.

Static Link Option [-lib libname...]

The static link -lib option requires one or more library name specifications and at least one valid source file specification (see option -Source above). The machine code of the libraries specified with the -lib option must be available in the ulcprog.vdb file of the BAE programs directory, i.e., the required libraries must be compiled before they can be linked. The built-in linker of the User Language Compiler binds the machine code of these libraries to the machine code currently to be translated.

Dynamic Link Option [-dll libname...]

The dynamic link option -dll requires one or more library name specifications and at least one valid source file specification (see option -Source above). The machine code of the libraries specified with the -dll option must be available in the ulcprog.vdb file of the BAE programs directory, i.e., the required libraries must be compiled before they can be linked. The built-in linker of the User Language Compiler stores dynamic link request information with the machine code to enable the User Language Interpreter to perform dynamic linking of the requested libraries at runtime.

Create Program/Library Option [{-cp|-cl} [dstname...]]

The create option can be used to designate the type of machine code to be generated. The User Language Compiler can create either User Language programs or User Language libraries. On default, program generation request is assumed, i.e., omitting both the -cp and the -cl option defaults to User Language program creation. Option -cp explicitly selects program generation whilst option -cl selects library generation; both options must not be used together. On default, the destination element name is derived from the corresponding source file name; both the directory path and the source file name extension are stripped from the source file name to generate the destination element name. Options -cp and -cl allow for the specification of non-default destination program and/or library names. Only onesource file specification (see option -Source) is allowed when explicitly specifying destination element name(s) with options -cp and -cl. The machine code generated by the Compiler is stored with the specified destination element name to the ulcprog.vdb file in the BAE programs directory. Wildcards are not supported with destination element name specifications. Multiple destination element name specifications can be used to store the machine code of a single source under different names, e.g., to generate programs scm_st, ged_st, etc. from a single source file named bae_st.ulh.

Include Path Option [-I[nclude] includepath...]

The -Include (and/or -I) option is used for specifying multiple alternate include paths for include file name search. At least one include path argument is required. When encountering an #include preprocessor statement, the Compiler first checks the current directory for include file access and then searches the include paths in the sequence specified with the -Include option until the requested include file is found.

Define Option [-D[efine] macroid...]

The -Define (and/or -D) option is used for defining macros at the User Language Compiler call. At least one macro identifier is required. This option corresponds with the #define preprocessor statement, i.e., macros defined with the -Define option can be checked with the #ifdef or #ifndef preprocessor statements, thus giving more control on conditional compilation to the Compiler.

Optimizer Option [-O[0|1]]

The -O option is used to activate or deactivate the optimizer of the User Language Compiler. On default the optimizer is deactivated, i.e., omitting this option leaves the optimizer deactivated. Option -O or -O1 activates the optimizer. Option -O0 explicitly deactivates the optimizer. The optimizer frees the machine code from redundancies, and modifies it to make it more efficient. Optimizing machine code significantly reduces disk space and main memory requirements, and the resulting machine code can be loaded and executed much faster. It is strongly recommended to activate the optimizer.

Error Severity Option [-e[0|1]]

The -e option is used for setting the error severity level. On default the error severity level is set to 1, i.e. omitting this option selects error severity level 1. Option -e0 sets error severity level 0. Option -e or -e1 explicitly sets error severity level 1. Error severity level 1 compiles all specified sources; error severity level 0 causes the Compiler to stop the compilation process on any errors occurred during a single source compilation.

Warning Severity Option [-w[0|1|2|3|4]]

The -w option is used for setting the warning severity level in the range 0 to 4. On default, the warning severity level is set to 0, i.e., omitting this option selects warning severity level 0. Omitting explicit level specification with this option as with -w defaults to warning severity level 3. Each type of warning defined with the Compiler is assigned to a certain warning severity level. The Compiler only prints warnings with a warning severity level less than or equal the level selected with the -w option since higher warning severity levels denote less importance. With this option, it is possible to suppress less important warning messages.

Top Level Warnings Only Option [-t[0|1]]

The -t option controls whether warning messages related to the compilation of include files are omitted or not. On default (i.e., if this option is not specified or if its value is set to 0), warning messages related to the compilation of both top level source code files and include files are issued. Setting this option value to 1 prevents the User Language Compiler from issuing warning messages related to the compilation of include files, thus simplifying the analysis of warning messages when working with standard include files containing functions and variables which are not used by every program.

Listing Option [-l[0|1|2|3|4|5]]

The -l option is used to control the listing file output. Listing modes 0 to 5 can be specified. Mode 0 won't produce any listing output and mode 5 produces the most detailed listing. On default, listing mode 0 is selected, i.e., no listing file is generated if this options is omitted. Omitting explicit listing mode specification with this option as with -l defaults to listing mode 5. The listing output file name is derived from the corresponding source code file name, where the original file name extension is replaced with extension .lst. The listing file is for user information purposes only, i.e., it is not required by system.

Listing Directory Option [-ld listingdirectory]

The -ld option allows for the specification of an alternative output directory for the listing files created with the -l option. This option is useful when applying make utilities for automatically compiling modified User Language programs as it allows to keep the source directories clean. With the BAE software, a makefile is provided in the baeulc directory. This makefile defines the dependencies between User Language programs and include files and works with listing files in a subdirectory (lst).

Delete Program Option [-dp prgname...]

The -dp option is used for deleting previously compiled programs from the ulcprog.vdb file in the BAE programs directory. At least one program element name is required. Wildcards are supported with the program element name specification if wildcard recognition is activated (see option -wcon above). Warnings are issued when trying to delete non-existent programs. Program deletion is always processed before any source code compilation to avoid compilation process conflicts such as deleting a program immediately after it has been compiled with the same ULC call.

Delete Library Option [-dl libname...]

The -dl option is used for deleting previously compiled libraries from the ulcprog.vdb file in the BAE programs directory. At least one library element name is required. Wildcards are supported with the library element name specification if wildcard recognition is activated (see option -wcon above). Warnings are issued when trying to delete non-existent libraries. Library deletion is always processed before any source code compilation to avoid compilation process conflicts such as deleting a library immediately after it has been compiled with the same ULC call.

Program Database File Name Option [-ulp prgfilename]

On default, the User Language Compiler stores User Language programs to a file named ulcprog.vdb in the Bartels AutoEngineer programs directory. The -ulp option can be used to select a different User Language program database file.

Library Database File Name Option [-ull libfilename]

On default, the User Language Compiler stores User Language libraries to a file named ulcprog.vdb in the Bartels AutoEngineer programs directory. The -ull option can be used to select a different User Language library database file.

Log File Option [-log logfilename]

The User Language Compiler prints all messages to standard output and to a log file. Log file output is generated to save long message lists which could be generated at the compilation of different sources. On default the log file name is set to ulc.log (current directory). The -log option can be used to specify a non-default log file name.

Examples

Compilation of the User Language program contained in ulcprog.ulc with optimization and warning message output; the produced machine program is stored with the name ulcprog to the ulcprog.vdb file of the BAE programs directory:

ulc ulprog -Ow

Compilation of the User Language program contained in ulcprog.ulc with listing file output (to ulcprog.lst); the produced machine program is stored with the name newprog to the ulcprog.vdb file of the BAE programs directory:

ulc ulprog -l -cp newprog

Deleting the User Language programs named ulcprog and newprog and all User Language libraries with names starting with test and ending on lib from the ulcprog.vdb file of the BAE programs directory:

ulc -dp ulprog newprog -dl test*lib

Generate User Language library libsll from source file libbae.ulh (optimizer is activated; listing output is directed to file libbae.lst):

ulc libbae.ulh -cl libsll -l2O

Compile all current directory files with extension .ulc and statically link the generated program machine codes with library libsll (macro USELIB is defined for controlling conditional compilation; optimizer is activated):

ulc *.ulc -Define USELIB -lib libsll -O

Generate libraries libstd and stdlib from source file std.ulh (optimizer is activated, warning severity level is to 2):

ulc -w2 -O -cl libstd stdlib -Source std.ulh

Generate library liblay from source file \baeulc\lay.ulh with library libstd dynamically linked (optimizer is activated, warning severity level is set to 3, Compiler messages are directed to log file genlib.rep instead of ulc.log):

ulc /wO -cl liblay -S \baeulc\lay.ulh -dll libstd -log genlib.rep

Generate programs laypcr and tracerep from source files laypcr.old and tracerep.ulc with library liblay dynamically linked (optimizer is activated):

ulc laypcr.old /dll liblay /cp -O /S tracerep

3.2.3 Error Handling

One of the most important Compiler features is the error handling. This is due to the fact, that source codes, which contain errors and/or redundancies are most frequently processed (a correct, redundancy-free program is usually only compiled once). The error and warning messages issued by the Compiler are intended to support the programmer in developing error-free User Language programs and/or libraries without redundancies as quickly as possible.

The User Language Compiler prints all messages to the screen and to a log file. Log file output is generated to save long message lists which could be generated at the compilation of different sources. On default, the log file name is set to ulc.log (current directory); a non-default log file name can be specified using the -log Compiler option (see above).

This section lists all error and warning messages defined with the User Language Compiler. At the appearance of errors no valid machine code can be produced. Warnings indicate the generation of valid machine code, which, however, might show up with unpredictable side effects at runtime. With each message a line number is included wherever possible to localize the corresponding error. This line number specification refers either to the source code file (denoted by "Ll") or to the machine code (denoted by "Lp").

The warnings messages listed below are preceded with a number enclosed in square brackets. These are not part of the actually printed warnings, but denote the minimum warning severity level to be set with the -w option to prompt the User Language Compiler to issue the corresponding warnings. Warnings assigned to severity level 0 are always printed, regardless of the selected warning severity level.

General Messages

On syntactically wrong Compiler calls, the correct ULC command syntax is displayed, and the compilation process is aborted.

The following general Compiler messages denote current Compiler actions and/or issue resumes on the compilation process:

Deleting programs from "n"...
Program 'n' deleted.
Deleting libraries from "n"...
Library 'n' deleted.
Loading/linking libraries...
Compiling source code file "n"...
Program 'n' successfully created.
Library 'n' successfully created.
Source code file "n" successfully compiled.
e errors, w warnings.
User Language Compiler aborted!
User Language Compilation successfully done.

The following Compiler messages indicate general errors regarding the Compiler call, such as missing Compiler runtime authorization, invalid file and/or element name specifications, file access problems or link library access problems:

ERROR : Please check your User Authorization!
ERROR : File name "n" is too long!
ERROR : File name "n" contains invalid chars!
ERROR : Element name 'n' is too long!
ERROR : Element name 'n' contains invalid chars!
ERROR : Error writing listing file "n"!
ERROR : Error creating ULC log file "n"!
ERROR : Too many source code files specified!
ERROR : Source code file "n" not found!
ERROR : Library 'n' not found!
ERROR : User Language Library 'n' Version not compatible!

The following messages indicate general problems accessing specified directories and/or program or library elements or notify of link library inconveniences:

[0] WARNING : Directory 'n' not found/not available!
[0] WARNING : Program 'n' not found!
[0] WARNING : Library 'n' not found!
[0] WARNING : Library 'n' is not optimized!

Fatal Errors

The following internal compiler messages either indicate memory management errors or refer to Compiler implementation gaps:

(Ll) ERROR : List overflow!
(Ll) ERROR : Out of memory!
(Ll) ERROR : INTERNAL ERROR IN function -- PLEASE REPORT!

Parser Errors

The following messages indicate source code file access and/or syntax errors:

(Ll) ERROR : Cannot open source file "n"!
(Ll) ERROR : Cannot read source file "n"!
(Ll) ERROR : Source file expression too complex ('s')!
(Ll) ERROR : Source file element too long ('s')!
(Ll) ERROR : Syntax error at 'string' (unexpected symbol)!
(Ll) ERROR : Unspecified syntax analyzer error!

Semantic Errors and Warnings

The following errors can be issued whilst performing semantic source code analysis:

(Ll) ERROR : Identifier 'n' is too long!
(Ll) ERROR : Character 's' is too long / no character!
(Ll) ERROR : String "s" is too long!
(Ll) ERROR : Numeric value 's' is too long!
(Ll) ERROR : Invalid numeric value 's'!
(Ll) ERROR : Type 'n' not defined!
(Ll) ERROR : Multiple definition of type 'n'!
(Ll) ERROR : Function 'n' not defined!
(Ll) ERROR : Multiple definition of function 'n'!
(Ll) ERROR : Function 'n' is a system function!
(Ll) ERROR : Function parameter 'n' not defined!
(Ll) ERROR : Multiple definition of function parameter 'n'!
(Ll) ERROR : Multiple declaration of function parameter 'n'!
(Ll) ERROR : Variable 'n' not defined!
(Ll) ERROR : Multiple definition of variable 'n'!
(Ll) ERROR : Assignment to constant or result value is attempted!
(Ll) ERROR : Not an array; cannot perform index access!
(Ll) ERROR : Invalid array index specified!
(Ll) ERROR : Array subscript out of range!
(Ll) ERROR : Access to member ('n') of unknown struct!
(Ll) ERROR : Structure 'n' unknown/invalid!
(Ll) ERROR : Multiple definition of structure 'n'!
(Ll) ERROR : Structure member 'n' unknown/invalid!
(Ll) ERROR : Multiple definition of structure member 'n'!
(Ll) ERROR : Index 'n' unknown/invalid!
(Ll) ERROR : Index variable 'n' unknown/invalid!
(Ll) ERROR : 'n' is not an index variable!
(Ll) ERROR : 'forall'-index not defined for 'of'-index 'n'!
(Ll) ERROR : 'continue' not within a loop!
(Ll) ERROR : 'break' not within a loop or 'switch'!
(Ll) ERROR : 'void' function 'n' cannot return a value!
(Ll) ERROR : Function 'n' must 'return' a valid value!
(Ll) ERROR : 'return' expr. not type-compat. to function 'n'!
(Ll) ERROR : Expression not type-compatible to parameter 'n'!
(Ll) ERROR : Expression not type-compatible to variable 'n'!
(Ll) ERROR : Operand not type-compatible to the 'n'-operator!
(Ll) ERROR : Operands not type-compatible to the 'n'-operator!
(Ll) ERROR : Invalid assignment to active loop index variable!
(Ll) ERROR : Invalid 'n'-expression!
(Ll) ERROR : Unknown/undefined function 'n'!
(Ll) ERROR : Function 'n' - not enough parameters specified!
(Ll) ERROR : Function 'n' - parameter not compatible!
(Ll) ERROR : Function 'n' - parameter out of range!
(Ll) ERROR : Invalid '#if-#else-#endif' construct!
(Ll) ERROR : Identifier 'n' is defined as macro!
(Ll) ERROR : Access to void macro 'n'!
(Ll) ERROR : Cannot store BNF to UL library!
(Ll) ERROR : BNF redefined!
(Ll) ERROR : BNF symbol 'n' unknown/undefined!
(Ll) ERROR : BNF production 'n' double defined!
(Ll) ERROR : BNF reduce/reduce conflict at production 'n'!
(Ll) ERROR : BNF terminal symbol 'n' is invalid!
(Ll) ERROR : BNF comment delimiter 's' is invalid!
(Ll) ERROR : BNF function 'n' not of type 'int'!
(Ll) ERROR : Division by zero is attempted!
(Ll) ERROR : Endless loop!
(Ll) ERROR : Function 'n' - recursive call!
(Lp) ERROR : Stack overflow!
ERROR : End of file reached where '}' has been expected!
ERROR : Incompatible index/function reference(s)!

The following warnings can be issued whilst performing semantic source code analysis:

[1] (Ll) WARNING : BNF contains no valid productions!
[2] (Ll) WARNING : Function 'n' - default return value used!
[1] (Ll) WARNING : Function 'n' - too many parameters specified!
[2] (Ll) WARNING : Function 'n' - change of parameter n will be ignored!
[2] (Ll) WARNING : Function 'n' - change of parameter 'n' will be ignored!
[2] (Ll) WARNING : Constant 'n'-expression!
[2] (Ll) WARNING : Expression has no side-effects!
[2] (Ll) WARNING : Function 'n', local variable 'n' hides global variable!
[2] (Ll) WARNING : Function 'n', parameter 'n' hides global variable!
[4] (Ll) WARNING : Variable 'n' has not been initialized!
[4] (Ll) WARNING : Macro 'n' redefined!

Optimizer Warnings

The following warnings are issued by the optimizer and indicate source code redundancies:

[1] (Ll) WARNING : BNF is not referenced!
[2] (Ll) WARNING : Global variable 'n' not referenced!
[2] (Ll) WARNING : Function 'n' not referenced!
[2] (Ll) WARNING : Statement is not reached!
[3] (Ll) WARNING : Function 'n', Local variable 'n' not referenced!
[3] (Ll) WARNING : Function 'n', Parameter 'n' not referenced!
[4] WARNING : Library function 'n' not referenced!
[4] WARNING : Library variable 'n' not referenced!
[4] WARNING : Dynamic Link Library 'n' is not referenced!

Database Access Errors

The following messages indicate errors on the storage of the machine program:

ERROR : Cannot create database file "n"!
ERROR : Read/write error whilst accessing file "n"!
ERROR : Too many open files!
ERROR : File "n" is not a database/DDB file!
ERROR : File structure is damaged in file "n"!
ERROR : File structure is erroneous in file "n"!
ERROR : Function not available for old format!
ERROR : Database limit exceeded!
ERROR : File "n" is not compatible with program version!
ERROR : Element 'n' not found!
ERROR : Element 'n' exists already!
ERROR : File "n" not found!
ERROR : Record end reached!
ERROR : Unspecified database error!

3.3 Interpreter

The Bartels User Language Interpreter is integrated to the Schematic Editor, the Layout Editor, the Autorouter, the CAM Processor, the CAM View module and the Chip Editor of the Bartels AutoEngineer. I.e., the Bartels User Language Interpreter can be used for calling Bartels User Language programs from each of these BAE modules.

3.3.1 Mode of Operation

The User Language Interpreter is activated by calling a User Language program from one of the valid interpreter environments. Any User Language program call is processed by applying the subsequently described sequence of operations.

Program Load, Dynamic Link

When calling a User Language program, the User Language Interpreter first of all must load the required User Language machine program with the specified program name from the ulcprog.vdb file of the BAE programs directory. The User Language Interpreter applies a compatibility check; a consistency check is not necessary since this time-consuming work has been carried out by the User Language Compiler already. A User Language program is compatible to and executable in the current interpreter environment, if the program's User Language Compiler version is equal to the User Language Interpreter version, and if the program only references index variable types and system functions which are implemented in the current interpreter environment.

Each User Language program can contain dynamic link requests, i.e. requests on binding User Language library machine code to program machine code at runtime. Dynamic linking is automatically applied during program load. Each dynamic link library (DLL) must be available, and the definitions (variables, functions, function parameters) provided with each DLL machine code must match its definitions at compile time (otherwise the Interpreter might try to access non-existent or wrong library objects, which would result in undefined behavior or even system crash with design data loss). The built-in linker of the User Language Interpreter checks on dynamic link library compatibility and refuses to run the program when encountering any inconveniences (error message Incompatible index/function reference(s)!). In case of incompatible DLLs, the User Language program must be recompiled.

Program Execution

After loading (and dynamically linking) the User Language machine program, the User Language Interpreter starts executing the program. Program execution can be understood to be the simulation of the User Language machine architecture by processing the instructions of the machine program. Program execution starts with the first machine program instruction and is completed when the program counter refers to a non-existent machine program instruction.

Program Termination

After executing the machine program a program termination must be applied to release the main memory allocated during program execution (Program Cleanup), and to remove the machine program from main memory (Program Unload).

3.3.2 Program Call

When calling a User Language program, the name of the program to be executed must be specified. This program name specification can be accomplished either explicitly or implicitly according to one of the subsequently described methods.

Menu Call

The Run User Script function from the File menu is used for explicit User Language program calls. The Run User Script function activates a dialog with a program name prompt and a List button for interactive User Language program selection:

File

Run User Script

Program Name ?

programname

Keyboard Call

One method of implicit User Language program call is provided by pressing special keys of the keyboard whilst working in the BAE function menu, i.e., this type of implicit User Language program call is possible at any time unless another interactive keyboard input currently is awaited by the system. The specification of the program name is accomplished implicitly by pressing a special key. Table 3-2 contains the list of key bindings provided with the User Language interpreter environments. Programs named bae_* have higher priority than those with module-specific names. When pressing one of the keys listed in table 3-2, the User Language program with the corresponding name is automatically started (if it is available).

Table 3-2: Key-driven Program Call

Event-driven Program Call

The User Language Interpreter environments are featuring event-driven User Language program calls, where User Language programs with predefined names are automatically started at certain events and/or operations such as after BAE module start, after loading and/or before saving a design element, when changing the zoom factor or when selecting a toolbar item. Table 3-3 lists the assignment of predefined User Language program names to corresponding interpreter environment events and/or operations. Programs named bae_* have higher priority than those with module-specific names. The BAE module start User Language program call method is most useful for automatic system parameter setup as well as for key programming and menu assignments (see also below). The element save and load program call methods can be used to save and restore element-specific parameters such as the zoom area, color setup, etc.

Table 3-3: Event-driven Program Call

Key Programming and Menu Assignments

Bartels User Language provides system functions for performing key programming and defining menu assignments. It is possible to define key bindings such as key m for activating the mirron User Language program or key U for activating the Undo BAE menu function. New or existing menus and/or menu entries can be (re-)configured to support special User Language program and/or BAE menu function calls. These features provide a powerful tool for configuring the menus of the AutoEngineer modules with integrated User Language Interpreter. It is a good idea to utilize the User Language startup programs for performing automatic key binding and menu setup. For an example on how to provide key bindings and menu assignments see the uifsetup User Language program distributed with the BAE software; this program is indirectly called from the startup programs listed in table 3-3. Even dynamic changes to the AutoEngineer user interface can be supported with special User Language programs for performing online key and menu programming. See the keyprog User Language program for implementations of online key programming facilities.

Menu Function Key Bindings

The keyprog key programming utility available through key 5 can be used in BAE pulldown menu interfaces for assigning BAE menu functions to keys by chosing Key Programming and Set HotKeys, double-clicking a key, clicking the Menu Selection button in the program menu and selecting the desired BAE menu function.

Macro Command Interpreter

A macro command interpreter is built into the Run User Script, function, the ulsystem User Language system function, the bae.ini key and menu function assignment facilities and the keyprog online key programming utility to allow for the specification of interaction/command sequences (macros) instead of User Language program names. Intercation codes must be separated with the : character. The p prefix is used to identify User Language program names (this prefix should be omitted if the User Language program name is the first item in the macro). The # prefix emulates a bae_callmenu User Language function call for activating a BAE menu function. Text input is specified through single-quoted strings. t awaits user text input. s activates a menu selection, which, if followed by l, m or r and a (zero-based) menu index triggers a menu function similar to a bae_storemenuiact function call. m awaits a mouse click, which, if followed by l, m or r, triggers a mouse click with input coordinates retrieved from the mouse position at the beginning of the interaction sequence if the mouse key in the macro isn't followed by coordinate specifications.

With macro specifications, it is possible to assign submenu functions such as Symbol/Label Query (macro scmpart:s5:m:t:mr) to keys. It is also possible to define macros for frequently required interaction sequences such as the Schematic Editor macro #500:m:mr:sl3:'4':'0':mr:sl0 for creating a 4mm horizontal graphic line from the current mouse position to the right (SCM symbol graphic pin connection).

Customized Parameter Settings and Menu Configurations

Customized parameter settings, key definitions and menu assignments can be stored to the bae.ini file in the BAE programs directory. The definitions from this file are loaded once upon BAE startup and can subsequently be accessed with the varget User Language system function.

The BAE User Language programs are designed to evaluate relevant definitions from bae.ini. Changes to bae.ini are activated by simply restarting the affected BAE program module, thus eliminating the need to recompile any of the affected User Language programs. I.e., with bae.ini, user-specific parameter settings can easily be transferred between different BAE versions and/or installations.

The bae.ini file provides specific sections for different BAE program modules. Each BAE program module only loads relevant sections from bae.ini. The definitions from the std section are relevant for all modules.

bae.ini allows for generic parameter value assignments. The key and fkey commands are used for standard and function key assignments. The addmenu, addmenuitem, addsmenuitem and addioitem kewords allow for menu extensions. Please note that menu items can only be appended to main menus and import/export menus. Menu item insertion is prohibited to preserve online help topic assignment.

A bae.ini file with inline documentation for command syntax explanation is supplied with the BAE software. The original version of this file activates the parameter settings from the supplied BAE User Language programs. I.e., these (default) settings are also activated if the bae.ini is not available in the BAE programs directory.

3.3.3 Error Handling

User Language Interpreter errors might occur whilst executing a User Language program call. These errors are reported to the interpreter environment, and a corresponding error message is displayed in the status line of the interpreter environment. The following listings contain all error message definitions of the User Language Interpreter.

Fatal Internal Errors

The following internal User Language Interpreter errors either refer to memory management problems or indicate User Language Interpreter implementation gaps; these errors are fatal, i.e., they force an abortion of the current interpreter environment:

ERROR : Out of memory!
ERROR : Unspecified User Language interpreter error!
ERROR : INTERNAL ERROR -- PLEASE REPORT!

Program Loader Errors

The following User Language Interpreter errors refer to program load failures or compatibility problems:

ERROR : Program 'n' already loaded (recursive call)!
ERROR : Program 'n' not found!
ERROR : Incompatible User Language program version!
ERROR : Incompatible index/function reference(s)!

Program Runtime Errors

The following User Language Interpreter errors refer to problems whilst executing a User Language program, i.e., they might occur at program runtime; these error messages include a program counter (PCl) indicating the corresponding machine program line which caused the errors (this information can be used for finding the location of the corresponding source code line if a listing file has been produced by the User Language Compiler):

(PCl) ERROR : Stack underflow (program structure damaged)!
(PCl) ERROR : Stack overflow!
(PCl) ERROR : Division by zero is attempted!
(PCl) ERROR : Function call error!
(PCl) ERROR : System function not available here!
(PCl) ERROR : System function not implemented!
(PCl) ERROR : User function not found!
(PCl) ERROR : Referenced function is of wrong type!
(PCl) ERROR : Invalid parameter for referenced function!
(PCl) ERROR : Memory protection fault on array access!
(PCl) ERROR : Array index out of range!
(PCl) ERROR : File access error!
(PCl) ERROR : File read error!
(PCl) ERROR : File write error!

Database Access Errors

The following User Language Interpreter errors refer to problems accessing the Bartels AutoEngineer design database (DDB); such errors might indicate an erroneous Bartels AutoEngineer software installation, if they occur whilst loading a User Language program; a database access error occurring whilst program runtime usually is caused by an implementation error in the executed User Language program:

ERROR : Cannot create database file 'n'!
ERROR : Read/write error whilst accessing file 'n'!
ERROR : Too many open files!
ERROR : File 'n' is not a database/DDB file!
ERROR : File structure is damaged in file 'n'!
ERROR : File structure is erroneous in file 'n'!
ERROR : Function not available for old format!
ERROR : Database limit exceeded!
ERROR : File 'n' is not compatible with program version!
ERROR : Element 'n' not found!
ERROR : Element 'n' exists already!
ERROR : File 'n' not found!
ERROR : Record end reached!
ERROR : Unspecified database error!

Programming System
© 1985-2025 Oliver Bartels F+E • Updated: 26 January 2007, 17:23 [UTC]