IBM
Contents Index Previous Next



Exceptions for Directives


Selecting File Structure for Generated Code - Directive #SEPARATE

The purpose of the separate generation feature 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.

The Cmicro SDL to C Compiler can generate a separate file for:

Note:

Instantiations cannot be separated. If #SEPARATE directives are used, they should be placed directly after the first semicolon in the system, block, process, or procedure heading; see the following example.

Example 580 : #SEPARATE Directive

system S; /*#SEPARATE 'filename' */ 
block B; /*#SEPARATE */
process type P1 inherits PType; /*#SEPARATE */
process P2 (1, ); /*#SEPARATE */
procedure Q; /*#SEPARATE */

In the example above the two versions of separate directive, with or without file name, are shown. As can be seen a file name should be enclosed between quotes. The Cmicro SDL to C Compiler 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, process, or procedure will be used to obtain a file name. In such a case the file name becomes the name of the unit with the appropriate extension (.c .h) depending on contents. The file name is stripped of characters that are not letters, digits or underscores.

The possibility to set up full, user-defined, or no separation in the Organizer's Make dialog and in the user-interface of a stand-alone Analyzer (see Generated Files), can be used in a simple manner to select certain default separation schemes. This setting will be interpreted in the following way:

Independently if No, User defined, or Full separation has been selected, the Cmicro SDL to C Compiler will use the file name specified in the Edit Separation dialog or the #SEPARATE directive, for a file that is to be generated.

An Example of the Usage of the Separate Feature

In the following example a system structure and the #SEPARATE directives are given. The same information can easily be set up in the Organizer as well. This example is then used to show the generated file structure depending on selected generation options.

Example 581 : #SEPARATE Directive

system S; /*#SEPARATE 'Sfile' */
  block B1; /*#SEPARATE */
    process P11; /*#SEPARATE 'P11file' */
    process P12;
  block B2;
    process P21;
    process P22; /*#SEPARATE */

Applying Full Separate Generation

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

Sfile.c	 

Sfile.h 

B1.c

B1.h 

P11file.c 



P12.c 



B2.c

B2.h

P21.c 



P22.c 



The .c files contain the C code for the corresponding SDL unit and the .h files contain the module interfaces.

Applying Separate Generation

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

Sfile.c

Sfile.h

Contains code for units S, B2, P21

B1.c

B1.h

Contains code for units B1, P12

P11file.c



Contains code for unit P11

P22.c



Contains code for unit P22

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 the separation option No is selected, only the following file will be generated:

Sfile.c


Contains code for all units

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

Guidelines

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 re-compile only parts of a system usually compensate for the overhead in generating and compiling several files for a large system.

Note:

A file name has to be specified, using the Organizer Edit Separation command or the #SEPARATE directive, if two units in the system have the same name in SDL and should both be generated on separate files. Otherwise the same file name will be used for both units.

Assigning Priorities - Directive #PRIO

#PRIO for Processes

Priorities can be assigned to processes using the directive #PRIO. The process priorities will affect the scheduling of processes, see Scheduling. A priority is a positive integer, where low value means high priority. #PRIO directives should be placed directly after the process heading in the definition of the current process.

Example 582 : #PRIO Directive .

Process P1; /*#PRIO 0 */ 
Process P2(1,1); /*#PRIO 1 */ 

Process P3 : P3Type; /*#PRIO 0 */ 
Process P4(1,1) : P4Type; /*#PRIO 1 */ 

Processes that do not contain any priority directive will have a user defined default priority with the name xDefaultPrioProcess.

There are some things to be kept in mind when using process priorities:

#PRIO for Signals

Priorities can be assigned to signals using the directive #PRIO. The signal priorities will also effect the scheduling of processes, see Scheduling.

Signal priorities can be specified, either:

It is impossible to specify #PRIO in a SDL input. Cmicro will ignore any occurrence of #PRIO in SDL input.

Signal priorities do affect the SDL output and the SDL create actions only.

The following rules are to be considered here:

The following example will give more explanations (note, that the values PA, PB are of sort pid):

Example 583 : #PRIO Directive .

Signal
S1, /*#PRIO 11 */ 
S2, /*#PRIO 22 */ 
S3,  
S4; /*#PRIO 44 */ 

....
output S1 to PA
output S1 to PB; /*#PRIO 55*/
....
output S3 to PC;
output S3 to PD; /*#PRIO 66*/

Assuming the following C definition:

#define xDefaultPrioSignal 100

the following priorities will then be generated:

output S1 to PA	 --->use of prio 11
output S1 to PB--->use of prio 55
....
output S3 to PC--->use of prio 100
output S3 to PD--->use of prio 66

Modifying Outputs - Directive #EXTSIG, #ALT, #TRANSFER

There is no difference for the #EXTSIG, #ALT and #TRANSFER directives for Cmicro compared with Cadvanced, except that the use of it will sometime lead to a better performance. This is because if #EXTSIG for example is used in the case of an output to the environment, the user can prevent the Cmicro Kernel to be called (and the xOutEnv function to be executed).


http://www.ibm.com/rational
Contents Index Previous Next