[Previous] [Next] [Contents] [Index]


    The SDL to CHIPSY CHILL Translator

The SDL to CHIPSY CHILL Translator, sdl2chill, translates your SDL system into a semantically equivalent CHILL program that you can compile, link, test and real-time execute by means of CHIPSY. CHIPSY is the CHILL Integrated Programming System, from Kvatro Telecom AS.

This chapter deals with the SDL to CHILL translation facilities. Description of CHIPSY and SDT tools to be used together with the translator, is given in the manual for CHIPSY and the Telelogic Tau User's Manual respectively.

Table of Contents 

Introduction

The translation from SDL to CHILL is based on a mapping scheme in which the basic concepts of SDL such as system structure, communication, behavior, actions and data are directly mapped into matching CHILL constructs of program structuring, concurrent processing, communication, actions and data. By this scheme SDL signals are mapped to CHILL signals and concurrency is implemented by utilizing the language inherent concurrency of CHILL as provided by CHIPSY.

The CHILL code generated from an SDL system, may be viewed as a CHILL module interfaced to via signals. This makes it easy to plug in an SDL system as an application program part anywhere in your CHILL software structure. Consistent interfacing of the SDL system will be ensured by the separate compilation scheme of CHIPSY.

The application area for sdl2chill is development and maintenance of real-time application systems. By using sdl2chill, the CHILL program generated for your system will be efficient, reliable, easily readable and open for interfacing and interoperability with other software.

Application Areas for sdl2chill

The application area for sdl2chill is development and maintenance of software for real-time application systems. sdl2chill has been implemented to maximize the user benefits of the ITU languages SDL and CHILL by combining the capabilities of SDT and CHIPSY.

The CHILL program generated from your SDL specified system by using sdl2chill, will be efficient, reliable, easily readable and open for interfacing and interoperability with other software.

In this part of the manual, the usage of sdl2chill for generating application systems is described. When it comes to detailed information on the functionality and usage of the CHIPSY tools and the SDT tools to be used together with sdl2chill, this is described in the CHIPSY Reference Manual and the Telelogic Tau User's Manual,respectively.

Generating Application Systems

During development and the succeeding maintenance of your system, the combined functional power of SDT, sdl2chill and CHIPSY is fully available and you may conveniently design, generate, simulate, test and real-time test your application on a host computer before possibly recompiling, linking and downloading to dedicated target hardware.

Concurrent real-time execution, communication and timing as implemented by sdl2chill, are directly based on services provided by CRS, the CHIPSY Real-time Operating System. Other features of CRSsuch as interrupt handling, Input/Output, distributed processing and program execution control, provide additional services you need in order to implement the operational environment to which the SDL system must be interfaced in order to realize its intended purpose.

Testing and debugging are facilitated by means of conventional debuggers or by using the CHIPSY's Pilot. The Pilot is an advanced real-time test and debugging tool that is part of CHIPSY.

CHIPSY is now available on a variety of host and target platforms including Sun SPARC (SunOS 4.1.3, Solaris 2.5), 386/486 PC with SCO UNIX ODT 3.0.

Generating Distributed Application Systems

The CHILL code generated by sdl2chill is prepared for distributed execution by means of CDPS, the CHIPSY Distributed Processing Services of CRS. CDPS allow your programs to communicate by means of CHILL (and thus also SDL) signals in a distributed environment where programs may reside on different nodes in an heterogeneous network.

Overview of sdl2chill

To facilitate generation of CHILL source code from SDL specifications or descriptions, the SDT Analyzer contains an SDL parser, an SDL semantic checker, and the sdl2chill translator.

Creating a CHILL program

To obtain an executable program that behaves according to an SDL description, you input the SDL description into the SDT Analyzer, which contains the sdl2chill translator, using the Make dialog in the Organizer (see Make). If the SDL description is syntactically and semantically correct a CHILL program and a Makefile1 is generated. This will compile the program using the CHIPSY CHILL compiler and link it with the precompiled CRS library including the SDL Services to form an executable program. See Figure 488.

As indicated above, sdl2chill contains two components:

Figure 488  : The production of a CHILL executable program

Extracted pic [1]

Building and Running a CHILL Program

After running make, a CHILL program generated by sdl2chill, can (just like any other executable program) be started from an operating system shell by typing the name of the file containing the executable program.

Contents of this Chapter

You can find more details on creating and executing a CHILL program in the following sections:

Generating a CHILL Program

Creating the CHILL Program

To create the CHILL source(s), use the SDT Analyzer and its built-in sdl2chill translator for creating a program expressed in CHILL source code. This operation is started from the Make dialog in the Organizer (see Make). The program may be partitioned to one or more CHILL compilation units.

Building and Running a CHILL Program from SDT

There are two steps that you must take to create an executable CHILL program and run it from SDT. Both must be performed from the UNIX shell:

  1. Compile and link the generated CHILL compilation unit(s) using GNU Make. CRS is automatically included.
  2. Start the executable program that is created in the above link operation, see next section.

A CHILL program can only be generated for a complete SDL system. The CHILL source code that constitutes the program can, however, be partitioned to several compilation units (files). This means that a local change in an SDL unit, for example a process diagram, requires regeneration and recompilation of CHILL code for that unit only. For the other unchanged units the existing object files can then be reused in the link operation to form a new executable program.

Note: 

The Makefile includes all CHILL files in the current directory: the call format used by sdl2chill under UNIX is:

    cmkmf *.ch <#WITH directive files>

Customizing the Building Step

By default, the CHIPSY tool cmkmf will be invoked. This may be overridden using the environment variable CMKMF under UNIX. You may let this define a tool of your choice. The call used by sdl2chill is then:

File Names

The files that are created during the generation phase will have the file names specified in Edit Separation dialog in the Generate menu in the Organizer. By default this is the name of the SDL unit2.


File Extensions UNIX
.ch

Compilation unit in CHILL source text form

.cdbf

Compilation unit in CHIPSY Data Base Format, a.k.a. CDB entry

.o

Object file


Executable program


Makefile

The .ch, .cdbf and .o files are created for the system, and are also created for blocks and processes, depending on the separate generation scheme decided by the user. The file names will be the name of the units (system, block, or process) with the appropriate extension. For more information on generated files and file names see the section Selecting File Structure for Generated Code -- Directive #SEPARATE.

Running a CHILL Program

A CHILL program generated by sdl2chill can be started from an operating system shell by typing the name of the image file containing the executable program3.

Errors During Code Generation

Errors that may occur during code generation are internal errors, that is, errors due to not yet implemented features of SDL, and errors related to problems with open or close operations of files.

All the error messages are listed below, together with a short explanation. Some messages contain a"#" followed by a number which is used to indicate where information, specific of the error situation, can be found.

The translator cannot yet handle this SDL feature. See the list of restrictions and implementation dependencies in the section Implementation Dependencies.

.ch file cannot be opened.

The scope structure is too deep.

#1 is replaced by the name of an SDL unit. During code generation sdl2chill prefixes SDL name strings to make them unique. The prefixing algorithm and the limit for the length of the prefix, might make it impossible to generate a prefix, in which case this warning is issued. It is still possible to execute the generated program if the name, without prefix, is unique.

These four last errors are internal errors in sdl2chill. We would be pleased if you will report such errors to us.

Implementation

Overview

sdl2chill implements your SDL system by mapping it to a semantically equivalent CHILL program. This means that when executing the generated program, it behaves according to the SDL system specification.

The translation from SDL to CHILL is based on a direct mapping scheme. The basic concepts of SDL such as system structure, communication, behavior, actions and data are directly mapped to matching CHILL constructs of program structuring, concurrent processing, communication, actions and data.

