Semantical analysis

Static semantics generally

The static semantics analysis checks the consistency of the generated syntax tree (Common Representation), whereby the rules given by the language are attended. Concrete for SITE analysis operates on CR files and reports errors or warnings for SDL or also ASN.1. Following tools, e.g. the generation of code presuppose the consistency of a CR file.
The semantics analysis can be called both for complete specifications and individual Packages (in particular also ASN.1 modules). Referenced packages (use pack;) must be resolvable as CR files (search path), if they are not contained in the indicated CR file (e.g. usefull by partiual compilation).

Back to the start

Error messages and warnings

The analysis supports two basically different types of freely selectable error messages:

Item-related error messages: SDL/PR file name, line number, line position, error message
With these error messages one can position text editors by hand on the defective source in the SDL/PR representation or with good editors (vim, emacs) automaticly, too. Finding of the SDL/GR position is somewhat laboriously, in exceptional cases however automizable (special emacs mode in combination with SDT).
If a CR file did not develop from an SDL/PR file or if the position information of the CR is missing for other reasons, then the error output takes place automatically in the syntax mode.
Syntax oriented error messages: Description of the syntactic path to the error, error message
This version was implemented initially for the positioning of SDL editors into the analysis. Unfortunately, the text representation of this positioning is not always well readable, it helps however to find the error position within the SDL/GR representation. With this method the outdated syntax oriented editor and the SDL/PR Viewer yang could be positioned. It is quite possible to develop modules for commercial SDL products if the interfaces are accessible for positioning.

Errors and warnings can be divided into different classes:

Static errors
A violation of a static semantics rule is present, which should be recovered (e.g. a referenced sort is not defined).
Warning
The construction is semantically correct, but "bad" specified. Usually this is a hint for wrong specification. Often there are possibilities in SDL of preventing this warning with an explicit construction (e.g. signal parameter ignored - simply write the comma for the missing parameter).
Internal errors
The analysis contains very complex test strategies, in order to seek out "forgotten semantics rules". If it is discovered that the effects are global, the tests print an internal error. Normal sequence errors are not to be excluded then.
Internal warning
An incorrect implementation was discovered, this is however not not of global importance. Probably one can ignore this error problem-free.
Does not implement
It occurs that explicitly the implementation of a construction is missing. If it is without meaning, is only warned, otherwise an error message is printed.
Assertion failed
This message comes from the underlying tool technology as emergency brake for pointer errors of each type. They became very rare however.

The lower four error classes should be reportet with an example to the SITE authors.

Back to the start

Analysis internally

SDL semantics is explained with a very complex, gradual replacement scenario. SITE follows these recommendations, however the syntactic structure changes only in exceptional cases. Because of the gradual analysis, error messages are not linear sorted.

The command line parameters are analyzed and noted in internal structures.
The CR file is read in.
Referenced definitions are replaced by the definitions from the reference lists. It is also checked whether all packages, which are referecned in use clauses, are available. Missing packages are pulled tight and indicated as "externally" (importantly for the generation of code). If errors occur in this step, the analysis ends because of the reference errors which can be expected. One can be able to be output the CR after this step. With the PrettyPrinter one can produce oneself in this way a complete SDL/PR description without external Packages and with resolved referenced definitions.
A symbol table of all local definitions is built. Also the implicit package Predefined is read.
The symbol table is completed around imported definitions (package use and ASN.1 imports).
The symbols of base types are transferred recursively to the derivatives. Also current context parameters are considered. After this step all structures contain symbol tables with all visible identifier. Errors by the inheritance are displayed.
All references (identifier) are resolved. It also implies the analysis of expressions. Because of the frequent search in the symbol tables for suitable names, this step is very lengthy. There are various hash strategies, in order to improve the effectiveness of the search. Error messages concern false references, expressions and not unique resolution of references. If errors occur up to this step, then the analysis is aborted. Following steps often rely on a correct resolution of identifiers.
There is a reference check for names. Here multiple definitions of same structures however different syntactic construction (sorts, generator names) are reported. Additionally the use of definitions is noted, in order to detect not used structures. These notes are from object-oriented view problematic, so that only in exceptional cases corresponding warnings are printed.
Take place various consistency tests, which SDL otherwise still prescribe.
On the basis of static instances (system, block, process...) instance test are executed. Those are so far however only tests of import/export structures. Actually also the routing structure would have to be tested here. This code is however deactivated, because of to many errors.
There is optionally a step, which analyzes the communication interface of the SDL system for the environment. Here a file is written, which contains these information (signal.ext). So one can test the communication consistency of SDL systems based on same channel names. The consistency test are however specific for different SITE projects.