In the first parts of this section we describe the SDL to CHILL mapping as implemented by sdl2chill. The implementation is explained in terms of CHILL and CHIPSY and a good knowledge of both is required in order to understand the mapping details. As rationale and discussion of mapping alternatives are not needed in order to use sdl2chill, this is described in a separate technical document. CHILL source code is easy to read, and as a supplement to reading this section you are recommended to study the generated code for your own system(s).

The last part of this section describes how sdl2chill implements operators and literals in abstract data types. In the general case it is not considered feasible to derive the implementation of operators (and literals) from the axioms. sdl2chill therefore provides support for implementing the operators by user-written CHILL procedures. sdl2chill also offers a simple escape mechanism for types by means of which is it possible for the sdl2chill user to utilize CHILL modes and properties of modes otherwise not accessible from SDL.

Numerous examples are used in this section to illustrate the run-time model and the SDL to CHILL mapping implemented by sdl2chill. In the examples, the prefixes, which can be added to names when they are translated to CHILL, are normally not shown. The prefixes are used to make sure that no name conflicts occur in the generated program. For more information about prefixes see Names and Prefixes in Generated Code.

System Structure

System

sdl2chill maps an SDL system definition to an outermost CHILL module.

The CHILL code generated for a system may be partitioned to several compilation units. How this is facilitated is described in Selecting File Structure for Generated Code -- Directive #SEPARATE.

For the CHILL code to be CHIPSY compilable, sdl2chill also generates a context directive including the SDL Services of CRS.


Example 241       

maps to:


Package

In sdl2chill a package will become a MODULE and the USE statements will become proper SEIZE statements.

The #CHILL-directive in packages is used to indicate that this package is an interface package between the environment (in CHILL) and the SDL system. The usage of this package is to access CHILL entities defined elsewhere from within the SDL system. During SDL analysis the SDL entities defined in the package are, of course, available. sdl2chill however does not translate them into CHILL, as they are available in the environment. Note that you should probably have #NAME directives on all entities, to get the proper names in the generated code. yEqual_typename and yMake_typename functions are generated for structs and arrays, as these functions are assumed not to be available in the environment. In this way signal definitions, type definitions, external procedures, and synonyms from the CHILL environment can be accessed. An ordinary global procedure can also be defined in a #CHILL package. This SDL implementation will not be used for the CHILL translation, but can be used to simulate the behavior of the procedure in the SDT Simulator.

An #ENVIRONMENT and #WITH directive can be placed in a package, just as in a system, and will have the same meaning and use.


Example 242       

Block and Block Substructure

sdl2chill maps the specifications contained in a block or in a block substructure to CHILL code without imposing any CHILL structure. The name string translation as described in Names and Prefixes in Generated Code, ensures proper name binding at the CHILL level.


Example 243       

maps to:


Process

sdl2chill maps an SDL process definition to a CHILL process definition. The SDL process name and the formal parameters map to the CHILL process name and the formal parameter list respectively.

Creating the initial number of SDL process instances, if any, maps to a sequence of CHILL start actions executed by the CHILL imaginary outer process. The default value for initial number of processes is 1.

SELF maps to THIS. PARENT maps to an additional (implicit) formal parameter of PId sort for each process definition. OFFSPRING and SENDER map to process local CHILL locations to which values are assigned by in-line CHILL assignment actions.

Note: 

sdl2chill does not support formal parameters for initially created processes and it is not checked that the number of simultaneous instances of an SDL process is within the allowed maximum number, if specified.


Example 244       

maps to:


Procedure

sdl2chill maps an SDL procedure definition to a CHILL procedure definition. This applies both to procedure definitions with state(s) and to procedure definitions without state(s). The SDL procedure name and the formal parameters map to the CHILL procedure name and the formal parameter list respectively.

Parameter passing for SDL in-parameters map on CHILL "pass by value" IN parameters, while SDL in/out-parameters are implemented by means of bound reference mode formal parameters and in-line CHILL
code for referencing (at point of call) and de-referencing (for each applied occurrence of the formal parameter).

Note: 

sdl2chill does not support calling an SDL procedure with an empty actual parameter.


Example 245       

maps to:


Global, External and Value Returning Procedures

Procedures may be placed at any scope level in SDL-92. sdl2chill allows global procedures without state. Process local procedures may, of course, have state.

External procedures is a new feature in SDL-96, which is supported by sdl2chill. The identifier (no prefixing is performed) is automatically SEIZED, but it is the user's responsibility to make sure the identifier is visible, e.g. via an #ENVIRONMENT directive, see Example 246 and Example 247.

Value returning procedures (SDL-92) are mapped in the obvious way as can be seen from the example.


Example 246        


Example 247        

Communication

sdl2chill implements all process communication by means of CHILL signals. The channel definitions, signal route definitions and channel to signal route connection definitions of SDL all map to empty.

Signal

An SDL signal definition maps to a CHILL signal definition statement. The SDL signal name and the sort list map to the CHILL signal name and associated list of modes.


Example 248       

maps to:


This mapping enables the CHILL inherent process communication and concurrency to be fully exploited by sdl2chill. The interface between the SDL system and its environment is mapped to a set of CHILL signals and connecting the generated program to other CHILL code thus becomes very easy.

Behavior

Variables

An SDL variable definition maps to a CHILL location declaration local to the CHILL process. The SDL variable names and the sorts map to location names and modes respectively. Assignment (explicit or implicit) associated with the variable declaration map to reach-bound initialization.


Example 249       

maps to:


Start

The mapping of the transition associated with start (of the SDL process body) is shown by Example 250 below.

State

The states of an SDL process definition map into CHILL as follows:

  1. The set of SDL states maps into a CHILL set mode definition (enumerated type) of which each set literal represents one state. The state names map to the set literal names and the set mode is named "states". The implicit state, "start_state", is added by sdl2chill.
  2. A CHILL location named "state'' of mode states is declared. This location is used to keep track of the current state and it is initialized to start_state.
  3. The SDL process body, including the start transition maps to a loop containing a case statement with one alternative for each state.
  4. Consumption of signal instances or waiting in a state maps to CHILL receive case action. Each signal for which input is specified in a state, maps to one signal receive alternative.

Example 250        

maps to:


Input

Each signal for which input is specified in a state, maps to a signal receive alternative of the CHILL receive case action mapped from this state. See also Implicit Transition.

The values transported by CHILL signals are received in locations defined by the CHILL signal receive alternative. Copying the received values from the implicit signal reception locations required by CHILL to the variables associated with the input maps on assignment.

The location to which the SDL expression SENDER is mapped, is directly updated by the receive case action.


Example 251       

maps to:


Save

Save maps on empty. The CHILL signals are persistent i.e. they are not consumed until explicitly received by a signal receive alternative. See also Implicit Transition.

Label

An SDL label maps to definition of a CHILL label. The connector name maps to the CHILL label name.

Transition

A transition maps to the CHILL action statement list of the signal receive alternative that is mapped from the input to which the transition is associated. See also Join.

Transition Terminator

Nextstate

Nextstate maps on assigning the set literal representing the specified nextstate to the CHILL location named state. The actual transfer of control is implemented by the enclosing case statement and loop statement. This is shown by Example 250.

Join

Join maps to CHILL goto action. Connector name maps to label name. Join from a transition to any legal connector is supported.4

Stop

sdl2chill maps SDL stop to CHILL stop.

Return

sdl2chill maps SDL return to CHILL return action.

Implicit Transition

The SDL semantics is that any signal (including timer signals) that is not explicitly saved or input in a state, shall be implicitly consumed when they are first in the input queue. The associated implicit transition is a nextstate action leading back to this state.

In the simplest case, sdl2chill maps the implicit transitions of a state to one empty signal receive alternative receiving the anonymous CHILL signal, else5. If "save", however, is specified for any signal in a state the CHILL "else signal" cannot be used and explicit empty signal receive alternatives for the signals to be consumed must be generated instead. As shown in the following example, this is fully catered for by sdl2chill.


Example 252       

maps to:


Action

Task

sdl2chill maps the assignment statements of a task body to CHILL assignment actions.

Create

sdl2chill maps the create requests to CHILL start expressions.6 The result yielded by the start expression is assigned to the offspring location of the creating process.

Note: 

sdl2chill requires that the actual parameters fully match all formal parameters, i.e. undefined parameters are not supported.

Dynamic check to verify that the number of process instances created is within the allowed maximum number, if specified, is not supported by sdl2chill. (If, however, all available memory has been used and no more processes can be created then this will of course be detected and reported by CRS.)

If the process definitions of the creating process and the process to be created are mapped to different (separate) CHILL compilation units then an auxiliary proc location is introduced by sdl2chill (if necessary). This is done in order to avoid cycles in the compilation graph. The details are shown in the example below.


Example 253       

maps to:



Example 254       

maps to:


Procedure Call

SDL procedure call maps to CHILL procedure call.

In the generated CHILL procedure call the actual parameters that matches SDL in/out-parameters are preceded by the referencing operator ->.

Value returning calls are mapped directly:


Example 255       

maps to:


Output

sdl2chill maps output and the associated signal parameters to a CHILL send action.

Note: 

Output without "to" or output with undefined actual parameters are not supported by sdl2chill.

To denote the PId value of initially created processes, the translation directive #PIDLIT has been defined. By means of this directive, any specification relying on output without to may easily be adjusted to output with to, see Identifying Initially Created Process Instances  -- Directive #PIDLIT.

If, in spite of this, you decide to use output without to, you will find that it maps to CHILL open send signal. As shown in the example below no error message is given, but thecomment /* TO ? */ is generated in the code to inform you that the CHILL open signal send, in the general case, may not properly implement the semantics of SDL output without to.

In this case the generated program therefore may, or may not execute correctly.


Example 256       

maps to:


Decision

sdl2chill maps decision to CHILL if action as shown in the example below.


Example 257       

maps to:


Timer

SDL timers and the associated actions on timers are implemented by means of CHILL run-time library procedures utilizing the signal timing and stopwatch as provided by CRS Timing Services. More information on the run-time library can be found in The SDL Services.

The mapping details are shown by Example 258 below.

Note: 

sdl2chill restricts the timer definitions and the set and reset statements to timers for which no (sort) parameters are specified. sdl2chill measures the SDL system time by means of the CRS stopwatch, the unit of which is execution platform and system clock dependent1.

The precision used when computing if the system time associated with a timer has been reached, is a configurable, execution platform dependent parameter of CRS.2

See also the CHIPSY Reference Manual for more information on implementation details and the CRS tuning options.


1. On UNIX the unit is one millisecond. Depending on the system clock resolution, stopwatch read-out may be updated as infrequently as every one second.
2. Its default value is 1/10 second on UNIX/BSD, while it is 1 second on UNIX/System V.


Example 258        

maps to:


Continuous Signals

sdl2chill supports a special subset which can be mapped directly to CHILL: A "provided true;" can be present.


Example 259       

maps to:


Note: 

Different priorities on the boolean expressions may be used by rewriting the SDL: Use a decision inside the "provided true" action.

Synonyms

Synonyms

An SDL synonym is implemented either by a CHILL location which is initialized at program start up, or as a CHILL synonym. The implementation using a location is chosen in case the expression defining the value of the synonym:

All other synonyms are translated into CHILL synonyms.

A synonym that maps to a location cannot be used in a range condition of a syntype because SDL range conditions are mapped to CHILL range modes and boundary values of CHILL range modes cannot be locations.

E xternal Synonyms

External synonyms can be used to parameterize an SDL system and thereby also a generated program. sdl2chill maps the definition of external synonyms on empty, this enables you to give values to external synonyms simply by using your own CHILL written definitions of these synonyms.

To give value to an external SDL synonym by means of CHILL written definitions, perform the following steps:

  1. Write the actual CHILL data statements in a compilation unit as shown in Example 260 and CHILL compile it. The synonym names are the SDL names (without any prefixes) and with any character not in letters, digits, or underline removed.
  2. Add the file name of the CDB_entry derived in the above step in an #ENVIRONMENT directive as shown in Example 261. The CHILL written definitions are then imported in the resulting CHILL program by the sdl2chill generated SEIZE ALL;

Example 260        


Example 261        

If you use this structure you can change the value of an external synonym merely by changing the corresponding CHILL data statements and recompiling the system.

Abstract Data Types

In this section we first look at how sdl2chill translates the SDL predefined data types, see "SDL Predefined Types" below.

We then discuss how user-defined abstract data types are translated, see Translation of Sorts.

Next the possibility to include CHILL written procedures as implementation of the operators in abstract data types is presented, see User Defined Operators.

Last, in More about Abstract Data Types, we discuss more details about operators and the possibilities to include a CHILL written mode definition to represent an SDL sort.

SDL Predefined Types

Mapping Table

Below is a table summarizing the SDL to CHILL mapping rules for the SDL predefined types and their operators (see SDL name/operator).

SDL name/operator       CHILL name/expression/operator
Boolean
BOOL
False, True
FALSE, TRUE
not
NOT
=, /=
=, /=
and
AND
or
OR 
xor
XOR
=>
<=
Character
CHAR
NUL
SOH

...

SDL_NUL 
SDL_SOH 

... (for all unprintable characters)

'a'
'b'

...

'a' 
'b'