The individual steps are excellently modularized, so that the software in other SITE components can be reused. For example the code generator and the cross-reference service contain the modules up to the resolution of identifiers.

Back to the start

Further documentation

There is a UNIX manual, which explains the comand line parameters in detail. Also various studends papers contain partial aspects of the analysis. However, often the topicality is not given. One should assume one cannot successfully modify the sources of the analysis without tutorials to SITE. Also a reimplementation is not recommended, the analysis exists since about 1995 and will be never finnished until SDL-96 is replaced by SDL-2000. SDL is not a language it is a monster!

Back to the start

Sources and versions

The sources are embedded in a CVS structure. This contains however all project-specific adjustments, which are not freely available. Therefore in irregular periods public versions are extracted, during the writing of these pages we used version 4.3. One can inquire information whether there are relevant modifications in relation to the public version.
The substantial reason, a version restrainable are actually only critical CR modifications. At the moment we use CR version 3.4 internally
One should look up and find the sources on our FTP server. One can use also binary files for various architectures, if there are no problems with dynamic libraries.

Back to the start

Installation

The analysis must be found as executable program, i.e. possibly PATH has to be set accordingly. The analysis needs the package Predefined as CR file, i.e. call the SDL parser to if it is an SDL/PR file. For finding this file there are two possibilities:

One indicates the file with the option -P explicitly.
One sets an environment variable SITE_HOME on a directory (e.g. /usr/local/SITE), in which is under lib/ the file predefined.cr.

Both versions can also be hidden naturally in simple scripts. One should copy the manual to a place accessible for the command man (ending to consider). One can also read that!

Back to the start

Compilation

The Compilation is not quite simple, since various tools become necessary. One can download oneself if necessary the generated c files and only this compiling. That would be also the simplest method for Windows, not everyone will install a GNU development kit. Here a description which actually at the Comilation takes place:

With awk scripts from the CR description (*.kc) some default Include files are produced, which contain only simple constant definitions.
The CR files are filtered by the C preprocessor it to develop So the actual input files of the CR definition for Kimwitu (*.k) are built. The attributes of the Phyla can be found in *.kh files, by the way.
The file cr_virtual.k. is produced. This file contains "virtual" functionality for the CR manipulation, e.g. initialization and access to the parent concatenation of the CR, universal print functions... This file is generated (in a Gen.<architecture> directory), in order to guarantee the topicality to the CR. The actual CR themselves are used for the generation:

call kc for gen_cr_virtual_k.k osdl.k data_type.k cr_extension.k
compile all new C sources together (unpk.c, rk.c, csgio.c can be ommited) and
the compiled program has to be called with output redirection to cr_virtual.k.

Now all k files are complete, one can call Kimwitu with all sources (however not with gen_cr_virtual_k.k!). We filter thereby the k-sources by a special preprocessor,in order to activate project-specific code, with public versions it is simpler.
Everything which C sources are, will be compiled, whereby some options are meaningful (see Makefile).

Now to the problems:

The Makefile works only with GNU make. Otherwise one would not have a chance to write a working one; -).
One needs much resources. The files k.c and unpk.c are more than sumptuous. If the C compiler gets problems with its temporary files, read the documentation (e.g. for gcc set TMPDIR=.).
Missing one -D options are critically, e.g.-DKC_VIEW_COUNT_PATCH -DGLOBAL_ATTRIBUTE_PATCH are important!
The C compiler crys otherwise over the generated code. We are actually endeavored to improve our Kimwitu version in such a way that the newer compilers (in particular gcc) bear the generated C code.
A wrong Kimwitu version is used! It is not possible unfortunately any longer to use Kimwitu from Twente directly. We are dependent on some patches. Thus reload Kimwitu of us.
Because of the generation of the dependences of the C sources to the h files the make flow appears sometimes unmotivated. It also not always folds everything. If necessary delete .depend* (or call make dep) and again.
...

Back to the start

Known bugs

Messages from incorrect operator calls are a piece of art in the analysis. Unfortunately art is very subjective.
Static routing conditions are not stable or are deactivated.
Warnings for unused structures are sometimes (in the context of inheritance) wrong.
Not unique reference resolution is often conciderred as error. That is however correct with unique covers.

Back to the start

created 29-Aug-94 by SITE maintenance crew
last change at Fre Jun 27 11:26:45 CEST 2003