... (for all printable characters except ')

''''
'''' 
=, /=
=, /=
<, <=, >, >=
<, <=, >, >=
Chr, Num
SDL_Chr(), SDL_Num()
Charstring
SDL_Charstring
'aa'
[2,'aa'//(SDL_Charstring_max_length-2)' ']
=
=
/=
/=
MkString
SDL_Charstring_MkString
Length
SDL_Charstring_Length
First
SDL_Charstring_First
Last
SDL_Charstring_Last
//
SDL_Charstring_Concat
SubString
SDL_Charstring_SubString
Extract!
SDL_Charstring_Extract
Modify!
SDL_Charstring_Modify
Integer
INT

0, 1, 2, ...

same as in SDL

+, -
+, -
*
*
REM, MOD
REM, MOD1
/
/
=, /=
=, /=
<, <=, >, >=
<, <=, >, >=
Float
SDL_Float
Fix
SDL_Fix
Natural
SDL_Natural
Real
SDL_Real

0.0, ...

SDL_Real_Lit(0, 0)

- (monodic)

SDL_Real_Neg
+
SDL_Real_Add

- (dyadic)

SDL_Real_Sub
*
SDL_Real_Mul
/
SDL_Real_Div
=, /=
=, /=
<
SDL_Real_Lss
<=
SDL_Real_Leq
>
SDL_Real_Gtr
>=
SDL_Real_Gte
PId
INSTANCE
NULL
NULL
=, /=
=, /= 
Duration
SDL_Duration
23.45
SDL_Duration_Lit(23, 450000000)
+
SDL_Duration_Add

- (monodic)

SDL_Duration_Neg

- (dyadic)

SDL_Duration_Sub
*
SDL_Duration_Mul
/
SDL_Duration_Div
=, /=
=, /=
>
SDL_Duration_Gtr
Time
SDL_Time
23.45
SDL_Time_Lit(23, 450000000)
+
SDL_Time_Add

- (result: Time)

SDL_Time_Sub

- (result: Duration)

SDL_Time_Diff
=, /=
=, /=
<
SDL_Time_Lss
<=
SDL_Time_Leq
>
SDL_Time_Gtr
>=
SDL_Time_Gte


1. Note that CHILL MOD is not defined for negative right sides.

The SDL Services

A small run-time8 library supporting the execution of programs generated by sdl2chill, has been implemented. This library is called SDL Services. It is delivered as part of CRS and consists of CHILL modes, synonyms and procedures used by sdl2chill. Interfacing to the library is of course, fully catered for by sdl2chill also when it comes to generating context directive, importing the applied names and including the library in the generated Makefile.

We will here briefly describe the modes, synonyms and procedures of the SDL Services used by sdl2chill to implement the SDL predefined types and the associated operators.

The listing below is extracted from source code of the library.

TIMER
SDL CHARACTER SORT
SDL CHARSTRING SORT
SDL NATURAL SYNTYPE
SDL REAL
SDL DURATION SORT
SDL TIME SORT

Note: 

Due to the implementation of SDL Integer using 16-bit integers in CHILL, there is a restriction in range for integer values. Integers must be in the range -215..215-1.1 There are in the same way restrictions both in range and precision for Real, Time, and Duration, as they are implemented using the CRS defined mode LONGDURATION. In the interface to SDL Services the literals of Real, Time, and Duration are represented by two 32-bit integers. The first integer of Time, and Duration represents the number of seconds and the second integer represents the number of nanoseconds. The length of charstrings cannot exceed the implementation defined limit of 100. 2


1. In CHIPSY CHILL 32-bit integer (LONGINT) is also available, on how to use LONGINT from SDL, see More about Abstract Data Types.
2. The above described implementation dependencies apply to Version 1.0 of theSDL Services. If needed, the range and precision for the predefined types may be extended by adapting the CRS Services.

Translation of Sorts

The following data types can be handled by sdl2chill:

Predefined Types

All the predefined data types, Integer, Natural, Boolean, Character, Charstring, Real, Time, Duration, and PId are completely handled.

The name of these types in the generated CHILL code will be INT, SDL_Natural, BOOL, CHAR, SDL_Charstring, SDL_Real, SDL_Time, SDL_Duration and INSTANCE respectively.

The translation rules for these types and their operators are described in more detail in the SDL Predefined Types.

Enumeration Type

A sort which is not a struct and which does not contain any inheritance or generator instantiation, but which contains a literal list, is translated to a CHILL set mode, as can be seen in the example below. As in all examples in this subsection, the prefixes, which are added to name strings when they are translated to CHILL, are not shown. The prefixes are used to make sure that no name conflicts occur in the generated program. For more information about prefixes see Names and Prefixes in Generated Code.


Example 262                         

is translated to:


Unfortunately this translation strategy is not always correct. Consider as an example the following sort definition:


Example 263        

When evaluating this definition it is fairly easy to see that the value set of this sort contains three values, the value denoted by Lit1, the value denoted by Lit2, and the value obtained by applying Op to Lit2, that is, Op(Lit2). The latter value does not have any explicit literal denoting its value, which means that an implementation of this sort as an enumeration type in CHILL would be incorrect. In general, the set of literals of a sort and the set of values of a sort are two quite different things. Still the translation rule is included in sdl2chill, since it is valid in most situations.

Struct

An SDL struct is translated to a CHILL struct, as can be seen in the example below.


Example 264                                     

is translated to:


All the properties of a struct in SDL are preserved in the CHILL code. The predefined operators Extract! and Modify! are implemented as component selection in the struct in the same way as in SDL, that is, if S is a variable of type Str, then S!a in SDL is translated to S.a in CHILL. The predefined operator Make!, which is a constructor of a struct value, is implemented by means of tuples in CHILL. This means that the expression (. 12, true, `a' .) in SDL is translated to the CHILL constant tuple: [ 12, TRUE, `a' ].

The components of a struct may be of any sort that sdl2chill can handle. A component may, however, not directly or indirectly refer to the struct sort itself.


Example 265       

The sort Str above may not have a component of sort Str. In such a case the translation to a CHILL struct would no longer be valid.


Array

Instantiations of the predefined generator array can be handled by sdl2chill with the following restrictions: The component sort may be any sort that sdl2chill can handle, but may not directly or indirectly refer to the array type itself (see also the previous paragraph on struct). The index sort should be a discrete sort, with one closed interval of values. This means that the following index sorts may be used:

Another way of defining the allowed index sorts is that sdl2chill can handle array generator instantiations with any index sort that maps to a CHILL discrete mode.


Example 266       

is translated to:


All the properties of an array in SDL are preserved in the CHILL code. The predefined operators Extract! and Modify! are implemented as indexing of the array in CHILL in the same way as in component selection is done in SDL, so if My_Var is a variable of type Arr, and My_Index is a valid index expression, then My_Var(My_Index) in SDL maps to My_Var(My_Index) in CHILL.

The predefined operator Make!, which is a constructor of an array value, is implemented by means of CHILL tuples. This means that the expression "(. 0.22 .)" in SDL is translated to the CHILL tuple: [ (*): SDL_Real_Lit(0, 220000000) ].

Syntypes

Syntypes may be defined for any sort that sdl2chill can handle, giving a new name for the sort and possibly a new default value for variables of the sort. Range conditions that restrict the allowed range of values are also allowed by sdl2chill provided that the parent sort maps to a CHILL discrete mode and the range condition details map to a CHILL literal range.

The syntype is translated to a type equal to the parent type using SYNMODE definition. The check that a variable of a syntype with range condition is only assigned legal values, is catered for by CHILL semantic conditions. An attempt to assign an illegal value to such a variable will be reported as a CHILL RANGEFAIL exception at run-time. Similarly, if syntype is specified as index sort in an array, the CHILL semantic conditions will ensure that the index values used in array component selections are within the range conditions specified for the index sort.


Example 267        

is translated to:


Default Values

In sdl2chill you may initialize a variable by assigning a value to it in the variable definition or by specifying a default value in the sort definition. If neither is done, the initial value for the variable is undefined. The exception to this is that sdl2chill assigns the value NULL to those variables of PId sort that would otherwise contain an undefined initial value.

Note: 

The SDL system is in error if a variable containing an undefined value is accessed. This should have been reported when executing the generated program, but it will not be detected because undefined values are (for performance reasons) generally not catered for in CHILL.

As a general rule you should define appropriate default values in sort definitions and use initial value assignment in variable definitions whenever this is needed.

Operators

The default mapping of user defined operators in an SDL sort is as follows:

In User Defined Operators it is described how to include CHILL procedures as implementation of operators.

Literals

In sorts that are translated to CHILL set modes, literals are obviously handled by sdl2chill. In sorts that are not translated to CHILL set modes, literals are treated as operators without parameters and are handled exactly in the same way as user defined operators.

Note: 

Note that sdl2chill does not permit naming of literals using name class literals or character strings.

Axioms and Literal Mappings

Axioms and literal mappings are allowed by sdl2chill in sorts, but are completely ignored.

User Defined Operators

Including Implementation of Operators

In the previous subsection the default behavior of sdl2chill concerning operators and literals was described. To make it possible for sdl2chill to generate complete application programs, you should include CHILL procedures implementing the operators and literals. This can be done by means of sdl2chill directives.

An sdl2chill directive is an SDL comment with the first character equal to `#', followed by a sequence of letters identifying the directive. In this case the letters are ADT (for Abstract Data Type) and OP (for operator). An ADT directive and an OP directive should thus look like:

The text is not case sensitive.

OP directives are recognized at two different positions in an abstract data type:

ADT directives are recognized immediately before the reserved word ENDNEWTYPE (or ENDSYNTYPE).


Example 268        

The #OP directive can be used to specify how the applied occurrences of the associated literal or operator should be implemented. In the #ADT directive the actual implementation can be defined e.g. in the form of CHILL procedure definitions.

An OP or ADT directive specifying the implementation details of operators and literals should have the following structure:

The letter between the parentheses should be B (body)9. If B has been specified for an operator or literal, then CHILL code for implementing its intended function must be supplied by the user. This CHILL code should be placed in the ADT directive, according to the following example:


Example 269        

The CHILL code must start on a new line.

Note: 

sdl2chill does not check the consistency between the specification of implementation techniques and the actual CHILL code. This check is, together with checking the CHILL code for syntactic and static semantic errors, left to the CHILL compiler.

CHILL comments within the code that is included in a #ADT directive should be in the form of end-of-line comments. SDL and CHILL use the same symbols for bracketed comments and if such a comment is included, the SDT Analyzer will consider its closing bracket as the end of the SDL comment.

In Example 268 the struct Str is defined and there are two literals (Lit1 and Lit2) and two operators (Op1: Str, integer --> Str; and Op2: Str, Boolean --> Str;). The procedures, which should be supplied by the sdl2chill user if B is specified in the OP or ADT directive, are ordinary CHILL procedures.


Example 270       

Before it is possible to give a complete example of an abstract data type with implementation of its operators supplied as CHILL procedures it is necessary to look at the problem of names and name strings. When a name string of an entity in SDL is translated to CHILL, a suitable sequence of characters, a prefix, is added to the SDL name string, to make the name unique in the CHILL program, see also Names and Prefixes in Generated Code. This strategy is selected in sdl2chill to avoid name conflicts in the generated code, but it makes it also impossible to predict the actual name string of, for example a mode or a procedure, in the generated program. To handle this problem the user can tell sdl2chill to translate a name string in the user written CHILL code in the same way as SDL name strings are otherwise translated. This is specified by enclosing the SDL name string between "#(" and ")" in the CHILL code. The two procedures in the previous example then become:


Example 271       

The facilities enabling the use of SDL defined names in CHILL code is described in more detail in the section Applying SDL Names in CHILL Code -- Directive #SDL. A few observations concerning the example above might be appropriate:

  1. The standard sorts in SDL: integer, natural, Boolean, real, character, charstring, time, duration, and pid, have the names INT, SDL_Natural, BOOL, SDL_Real, CHAR, SDL_Charstring, SDL_Time, SDL_Duration and INSTANCE in the generated code. These mode names should not be enclosed between "#(" and ")".
  2. The component names of a struct are unchanged in the struct implementation in CHILL, which means that field names should not be enclosed between "#(" and ")" either.

Two Examples of ADTs

We now give two complete examples of abstract data types.


Example 272        


Example 273       

Note that no procedure definition is supplied for the operator Sum. When compiling a generated program where the operator Sum is used, the CHILL compiler will therefore give an error message saying that definition of the name Sum is missing.

For more information about CHILL synonyms, modes and procedures (supplied by the SDL Services and used in generated code) that can be useful when implementing operators in CHILL, see SDL Predefined Types, and last in More about Abstract Data Types (below).

More about Abstract Data Types

More about Operators

Previously under User Defined Operators, the possibility to include implementations of operators in abstract data types was described. Here we will first discuss some additional features concerning operators and then describe how to replace the generated CHILL mode definition for an abstract data type with a user defined mode definition.

For an operator in an abstract data type not only B (body) may be specified. The following choices are available:

Note: 

As CHILL does not include the possibility to have user defined operators, I (infix) is only adequate together with S (standard).

For each operator one of the letters B, S and one of the letters P, I should be supplied, either in a #OP directive, or in a #ADT directive, or as the defaults B and P. For literals P and I have no meaning.


Example 274       

Example of usage of S (standard)

An SDL expression using these operators:

SIZE(a) will be translated to: SIZE(zh723_a)


These examples show how built-in procedures and standard operators of CHILL can be directly utilized in abstract data types.

Including CHILL Mode Definitions

In Translation of Sorts it is described which CHILL mode definitions the SDL predefined types, enumeration types, struct, array and syntypes map into. By this translation scheme the general, implementation independent capabilities of the CHILL modes that matches the above SDL types are directly utilized.

When generating applications it is sometimes needed, in parts of a system, to use additional CHILL modes such as pointers, other integer modes than INT and the more implementation oriented capabilities of CHILL such as variant structure modes and packing. This is facilitated by means of the #ADT directive.

By this directive it is possible to suppress the generation of mode definitions for an abstract data type and include a CHILL written mode definition instead. Suppressing the generation of the mode definition, however, does not affect the translation of the actions related to the data type.

The #ADT directive to specify that no mode definition shall
be generated from the SDL sort has the following structure10:

The example below shows how the #ADT directive may be used in order to use the CHIPSY defined integer mode LONGINT from SDL.


Example 275       

Maps into the following CHILL code:


Below is another example showing how the #ADT directive may be used to facilitate packing of the components of a structure and to build a linked list of data objects by means of a CHILL defined pointer.


Example 276       

Replacing Standard Operations

This is not the whole story, however. The ADT directive allows finger tip control of how the type itself, assignment, equality and initial value are generated.

The following subsections detail the code generation strategy. The SEIZE column shows whether sdl2chill will generate a SEIZE statement for making identifiers visible in separate modules in the CHILL code. The differences in strategy for Samsung and ETRI CHILL is due to somewhat different compiler properties.

Type

ADT(T(x)) Translation action SEIZE?

T(G)

Generate from SDL

SEIZE

T(S)

Do not generate from SDL, assume standard CHILL type

no SEIZE

T(B)

Do not generate from SDL, assume user supplied

SEIZE

T(H)

Do not generate from SDL, assume
user supplied

no SEIZE

T

= T(B)


- (default)

= T(G)


Equality Test

ADT(E(x)) Translation action SEIZE?

E(G)

Use = if possible1, else generate yEqual_<sort> procedure

SEIZE if yEqual

E(S)

Use =

no SEIZE

E(B)

Use yEqual_<sort>, assume user supplied

SEIZE

E(H)

Use yEqual_<sort>, assume user supplied

no SEIZE

E

= E(B)


- (default)

= E(G)



1. "Possible" is defined below.

How to Make an SDL Value

ADT(K(x)) Translation action SEIZE?

K(G)

Use tuple (or built-in) if possible, else generate yMake_<sort>

SEIZE if yMake

K(S)

Use tuple

no SEIZE

K(B)

Use yMake_<sort>, assume user supplied

SEIZE

K(H)

Use yMake_<sort>, assume user included

no SEIZE

K

= K(B)


- (default)

= K(G)


Assignment

ADT(A(x)) Translation action SEIZE?

A(G)

Use := if possible, else generate yAssign_<sort>

SEIZE if yAssign

A(S)

Use :=

no SEIZE

A(B)

Use yAssign_<sort>, assume user supplied

SEIZE

A(H)

Use yAssign_<sort>, assume user supplied

no SEIZE

A

= A(B)


- (default)

= A(G)


How sdl2chill Determines "Possible"

The table below shows the decision table used with the "G" letter in the above situations.

X(G) CHIPSY1

E(G)

Use = always

K(G)

Use tuples for array and struct

A(G)

Use :=


1. The mapping may differ for other CHILL dialects.

Directives to sdl2chill

Syntax of Directives

sdl2chill recognizes a number of directives given mainly in SDL comments. The #ADT and #OP used in abstract data types are examples of such directives. These directives were described in the section User Defined Operators in connection with abstract data types and are not further discussed here.

A directive has the general structure:

  1. The start of comment characters: /*
  2. A # character.
  3. The directive name.
  4. Possible directive parameters given in free syntax, that is, spaces and carriage returns are allowed here.
  5. The end of comment characters: */.

Upper and lower case letters are considered to be equal in directive names.


Example 277       

Take as an example the directive:

This comment will be recognized as a directive only if no other character is inserted in the sequence /*#OP.11 After this part spaces and carriage returns may be inserted freely.


You may prefix a directive name by "CHILL" or "C" to condition the recognition of the directive to sdl2chill or to the Cadvanced/Cbasic Code Generator, respectively.

Selecting File Structure for Generated Code
-- Directive #SEPARATE

The purpose of the separate feature directive is to specify the file structure of the generated program. Both the division of the system into a number of files and the actual file names can be specified. There are two ways this information can be given.

sdl2chill can generate separate files for the system, for a block, and for a process. The #SEPARATE directive should in all cases be placed directly after the first semicolon in the system, block, or process heading; see the following example.


Example 278       

As can be seen a file name should be enclosed between quotes. sdl2chill will append appropriate extensions to this name when it generates code.

If no file name is given in the directive, the name of the system, block, or process will be used to obtain a file name. In such a case the file name will be the same as the name of the unit with the appropriate extension ( .ch, .cdbf, .o) depending on contents. Characters that are not letters, digits or underlines are stripped from the file name.

An Example of the Usage of #SEPARATE

In the following example a system structure and the #SEPARATE directives are given. This example is then used to show the generated file structure depending on selected generation option.


Example 279       

Applying Full Separate Generation

If full separate generation is selected in the SDT Analyzer interface then the following files will be generated12:

Sfile.ch
B1.ch
P11file.ch
P12.ch
B2.ch
P21.ch
P22.ch
Makefile

The .ch files contain the CHILL code generated for the corresponding SDL unit and the Makefile is the GNU makefile for compiling and linking the application program.

A.cdbf file for each compilation unit will be created when compiling the generated CHILL code. Interfaces between compilation units are contained in the .cdbf files derived for the system unit and for the block units. The compilation order thereby imposed is, of course, catered for by the Makefile.

Applying Separate Generation

If user defined separate generation is selected then the following files will be generated:

Sfile.ch

Contains code for units S, B2, P21

B1.ch

Contains code for units B1, P12

P11file.ch

Contains code for unit P11

P22.ch

Contains code for unit P22

Makefile


The user defined separate generation option thus makes it possible for a user to completely decide the file structure for the generated code. The comments on files and extensions given above are of course also valid in this case.

Applying No Separate Generation

If you select the "no separate generation" option the following files will be generated:

Sfile.ch

Contains code for all units

Makefile


The comments on files and extensions earlier are valid even here.

When Should Code Generation to Separate Files be Applied?

Generally a system should be divided into manageable pieces of code, that is, for a large system full separate generation should be used, while for a small system no separate generation ought to be used. The possibility to regenerate and recompile only parts of a system usually compensates for the overhead in generating and compiling several files for a large system

Applying SDL Names in CHILL Code
-- Directive #SDL

When you write CHILL code that is to be included in a generated program it is often necessary to refer to name strings of objects defined in SDL. The name string of an SDL object is, however, transformed when it is translated to CHILL. A prefix, which is a sequence of characters, is added to the SDL name string to make the CHILL name unique in the CHILL program. Furthermore, all characters in SDL name strings which are not allowed in a CHILL name string are removed. The prefixes are calculated by looking at the structure of definitions in the actual scope and in all scopes above. This means that adding a declaration at the system level might change all prefixes in blocks and processes contained in the system. As a consequence it is almost impossible to know the prefix of an object in advance.

To be able to write CHILL code and use the name string of SDL objects in that code, sdl2chill provides the directive #SDL which is used in CHILL code to translate an SDL name string to the corresponding CHILL name string.

The syntax of the #SDL directive is as follows:

or

There is also a short form for the directive. No characters are allowed between the # character and the (in this form.

or

Replace SDL name with the name string of an object in the SDL definition and entity class name by any of the following identifiers (upper and lower case letters are considered to be equal):

block
blockinst
blocksubst
blocktype
channel
channelsubst
connect
formalpar
gate
generator
imported
label
literal
newtype
operator
package
predef
procedure
process
processinst
processtype
remoteprd
remotevar
service
serviceinst
servicetype
signal
signallist
signalroute
sort (= newtype)
state
synonym
syntype
system
systemtype
timer
variable
view

This list contains all entity classes, which means that not all of the entries are relevant for practical use. When a #SDL directive is found in included CHILL code, sdl2chill first identifies which SDL object is referred and then replaces the directive by the CHILL name string for that object. The search for the SDL object starts in the current scope (the scope where the CHILL code is included), and follows the scope hierarchy outward to the system definition, until an appropriate SDL object is found. An appropriate SDL name is considered to be found if it has the specified name string and is in the specified entity class. If no entity class name is given the search is performed for all entity classes.

The table in the subsection SDL Predefined Types gives the direct translation between an SDL name and the corresponding CHILL name or expression. For these names the #SDL directive should not be used.

Including CHILL Code in TASK
-- Directive #CODE

You can include your own CHILL code in tasks by using the #CODE directive. This directive has the following syntax:

Type the directive name on the first line and the CHILL code on the following lines up to the end of comment symbol.

A #CODE directive can be placed:

The CHILL code in the directives is textually included in the generated code at the position of the directive. If, for example, a code directive is placed between two assignment statements, the code in the directive is inserted between the translated version of the assignment statements.

Note: 

sdl2chill handles the CHILL code in directives as text and performs no check that the code is valid CHILL code.

The code directive is included as a facility in sdl2chill to provide experienced users an escape possibility to the target language CHILL. This increases the application range of sdl2chill.

An example of a possible use of the code directive is: An algorithm for some computation, which in the SDL description is only indicated as task with an informal text, could be implemented in CHILL. In this case the directive #SDL described in the previous subsection probably will become useful to access variables and formal parameters defined in SDL.

Some general hints on how to write CHILL code that can be included into an application program can be found in the last part of the section User Defined Operators.

SDL and CHILL use the same symbols for start and end of comments. To have CHILL comments within the code that is included in any directive, the CHILL end-of-line comment must be used.

Including CHILL Data Statements
-- Directive #CODE

The #CODE directive can also be used to include CHILL definitions and declarations, for example mode definitions, locations declarations and procedure definitions into the generated CHILL program. This version of the code directive has the same syntax as the code directive for including CHILL code in task:

Code directives to include CHILL declarations may, generally speaking, be placed immediately after a semicolon that ends a declaration in SDL. More precisely it is allowed to place a #CODE directive after the semicolon that ends:

In the following small PR example the allowed positions are marked with an * followed by a number.


Example 280       

A code directive is considered to belong to the unit where it is defined and the data statements within the directive are thus placed among the other CHILL statements generated for that unit. In the example above directives at positions 1, 2, 3, 4, 12 belong to system s, directives at positions 5, 6, 7, 11 belong to block b1, while directives at positions 8, 9, 10 belong to process p1. Only one code directive may be placed at each available position.

The SDL declarations made in the corresponding unit are available in the code directives and can as usual be reached using the #SDL directive. All definitions and declarations made in code directives are of course available in code directives in tasks in the corresponding unit or in its subunits.

The general hints on how to write CHILL code that fits into a generated CHILL program given in the section User Defined Operators and in the section Applying SDL Names in CHILL Code -- Directive #SDL are also applicable here.

Including CHILL Code in SDL Expressions
-- Operator #CODE

For each sort defined in an SDL system (both predefined sorts and user defined sorts), sdl2chill defines implicitly the prefix operator #CODE with the following signature:

where S denotes the actual sort name. This operator or rather these operators make it possible to access e.g. locations, procedures and built-in procedures defined in CHILL using the #CODE directive in SDL expressions without violating the syntactic and static semantic rules of SDL.

During SDL to CHILL translation, sdl2chill will just copy the actual Charstring parameter into the generated CHILL code at the place where the #CODE operator is applied.


Example 281       

Suppose that x and y are SDL variables, which are translated to z72_x and z73_y, that a and b are CHILL locations, and p is a CHILL procedure defined in #CODE directives.

SDL expression CHILL expression
x + #CODE('a')
z72_x + a
x + #CODE('a * b')
z72_x + a * b 
x * #CODE('(a+b)') * y
z72_x * (a + b)* z73_y
#CODE('p(a, #SDL(x))')
p(a, z72_x) 


Within the Charstring parameter of a #CODE operator, the #SDL directive is available in the same way as in other included CHILL code. This is shown in the expression in the last line of the example above.

As there is one #CODE operator for each sort in the system, it is sometimes necessary to qualify the operator with a sort name to make it possible for the SDL Analyzer to resolve which operator that has been used. If, for example, the question and all answers in a decisions are given as applications of #CODE operators, then it is not possible to determine the type for the decision. One of the #CODE operators should then be qualified with a sort name to resolve the conflict.


Example 282       

In this case the sort of the decision cannot be resolved. To overcome this problem the question could be written as


Names and Prefixes in Generated Code

When an SDL name is translated to a CHILL name, a prefix is normally added to the name string given in SDL. This prefix is used to prevent name conflicts in the generated code, as SDL has other scope rules than CHILL and also allow different objects defined in the same scope to have the same name string, if the objects are of different entity classes. It is for example allowed in SDL to have a sort, a variable, and a procedure with the same name string defined in a process. So the purpose of the prefixes is to make each translated SDL name to a unique name in the CHILL program.

A generated CHILL name string for an SDL object contains four parts in the following order:

  1. The character "z"
  2. A sequence of characters that make the name string unique
  3. An underline "_"
  4. The SDL name string with characters not allowed in CHILL name strings stripped off.

A CHILL name string may contain letters, digits, and underline "_" and must start with a letter.

The sequence of characters that make the name string unique is determined by the position of the actual declaration in structure of declarations in the system:

The total sequence making a name string unique is now constructed from the "declaration numbers" for the actual unit and its parents, that is the units in which it is defined, starting from the top.

If, for example, a sort is defined as the 5th declaration in a block that in turn is the 12th declaration in the system, then the total sequence will be b4 (if not more than 36 declaration are present on any of the two levels).


Example 283       

Examples of generated name strings:

SDL
name string
Position of the Declaration Generated name string
S1

10th declaration in the system

z9_S1
Var2

3rd declaration in the process,

which is the 5th declaration in the block, which is the 15th declaration is system

ze42_Var2


This strategy for naming objects in the generated code should be used in all normal situations, as it guarantees that no name conflicts occur. sdl2chill offers, however, possibilities to change this strategy. In the user interface of the Analyzer and sdl2chill it is possible to select one of the following strategies: full prefix, entity class prefix, no prefix, or special prefix. Full prefix is default and is the strategy described above. If entity class prefix is selected, then the prefix that is concatenated with the SDL name string will be in accordance with the table below and depends only on the entity class of the object.

Entity class Prefix Entity class Prefix

Block, block type, block instance

blo

Process, Process type, Process instance

prs

Block substructure

bls

Remote procedure

rpc

Channel

cha

Remote variable

imp

Channel substructure

chs

Service, Service type, Service instance

ser

Connection

con

Signal

sig

Formal parameter

for

Signal list

sil

Gate

gat

Signal route

sir

Generator

gen

Sort

sor

Import

imp

State

sta

Label

lab

Syntype

syt

Literal

lit

Synonym

syo

Operator

ope

System, System type

sys

Package

pac

Timer

tim

Predef

pre

Variable

var

Procedure

prd

View

vie

Using entity class prefix means that the user must guarantee that no name conflict occurs. It also means, however, that the generated name strings are predictable and thus simplifies writing CHILL code where the SDL names are used. You only have to look for name conflicts within entity classes, for example not having two sorts with the same name string. The entity class prefixes handle the case when two objects of different entity class have the same name string. Note that the table above contains all entity classes. Not all of the items are actually used by sdl2chill.

The third alternative, no prefix, means of course that no prefixes are added to the SDL name string. The name string in the CHILL program will then be the SDL name string with the characters that are not allowed in CHILL name strings (everything except letters, digits, and underline) stripped off. In this case, you must guarantee that no name conflict occurs and that the stripped name string is allowed as a CHILL name string, that is, that it begins with a letter.

In the fourth alternative, special prefix, full prefixes are used for all entity classes except variable, formal parameter, sort, and syntype. For these entity classes no prefix is used.

As was said in the beginning of this subsection, you should have a good reason for selecting anything but the full prefix, as it could be very difficult to spot name conflicts. The compiler will in some cases find a conflict, but may in other cases consider the program as legal and generate an executable program with a possibly unwanted behavior.

Specifying Name Strings in Generated Code
-- Directive #NAME

If you wish to decide the name string of an object in generated code yourself you can use the #NAME directive. Place the directive directly after the name string in the declaration of the object. It should contain the desired name string to be used in the generated code within quotes.


Example 284       

The name string defined in a #NAME directive will be used everywhere that the SDL name is used in the generated code, with one exception: the name of the files for generated code are not affected by the usage of #NAME directives.

Assigning Priorities -- Directive #PRIO

Priorities in the CHILL and CHIPSY sense can be assigned to processes and signals using the directive #PRIO. How this will affect the behavior of the generated CHILL program is described in the CHIPSY Reference Manual.

Process Priorities

You can assign the CHIPSY implementation defined process parameters: optional stack need, execution priority and home execution processor to a process type. The #PRIO directives for processes should be placed directly after the process heading in the definition of the actual process type, as shown in Example 285.


Example 285        

Signal Priorities

You can assign a CHILL defined priority to a signal type or to the output of a specific signal value. The #PRIO directives for signals should be placed in the signal definition and in the output actions as shown in Example 285. A #PRIO directive specified in an output action will override a #PRIO directive possibly specified for the actual signal type.


Example 286        

Initialization -- Directive #MAIN

The #MAIN directive is used to include initialization code that should be executed before any process transitions are started. The directive should be placed in the system definition directly after the system heading.


Example 287       

The #MAIN directive has exactly the same structure as the #CODE directive for including code in tasks. The included code will, however, be placed in the reach of the outermost CHILL module of the generated program, and it will be executed after the initialization of the internal structure, but before any transitions.

Linking with Other Object Files
-- Directive #WITH

You can specify that a number of user defined and precompiled units (e.g. manually written CHILL modules) shall be linked together with a generated application program. You do this in a #WITH directive that should be placed in the system definition directly after the system heading.


Example 288       

Within the #WITH directive, the names of the object files that are to be included in the link operation should be given between quotes, as in the example above. These file names will then be included literally13 in the call to cmkmf, see Building and Running a CHILL Program from SDT.

The makefile will, however, not include any definition of how to compile the corresponding source files, as it is impossible for sdl2chill to know the compilation options or even what compiler the user wants.

Note: 

The #WITH directive will only affect the call to cmkmf. There will be no change in the generated CHILL code when a #WITH directive is introduced.

There may be only one #WITH directive per system or package.

Interfacing to Existing CHILL Code 
-- Directive #ENVIRONMENT and #CHILL

You can specify that importing CHILL names from user defined CDB_entries shall be allowed in a generated program. You do this in a #ENVIRONMENT directive that should be placed in the system definition directly after the system heading.


Example 289       

Within the #ENVIRONMENT directive the names of the actual CDB_entries should be given between quotes, as in the example above. These file names will then be included in the CHIPSY context directive of the generated compilation unit(s). As shown by the example, the #ENVIRONMENT directive and the #WITH directive may both be used for a system.

A user that knows how to interface to routines in other languages in a CHILL program, can with this knowledge and the #ENVIRONMENT directive and the #WITH directive link modules written in another language together with the generated program.

Note: 

The #ENVIRONMENT directive will only affect the generated CHILL code. There will be no change in the call to cmkmf when a #ENVIRONMENT directive is introduced.

Note: 

There may be only one #ENVIRONMENT directive per system or package.

The #CHILL directive is used with packages to interface system parts which are programmed in CHILL, see Package.

Identifying Initially Created Process Instances 
-- Directive #PIDLIT

The #PIDLIT directive enables you to identify the PId values of initially created processes. Place the #PIDLIT directive directly after the process heading. It should contain the name of the to be associated synonym within quotes as shown in Example 290 below. In sdl2chill, because output without to is not supported, you may use a #PIDLIT directive to easily get hold of the PId value of an initially created process instance in order to output a signal to it14.


Example 290        

In case you create more than one initial instance of a process, the identifying synonym must be an array of which the item sort is PId and the number of items is equal to the number of initially created instances. See also Example 290.


Example 291        

Applying Generated Programs

Software Structure

The application (or application part) generated with sdl2chill can be viewed as having three components:

  1. The SDL system
  2. The environment of the system
  3. The system interface module where you connect the SDL system to its environment

In the SDL system processes are created and stopped, transitions are executed, signals are sent from one process to another initiating new transitions, timer signals are sent, and so on. These are examples of internal actions that only affect the execution of the SDL system. An SDL system communicates with its environment by sending signals to the environment and by receiving signals from the environment.

The SDL system may be viewed as a CHILL module interfaced to via signals. This makes it easy to plug in a system as an application program part anywhere in your CHILL software structure and as the interface definition is also generated by sdl2chill, consistency check is fully catered for by CHILL.

The environment of the SDL system consists of CRS, other application program parts, the hardware, a network of computers and so on. In this world other actions than just signal sending and receiving are required. Examples of some actions that an application may want to perform are:

Such actions can efficiently and reliably be implemented in CHILL.

The system interface module is the place where the two worlds, the SDL system and the environment, meet. Here signals sent from the SDL system to the environment can induce all kinds of events in the environment, and events in the environment might cause signals to be sent into the SDL system. The system interfacing code may be collected in a separate interface module or, if more convenient, embedded in the application program part(s) which the SDL system is connected to. Definitions of the signals connecting the SDL system to its environment is provided by sdl2chill, but the actual functionality of the system interface module, of course, you must provide yourself because sdl2chill has no knowledge of this. How to write the system interface module is described in the next section.

When it comes to system architecture, utilization of the application (parts) generated by sdl2chill is very flexible. In a distributed system an application might consist of several communicating SDL systems. Each SDL system will become one executable program. It might execute either as an operating system process (e.g. UNIX process), or it might execute in a processor of its own, communicating over a network with other processors. There can of course also be combinations of these. Distribution is facilitated by means of the CHIPSY Distributed Processing Services as described in the CHIPSY Reference Manual.

The System Interface Module

With sdl2chill, interfacing to an SDL system as shown in the below example, is very simple:


Example 292        

SDL-PR specification:

Generated CHILL:

System interface module:


A Complete Example

This section is a complete example showing the SDL specification for a system called Demongame, and the CHILL code for connecting to it for the purpose of playing the game by giving commands from the workstation keyboard and showing results on the screen. The generated CHILL code for Demongame is also shown. The latter is not needed in order to write the system interface module, but it is included here anyhow in order to show the actual SDL to CHILL mapping for a non-trivial example.

SDL Specification for Demongame

System Interface Module

Generated CHILL program

Implementation Dependencies

SDL Implementation Dependencies

sdl2chill handles the majority of SDL concepts according to the definition of SDL-88. A few extension taken from SDL-92 and SDL-96 are allowed. There are, however, a set of implementation dependencies and restrictions that are discussed in this section.

The restrictions in the SDT Analyzer, which of course also affect sdl2chill, are summarized below. For more information see The SDT Analyzer.

sdl2chill introduces additional implementation dependencies on the allowed set of SDL concepts:

The following SDL-92 features are incorporated in sdl2chill:

The following SDL-96 features are incorporated in sdl2chill:

Implementation Dependencies on Integer

Due to the implementation of Integer using 16-bit integers in CHILL, there is a restriction in range for Integer values. Integers must be in the range -215..215-1. There are in the same way restrictions both in range and precision for Real, Time, and Duration, as they are implemented using the CRS defined mode LONGDURATION. In the interface to the SDL Services the literals of Real, Time, and Duration are represented by two 32-bit integers. The first integer of Time, and Duration represents the number of seconds and the second integer represents the number of nanoseconds.


1. Requires GNU Make. The Makefile is produced by means of the CHIPSY Makefile generator cmkmf.

2. Report files and temporary intermediate files used by CHIPSY during compiling and linking are not shown.

3. The CHILL program executes on its own and no connection to other tools in SDT or in CHIPSY is established by sdl2chill. See also the CHIPSY Reference Manual.

4. This forces textually relocating and goto-chaining the CHILL code generated for transitions containing labels to which goto is made from other transitions. To the user of sdl2chill, a "structured SDL specification" thus translates to a structured CHILL program while an "unstructured specification" maps to a CHILL program relying heavily on the use of goto.

5. The "else signal" is a CHIPSY implementation-defined CHILL signal.

6. The #PRIO directive may be used to override the default values for the CHIPSY CHILL implementation defined process parameters. See Assigning Priorities -- Directive #PRIO.

7. An expression can be evaluated at analysis time if it only contains literals and operators defined in the predefined SDL sorts and other synonyms which are possible to calculate at analysis time.

8. For advanced sdl2chill use it is possible to adapt the SDL Services to meet specific needs. This may be done without affecting the sdl2chill tool itself provided that the library interface is unchanged. The exporting CDB entry of the CRS Services is (CRS)/_sdl/SDL_support.

9. At this point the usage of (B) may seem redundant. This syntax, however, is introduced here to prepare for specifying other implementation techniques as described in More about Abstract Data Types.

10. This is an escape mechanism that should be used only when it is really needed e.g. for interfacing to an existing system, as a means to define implementation details or to remove bottlenecks during the final performance tuning.

11. In case a space is erroneously inserted e.g. before the # character, the intended directive is treated as an ordinary comment, and it has no impact on the SDL to CHILL translation at all.

12. The Makefile is actually generated in the cmkmf step, see Generating a CHILL Program.

13. So the strings could also contain references to source files, e.g. in other directories which should be compiled together with the SDL system source files. Cf. CHIPSY documentation.

14. Using the #PIDLIT directive can usually be replaced by a start-up protocol in which the PId values of the initially created processes are exchanged. To facilitate SDL to CHILL translation of a specification without enforcing you to introduce such a protocol, the #PIDLIT directive has, however, been implemented as a pragmatic extension to SDL.


[Previous] [Next] [Contents] [Index]