IBM
Contents Index Previous Next



Internal


Partitioning Diagram Model File

The Targeting Expert needs to know how the SDL system which is used for targeting should be partitioned. This is done by using a partitioning diagram model.

Note:

The partitioning diagram model will be generated by the Deployment Editor for deployed systems into a partitioning diagram model file <partitioning diagram model>.pdm. It should not be modified by hand! Please see Generating Partitioning Diagram Data for the Targeting Expert for more information.

If there is no deployment done for a system, the Targeting Expert generates a default partitioning diagram model for its internal use. This partitioning diagram model is not available as a file. For a default partitioning diagram model there is no chance to specify integration models or threads.

Definitions

The complete SDL system is mirrored in the partitioning diagram's application which takes several nodes.

Each node can represent a run-time (physical) object with memory and processing capability and is a collection of several components.

Each component is a collection of different objects, with each object representing an SDL qualifier. A component will result in one executable or OS task.

File Syntax Example

Estimated there is an SDL system like the one shown in Figure 546,

Figure 546 : An SDL system

then the simplest possible partitioning diagram model looks like the one shown in Figure 547.

Figure 547 : A possible partitioning diagram model

The first few lines of the corresponding partitioning diagram model file is shown in Example 490:

Example 490 : Partitioning diagram model file

TIMESTAMP: 948787119

APPLICATION*0: access
detail+SystemFileName: access.sdt

NODE*1: node

COMPONENT*2: component

OBJECT*3: object
detail+Qualifier: access

Explanations

More Supported Keywords

Details of COMPONENT
Details of OBJECT
Details of THREAD

Configuration Files

For each SDL to C compiler that will be used there is one configuration file ca_conf.def (Cadvanced), cm_conf.def (Cmicro) and ce_conf.def (Cextreme).

The configuration files for all SDL to C compilers can be found in <installationdir>/sdt/sdtdir.

The c*_conf.def files are ASCII text files that can be (should be) extended by you to adapt a new compiler or to adapt a new communications link (Cmicro only).

You can find all the known configuration flags in:

Structure of the Configuration File cm_conf.def

Note:

All the descriptions in this section are valid for the SDL to C compiler Cmicro only.

Compiler

All the compilers currently supported by a SDL to C compiler library are listed in the c*_conf.def file like displayed in Example 491.

Example 491 : Structure of a compiler entry

BEGIN
  IAR_C51
  IAR systems compiler of 8051
  COMPILER
  Microcontroller compiler
END

The first and the last line of the example simply marks the start and the end of one entry.

Line 2 is the flag which will be used to include the appropriate compiler section in the used library (see ml_typ.h for Cmicro and scttypes.h for Cadvanced).

Line 3 is the text which will be shown in the Targeting Experts user interface.

Line 4 must be COMPILER in this case.

Line 5 is the compiler group this compiler should be associated with. In the distributed files c*_conf.def there are three groups, namely:

Communications Link

Note:

This section is valid only if the Cmicro SDL to C Compiler is used.

The example below shows the structure of one entry.

Example 492 : Structure of a cm_conf.def entries

 1 BEGIN
 2   XMK_USE_V24
 3    V24 communication
 4    COMMLINK
 5    V24 interface
 6   AUTOSET
 7     XMK_V24_BAUD
 8     XMK_V24_DEVICE
 9   END
10 END

Lines 1 and 10 mark the start and the end of one entry.

Line 2 gives the name of the flag as it appears in the generated file ml_mcf.h. According to this example line 3 is the marker which appears in the Targeting Expert graphical user interface.

Line 4 specifies the main group this entry belongs to. It has to be COMMLINK in this case.

Line 5 gives the subgroup of the entry. This subgroup can be anything you like. In the delivered version there is only the subgroup V24 interface. However, you can define your own communications link CAN Bus for example.

The lines 6 and 9 belong together and between these lines all flags are listed which have to be set when the flag on line 2 is set. The amount of flags (lines 7 and 8 in the example) is free. In the same way as AUTOSET in line 6 there can also be the entries RESET or DEPEND.

RESET means the following flags will be reset if this flag is defined and DEPEND means this flag can only be set if the following flags (lines 7 and 8) are already defined.

Not given in the example above is the section VALUE, (like AUTOSET finished by an END) which assign a value to the flag. This section can include three lines of information. The first gives the default value. And, if the value is numeric, the second line gives the lowest and the third one the highest value. You are asked to have a look into c*_conf.def.

Also not given in the example above is the section VALUE_LIST (finished by an END) which assign a value to the flag with a list of allowed values given. The first value is the default value, the following values (with no upper limit) are giving the list of allowed values. The default value must be given in the list again.

Pre-defined Integration Settings

Introduction

Pre-defined integration settings must be seen as a set of default values which can be used for targeting purposes.

There are several pre-defined integration settings distributed with each installation.

Figure 548 : Search order on UNIX

Figure 549 : Search order in Windows

Distributed Pre-defined Integration Settings

For Use with Cadvanced SDL to C Compiler

Supported compiler

On Sun:

    • Sun GNU gcc
    • Sun Workshop cc
    • Sun Workshop CC

In Windows:

    • Microsoft VC++

Used kernel directory

-

Timers

Timers are not implemented, i.e. timers set in the SDL system will expire at once

Environment

Will be handled in the Simulator UI

More info

See The SDL Simulator.

Supported compiler

On Sun:

    • Sun GNU gcc
    • Sun Workshop cc
    • Sun Workshop CC

On Windows:

    • Microsoft VC++

Used kernel directory

-

Timers

Timers are implemented in a way that one timer tick is equal to one second, i.e. a timer set to 10 in the SDL system will expire after 10 seconds.

Environment

Will be handled in the Simulator UI

More info

See The SDL Simulator.

Supported compiler

On Sun:

    • Sun GNU gcc
    • Sun Workshop cc
    • Sun Workshop CC

In Windows:

    • Microsoft VC++

Used kernel directory

-

Timers

Not handled

Environment

Not handled

More info

See The Performance Library.

Supported compiler

On Sun:

    • Sun GNU gcc
    • Sun Workshop cc

On Windows:

    • Microsoft VC++

Used kernel directory

$(sdtdir)/SCT*TTCNLINK

More info

See TTCN Test Suite Generation.

Supported compiler

On Sun:

    • Sun GNU gcc
    • Sun Workshop cc

On Windows:

    • Microsoft VC++

Used kernel directory

$(sdtdir)/SCT*VALIDATOR

More info

See The SDL Explorer.

Supported compiler

On Sun:

    • Sun GNU gcc
    • Sun Workshop cc
    • Sun Workshop CC

On Windows:

    • Microsoft VC++

Used kernel directory

-

Timers

Timers are implemented in a way that one timer tick is equal to one second, i.e. a timer set to 10 in the SDL system will expire after 10 seconds.

Environment

Has to be implemented by the user.

More info

See Compilation Switches.

Supported compiler

On Sun:

    • Sun GNU gcc
    • Sun Workshop cc
    • Sun Workshop CC

On Windows:

    • Microsoft VC++

Used kernel directory

-

Timers

Timers are implemented in a way that one timer tick is equal to one second, i.e. a timer set to 10 in the SDL system will expire after 10 seconds.

Environment

Has to be implemented by the user.

More info

See Compilation Switches.

Note: (VxWorks only)

The environment variable WIND_BASE has to be set on your system!

Note: (OSE only)

The environment variable OSE_ROOT has to be set on your system!

Supported compiler

OSE:

    • Sun GNU gcc
    • Microsoft VC++

Solaris:

    • Sun GNU gcc
    • Sun Workshop cc
    • Sun Workshop CC

VxWorks:

    • gnu tool chain

Win32:

    • Microsoft VC++

Used kernel directory

-

Timers

OS timer

More info

See Threaded Integration.

For Use with the Cmicro SDL to C Compiler

Supported compiler

On Sun:

    • Sun GNU gcc
    • Sun Workshop cc
    • Sun Workshop CC

On Windows:

    • Microsoft VC++

Used kernel directory

-

Timers

Timers are implemented in a way that one timer tick is equal to one second, i.e. a timer set to 10 in the SDL system will expire after 10 seconds.

Environment

Has to be implemented by the user.

Template files

Taken from $(sdtdir)\cmicro\template

More info

The target executable can be executed on a command line.

Supported compiler

On Sun:

    • Sun GNU gcc
    • Sun Workshop cc
    • Sun Workshop CC

On Windows:

    • Microsoft VC++

Used kernel directory

-

Timers

Timers are implemented in a way that one timer tick is equal to one second, i.e. a timer set to 10 in the SDL system will expire after 10 seconds.

Environment

Has to be implemented by the user.

Template files

Taken from $(sdtdir)\cmicro\template

More info

The target executable has to be started manually after the Target Tester is started by the Targeting Expert.

Supported compiler

On Sun:

    • Sun GNU gcc
    • Sun Workshop CC

On Windows:

    • Microsoft VC++

Used kernel directory

-

Timers

Timers are not implemented, i.e a timer set in the SDL system will never expire.

Environment

Will be handled in the SDL Target Tester UI.

Template files

Taken from $(sdtdir)\cmicro\template

More info

The target is executed as the SDL Target Tester's gateway. After a complete make The SDL Target Testerwill be started and the target can be tested.

Supported compiler

On Sun:

    • Sun GNU gcc
    • Sun Workshop CC

On Windows:

    • Microsoft VC++

Used kernel directory

-

Timers

Timers are implemented in a way that one timer tick is equal to one second, i.e. a timer set to 10 in the SDL system will expire after 10 seconds.

Environment

Will be handled in the SDL Target Tester UI.

Template files

Taken from $(sdtdir)\cmicro\template

More help

The target is executed as the SDL Target Tester's gateway. After a complete make The SDL Target Tester will be started and the target can be tested.

Supported compiler

On Sun:

    • Sun GNU gcc
    • Sun Workshop CC

On Windows:

    • Microsoft VC++

Used kernel directory

-

Timers

Timers are implemented in a way that one timer tick is equal to one second, i.e. a timer set to 10 in the SDL system will expire after 10 seconds.

Environment

Has to be implemented by the user.

Template files

Taken from $(sdtdir)\cmicro\template

More help

The target is executed as the SDL Target Tester's gateway. After a complete make The SDL Target Tester will be started and the target can be tested.

For Use with the Cextreme SDL to C Compiler

Syntax of the .its Files

There is a more or less complex syntax to be followed in .its files which will be described here. In principle each .its file is divided into four sections:

You can find further syntax information in Comments and empty Lines and Other Rules.

Description about the Settings

The Targeting Expert will read in the description and display it in the user interface whenever a set of pre-defined integration settings is selected.

This section starts with [DESCRIPTION] and has got the only entry HelpLink. The description is a link name to this manual.

The Settings

The section of the .its files which contains the settings starts with [SETTINGS]. They must be ordered with the Global Settings (A) first, followed by the Compiler specific Definitions.

The global settings start with the <keyword1> equal to Preferences and the delimiter '+', i.e. an allowed line in this section looks like:

Preferences+<keyword2>: parameter

Example 493 : Pre-defined integration settings (2A)

Preference+IntegrationSettings: <name>

The meaning of <keyword2> can be found in the table below.

Keyword 2 Meaning of the parameter

IntegrationSettings

The name of this pre-defined integration setting is entered here.

The global settings part B start with the <keyword1> equal to the name of the pre-defined integration settings (see Global Settings (A)) and the delimiter '+', i.e. an allowed line in this section looks like:

<name>+<keyword2>: parameter

Example 494 : Pre-defined integration settings (2B)

Simulation+CompilersUsed:       Microsoft
Simulation+CodeGenerator:       Cadvanced
Simulation+GenerateMakefile:    YES

The meaning of <keyword2> can be found in the table below.

Keyword 2 Meaning of the parameter
CompilersUsed

The name of a compiler which is used to build the target application must be entered here. This line can appear more than once per file to allow the description of more than one compiler.

CodeGenerator

The name of the SDL to C compiler this pre-defined integration settings are designed for must be entered to the right of this keyword. Currently the SDL to C compilers

    • Cadvanced
    • Cmicro
    • Cextreme

are possible here.

GenerateAllFiles

All the files will be re-generated even if the contents have not changed (YES) or not (NO)

GenerateMakefile

The makefile generation should be switched on (YES) but can of course be switched off by specifying NO here.

GenerateLowerCase

The SDL to C compiler should generate all SDL identifiers in lower case (YES) or as defined (NO)

GenerateEnvFunctions

The SDL to C compiler should generate template environment functions (YES) or not (NO)

GenerateEnvHeader

The SDL to C compiler should generate an environment header file (YES) or not (NO)

GeneratePrefix

All variables will be generated with full prefix. Default is (YES) but can of course be switched off by specifying NO here.

GenerateSignalNumber

The SDL to C compiler should generate a signal number file (YES) or not (NO)

GenerateSDLCoder

The SDL to C compiler should generate an SDL coder functions file (NO, ASCII or <user>)

GenerateASNCoder

The SDL to C compiler should generate an ASN.1 coder functions file (NO, BER, PER or <user>)

Separation

The SDL to C compiler shall generate the C files separated according to the given value: NO, USER, FULL

Analyze

The Analyzer/SDL to C compiler should be invoked during the make (YES) or not (NO)

TestTool

The Test application to be used can be entered here, i.e. the entries Simulator, Validator or Tester but also a complete command line.

FileNamePrefix

The SDL to C compiler will generate all files with the given filename prefix.

GenerateIfcSynonyms

The SDL to C compiler should generate the
SYNONYMS section into the env. header file (YES) or not (NO).
(depends on GenerateEnvHeader)

GenerateIfcLiterals

The SDL to C compiler should generate the
LITERALS section into the env. header file (YES) or not (NO).
(depends on GenerateEnvHeader)

GenerateIfcTypedefs

The SDL to C compiler should generate the
TYPEDEFS section into the env. header file (YES) or not (NO).
(depends on GenerateEnvHeader)

GenerateIfcOperators

The SDL to C compiler should generate the
OPERATORS section into the env. header file (YES) or not (NO).
(depends on GenerateEnvHeader)

GenerateIfcSignals

The SDL to C compiler should generate the
SIGNALS section into the env. header file (YES) or not (NO).
(depends on GenerateEnvHeader)

GenerateIfcChannels

The SDL to C compiler should generate the
CHANNELS section into the env. header file (YES) or not (NO).
(depends on GenerateEnvHeader)

IfcPrefixSynonyms

The SDL to C compiler will generate SYNONYMS using the specified rule (Default is %n)

IfcPrefixLiterals

The SDL to C compiler will generate SYNONYMS using the specified rule (Default is %n)

IfcPrefixTypes

The SDL to C compiler will generate SYNONYMS using the specified rule (Default is %n)

IfcPrefixSignals

The SDL to C compiler will generate SYNONYMS using the specified rule (Default is %n)

IfcPrefixChannels

The SDL to C compiler will generate SYNONYMS using the specified rule (Default is %n)

SuppressText

The Analyzer error or warning message to suppress can be given here.

This segment has got all the definitions for an unlimited amount of compilers. All the keywords start with

<name of the setting>+<compiler-name>*

followed by one or two further keywords. If it is followed by two keywords both are separated by '~'.

Example 495 : Pre-defined integration settings (3)

Simulation+Microsoft*Compiler~Tool:    cl
Simulation+Microsoft*Compiler~Options: -nologo %I -ML -c -D_Windows -DSCTDEBCOM 
/Fo%o %s
Simulation+Microsoft*Compiler~Include: -I$(sctuseinclude)
Simulation+Microsoft*Compiler~Flag:   IC86
Simulation+Microsoft*Linker~Tool:     link
Simulation+Microsoft*Linker~Options:  -nologo -subsystem:console %O /OUT:%e
Simulation+Microsoft*ObjectExtension:     _smc.obj 
Simulation+Microsoft*ExecutableExtension: _smc.exe
Simulation+Microsoft*FileToCompile:   $(sdtdir)\INCLUDE\sctsdl.c
Simulation+Microsoft*FileToCompile:   $(sdtdir)\INCLUDE\sctpred.c
Simulation+Microsoft*FileToCompile:   $(sdtdir)\INCLUDE\sctos.c
Simulation+Microsoft*FileToCompile:   $(sdtdir)\INCLUDE\sctmon.c
Simulation+Microsoft*FileToCompile:   $(sdtdir)\INCLUDE\sctutil.c
Simulation+Microsoft*FileToCompile:   $(sdtdir)\SCTADEBCOM\sctpost.c
Simulation+Microsoft*LibrariesToLink: $(sdtdir)\INCLUDE\msvc50\libpost.lib
Simulation+Microsoft*LibrariesToLink: user32.lib
Simulation+Microsoft*Make~Tool: Microsoft nmake (using temporary response file)
Simulation+Microsoft*MakefileName:        my_makefile.m
Simulation+Microsoft*MakefileGenerator:   -
Simulation+Microsoft*ObjectDirectory:     objects

All the keywords and the allowed combinations can be found in the table below.

Keyword 3 Keyword 4 Meaning of the parameter
Compiler

Tool

Name of the compiler application

Compiler

Tool2

Name of the C parser application (optional)

Compiler

Tool3

Name of the assembler application (optional)

Compiler

Options

Compiler command line options (Please see Compiler)

Compiler

Options2

C parser command line options (optional)

Compiler

Options3

Assembler command line options (optional)

Compiler

LibFlag

The compiler's option to set defines plus the library flag (e.g. SCTDEBCOM)

Compiler

Include

The compiler's option for include paths and the include paths

Compiler

CodInclude

The compiler's option for include paths and the include paths to the coder files

Compiler

Flag

Compiler flag (Please see Compiler Flag)

Linker

Tool

Name of the linker application

Linker

Options

Linker command line options (Please see Linker)

ObjectExtension



Extension of the object files

ExecutableExtension



Extension of the target executable

FilesToCompile



Kernel, library and template files to be compiled. This entry can be used more than once.

TesterFilesToCompile



Tester files to be compiled. This entry can be used more than once. (Cmicro only)

FilesToCopy



Template files which should be copied into the target directory. Environment variable §(sdtdir) can be used

ObjectsToLink



Additional object files to be linked. This entry can be used more than once.

LibrariesToLink



Additional libraries to be linked (e.g. the compiler's libraries). This entry can be used more than once.

Make

Tool

The name of the make application. This can be:

  • Microsoft nmake (using temporary response file)
  • Microsoft nmake
  • UNIX make
MakefileName



The name of the makefile to be generated (or respectively to be used) is entered here.

MakefileGenerator



The Targeting Experts supports the use of external makefile generators which is to be entered here. An intern means that the build-in makefile generator is to be used

ObjectDirectory



The relative path (seen from the target directory) for the object directory can be entered here. If not specified Targeting expert will generate the makefile in a way that the object files will be written into the target directory when make is executed.

LibraryDirectory



If this entry is specified the SDL to C compiler's library will be taken from the specified path. If not specified it will be taken from $sdtdir (%SDTDIR%).

Download

Tool

The full command line to invoke the download application.

PreMake



Action to perform before the target application will be made in the makefile.

PreCompile



If the generated code should be modified before it is compiled, an appropriate application (complete command line) should be entered here.

PostLink



If the linked target application needs to be modified (e.g. conversion into HEX format), the appropriate application (complete command line) should be entered here.

AddCompiler

Tool

For the additional files (see FilesToCompile) the name of the compiler application must be entered here.

AddCompiler

Options

The command line options for the compiler in AddCompiler must be specified here.

AddCompiler

Include

The compiler's option for include paths and the include paths for the compiler entered in AddCompiler

AddCompiler

Depend

The dependencies for the additional files (used inside of the generated makefile).

AddObjectExtension



The object extension of the AddCompiler must be entered here.

AddFilesToCompile



Kernel files to be compiled (e.g. communications link). This entry can be used more than once.

Default Configuration Settings

For several pre-defined integrations it is necessary to have some configuration flags defined as default. In this section a simple list of all configuration flags which should be set is given.

This section starts with [CONFIGURATION_DEFAULT].

Please see Configuration Files for more information about configuration flags.

Configuration Settings to Be Set

For several pre-defined integrations it is necessary to have some configuration flags set without giving you the chance to un-select them. In this section a simple list of all configuration flags which have to be set is given.

This section starts with [CONFIGURATION_SET].

Please see Configuration Files for more information about configuration flags.

Configuration Settings to Be Reset

In opposite to the configuration flags which have to be set, it is of course necessary sometimes to prevent the selection of other flags. This can be done in this section by simply listing all the flags that have to be reset.

This section starts with [CONFIGURATION_RESET].

Please see Configuration Files for more information about configuration flags.

SDL to C Compiler Settings to Be Disabled

For some pre-defined integrations it does not make sense to configure all the SDL to C compiler options available. It is possible here to list all the options to be disabled in the user interface.

This section starts with [SDL_TO_C_COMPILER_DISABLED].

SDL to C Compiler Settings to Be Enabled

For some pre-defined integrations some SDL to C compiler options needs to be enabled by default. It is possible here to list all the options to be enabled in the user interface.

This section starts with [SDL_TO_C_COMPILER_DEFAULT].

Comments and empty Lines
Other Rules

User-defined Integration Settings

All the settings done by the user will be stored in separate files into the target directory, i.e.:

Target Sub-Directory Structure

The Targeting Expert automatically sets up a sub-directory structure for all the applications, nodes and components. Furthermore there is a sub directory for each kind of integration done.

Example 496 : Sub-directory structure

Figure 550 : Example of a partitioning diagram

Estimated there is a partitioning diagram which looks like Figure 550, the Targeting Expert generates a sub-directory structure like:

<target_dir>
   + application._0
       + node._1
           + component._2

Note:

The suffixes ._* give unique identifiers which make it possible to rename the application, nodes or components and to keep the done settings. In this case the Targeting Expert automatically modifies the names of the subdirectories.

Later, after you have built a Simulator and an Explorer for the component, for example, then the sub-directory structure was extended to:
<target_dir>
     + application._0
            + node._1
               + component._2
                    + Simulator
                    + Validator

Flat Directory Structure

When using an .sdt or .pr file as input the directory structure will be flatten automatically. I.e it will look like

<target_dir>
     + application._0
           + Simulator
           + Validator

This is possible because there can only be one node with one component in both cases.

Generated Makefile

Before the selected make tool is invoked the Targeting Expert generates a makefile with all of the necessary settings done. (Please see Configure Compiler, Linker and Make for information on how to set up the makefile generation.)

Caution!

The standard header files of the used SDL to C compiler library are not used as dependencies in the compilation rules, i.e. after modifying one of these files you have to select the Clean entry in the Make Menu.

Comparisons

There are a few differences that need to be mentioned when comparing the way the Targeting Expert handles makefiles with the way the Organizer's Make dialog does.

When using the Targeting Expert...

Note:

The only exceptions in which the Targeting Expert uses some information from the associated kernel directory are the integrations Validation and TTCN Link. In both cases a library is taken from the kernel directory.

User Modifications

After all it is possible that there are a few adaptations to be done, e.g. if there is an assembler file which needs to be assembled and linked.

Example 497 shows the section of a generated makefile where it is possible to add further object files.

Example 497 : Generated makefile (1)

######## UserObjectsStart (Do not edit this line!) ##########
userOBJECTFILES1 =

userOBJECTFILES2 =

######## UserObjectsEnd   (Do not edit this line!) ##########

The list userOBJECTFILES1 will be inserted at the front of all the object files to link. Accordingly userOBJECTFILES2 will be inserted at the end.

The rules and the dependencies for the files in Example 497 must be given in the section shown in Example 498.

Example 498 : Generated makefile (2)

######## UserRulesStart (Do not edit this line!) ##########

######## UserRulesEnd   (Do not edit this line!) ##########

Caution!

Any modification that is done outside of the sections described in Example 497 and Example 498 will be overwritten when the makefile is generated anew.

Parameter File sdttaex.par

General

One of the delivered configuration files used by the Targeting Expert is called sdttaex.par. Several different sections give information that is statically used during runtime. Under normal circumstances this file does not need to be modified. However, there might be the need to extend the Targeting Expert functions.

Please see the following sub-sections for more information what can be configured:

Search Order for sdttaex.par

The following shown search order applies when the Targeting Expert is started. The distributed version of sdttaex.par is always placed in <installationdir>/bin/<platform>bin

Figure 551 : Search order for sdttaex.par on UNIX

Figure 552 : Search order for sdttaex.par in Windows

Compiler Error Descriptions

The section [COMPILER-ERROR-DESCRIPTION] of sdttaex.par is filled with regular expressions describing the construction of compiler error messages.

Example 499 : [COMPILER-ERROR-DESCRIPTION]

[COMPILER-ERROR-DESCRIPTION]
{cl}      {1} {.*([1234567890]}       {0} {2} {([1234567890]*)}       {1} {1}
{cc166}   {2} {.*[A-Za-z]:}           {0} {1} {[1234567890]*: }       {0} {2}
{gcc}     {1} {.*:[1234567890]}       {0} {2} {:[1234567890]*:}       {1} {1}
{icc8051} {1} {.*,[1234567890]}       {1} {3} {,[1234567890]* }       {1} {1}
{c51}     {1} {OF .*[CH]: }           {3} {2} {LINE [1234567890]* OF} {5} {3}
{cc}      {1} {.*, l}                 {1} {4} {line [1234567890]*:}   {5} {1}
{CC}      {1} {.*, l}                 {1} {2} {line [1234567890]*:}   {5} {1}
{aCC}     {1} {: .*,}                 {3} {2} {line [1234567890]* #}  {5} {2}
{ccpentium} {1} {.*:[1234567890]}     {0} {2} {:[1234567890]*:}       {1} {1}
{icpp}    {1} {!E .*(}                {3} {1} {(.*)}                  {1} {1}

Each line gives the description for one compiler. The eight entries have the meaning shown below (explained on the gcc entry):

  1. The name of the compiler executable
  2. The amount of lines the compiler error message takes
  3. The regular expression to determine the erroneous file
  4. The amount of characters thrown away at the beginning of the found file name
  5. The amount of characters thrown away at the end of the found file name. (In this example the colon and the numeric character do not belong to the file name but both are needed to find it.)
  6. The regular expression to determine the line number
  7. The amount of characters thrown away at the beginning of the found line. (In this example the colon at the front of the regular expression does not belong to the line number but is needed to find it).
  8. The amount of characters thrown away at the end of the found line. (In this example the colon at the end of the regular expression does not belong to the line number but is needed to find it).

Preprocessor Commands

This section takes the preprocessor commands for all the default compilers that can be set in the preferences. It has got the following contents:

Example 500 : [PREPROCESSOR-COMMANDS]

[PREPROCESSOR-COMMANDS]
{Sun GNU gcc}     {gcc -P -E -C}
{Sun Workshop cc} {cc -C -P}
{Sun Workshop CC} {CC -E}
{Microsoft}       {cl -P -EP -C -nologo}

Make Applications

The section [MAKE_APPLICATIONS] of sdttaex.par is used to specify the command line of the make application, i.e. how it will be invoked.

Example 501 : [MAKE_APPLICATIONS]

[MAKE_APPLICATIONS]
{Microsoft nmake}                                 {nmake /f}    {}        {}
{Microsoft nmake (ignore exit codes)}             {nmake /i /f} {}        {}
{Microsoft nmake (using temporary response file)} {nmake /f}    {@<<\n\t} {\n<<}
{Tasking mk166}                                   {mk166 -f}    {}        {}
{VxWorks make}                                    {make -f}     {}        {}
{UNIX make}                                       {make -f}     {}        {}

Each line is the description for one make application. The four entries (given between '{' and '}') have the following meaning.

  1. The text to identify it in the make configuration. See Make tool
  2. The name of the make application and the option used to specify the makefile.
  3. This is the start sequence for the generation of temporary response files. Empty for most make applications.
  4. This is the stop sequence for the generation of temporary response files. Empty for most make applications.

C++ Options

The C++ options specify what has to be added to the compiler's Options and the linker's Options to compile and link the SDL to C compiler's library as C++ code.

Example 502 : [C++-OPTIONS]

[C++OPTIONS]
{Sun GNU gcc} {-xc++}  {-lstdc++}
{Microsoft}   {-TP}    {}

Each line consist of the three entries

  1. compiler name
  2. compiler command line option
  3. linker command line option

Debug Options

The debug options specify what has to be added to the compiler's Options and the linker's Options to compile and link the target application including debug information.

Example 503 : [DEBUG_OPTIONS]

[DEBUG-OPTIONS]
{Sun GNU gcc}     {-g}             {-g}
{Sun Workshop cc} {-g}             {-g}
{Sun Workshop CC} {-g}             {-g}
{Microsoft}       {-D "_DEBUG"}    {/debug}
{icc12}           {-g}             {-g}

Each line consist of the three entries

  1. compiler name
  2. compiler command line option
  3. linker command line option

Compiler Dependent Defaults

The compiler dependent defaults ease the implementation of new pre-defined integrations because the values given here do not need to appear again in the .its file(s).

Example 504 : [COMPILER-DEPENDENT-DEFAULTS]

[COMPILER-DEPENDENT-DEFAULTS]
{Borland}   {bcc32} {bcc32} {tlib} {.obj} {.exe} {.lib} {%I -c -w- -DUSING_DLL -
DIC86 -o%o %s} {-e%e %L %O} {%l /C /E /P256 %O} {-I$(sctCODERDIR)} {bcc_obj} 
{Borland make (using temporary response file)}

The different entries mean the following (listed from left to right):

  1. Compiler name
  2. Compiler tool name
  3. Linker tool name
  4. Library manager name
  5. Object file extension
  6. Executable file extension
  7. Library file extension
  8. Compiler options
  9. Linker options
  10. Library Manager Options
  11. Coder include path
  12. Relative path to intermediate directory
  13. make application to use per default

Restricted Compilers

There are a few target compilers which do not support file names which are longer that 8.3 (8 character in front of '.' and a 3 character extension). To ensure that files are generated only which fit to the 8.3 requirement. This section looks as follows:

Example 505 : [8.3-COMPILERS]

[8.3-COMPILERS]
{c51}
{icpp}
{icc12}

Editor Commands

The Targeting Expert allows to use other text editor different to the build-in one. The information how to start these editors is given in the section [EDITOR-COMMANDS] shown below.

Example 506 : [EDITOR-COMMANDS]

[EDITOR-COMMANDS]
{Windows} {TextPad}            {textpad -ca -q "%f"(%l,0)}
{Windows} {UltraEdit}          {UEdit32 %f/%l/0}
{Windows} {Codewright}         {codewright %f -G%l}
{Windows} {MS DeveloperStudio} {msdev %f}
{UNIX}    {Emacs}              {emacs %f}
{UNIX}    {dtpad}              {/usr/dt/bin/dtpad %f}
{UNIX}    {nedit}              {nedit -line %l %f}

There are 2 placeholders used in the command. %f will be replaced by the name of the file to open and %l gives the line number which should be shown.

Additional Files

The sections shown in Example 507 will used to find out which files belong to external parts of the distributed SDL to C compiler libraries.

Example 507 : Additional Files Sections

[CMICRO-KERNEL-FILES]
$(sctkerneldir)/mk_main.c
$(sctkerneldir)/mk_sche.c
$(sctkerneldir)/mk_queu.c
$(sctkerneldir)/mk_outp.c
$(sctkerneldir)/mk_tim1.c
$(sctkerneldir)/sctpred.c

[CMICRO-TI-KERNEL-FILES]
$(sctkerneldir)/ti_sche.c
$(sctkerneldir)/ti_queu.c
$(sctkerneldir)/ti_outp.c
$(sctkerneldir)/ti_tim1.c
$(sctkerneldir)/ti_init.c
$(sctkerneldir)/sctpred.c

[TESTER-FILES]
$(scttesterdir)/mt_tsdl.c
$(scttesterdir)/mt_tsys.c
$(scttesterdir)/mt_cod.c
$(scttesterdir)/mt_cmd.c
$(scttesterdir)/mt_opt.c
$(scttesterdir)/mt_deb.c
$(scttesterdir)/mt_rec.c
$(scttesterdir)/mt_play.c
$(sctkerneldir)/ml_buf.c

[TI-TESTER-FILES]
$(scttesterdir)/mt_tsdl.c
$(scttesterdir)/mt_tsys.c
$(scttesterdir)/mt_cod.c
$(scttesterdir)/mt_cmd.c
$(scttesterdir)/mt_opt.c
$(scttesterdir)/mt_deb.c
$(sctkerneldir)/ml_buf.c

[CODER-FILES]
$(sctCODERDIR)/cucf_er.c
$(sctCODERDIR)/cucf_er_sdt.c
$(sctCODERDIR)/bms/bms.c
$(sctCODERDIR)/bms/bms_small.c
$(sctCODERDIR)/ems/ems.c
$(sctCODERDIR)/ems/ems_eo_sdt.c
$(sctCODERDIR)/er/ascii/ascii.c
$(sctCODERDIR)/er/ber/ber_base.c
$(sctCODERDIR)/er/ber/ber_content.c
$(sctCODERDIR)/er/ber/ber_decode.c
$(sctCODERDIR)/er/ber/ber_encode.c
$(sctCODERDIR)/er/per/per_base.c
$(sctCODERDIR)/er/per/per_content.c
$(sctCODERDIR)/er/per/per_decode.c
$(sctCODERDIR)/er/per/per_encode.c
$(sctCODERDIR)/er/mms/mms.c
$(sctCODERDIR)/vms/vms_base.c
$(sctCODERDIR)/vms/vms_check.c
$(sctCODERDIR)/vms/vms_export.c
$(sctCODERDIR)/vms/vms_print.c

[TCP-IP-FILES]
$(sctTCPIPDIR)/tcpipcomm.c

Note:

The [TESTER-FILES] and [TI-TESTER-FILES] only apply for the Cmicro SDL to C compiler.

The [TCP-IP-FILES] only applies for the Cadvanced SDL to C compiler.

If the environment variable SDTTAEXIGNOREDEFAULTFILES is set, the contents of the sections [CMICRO-KERNEL-FILES], [CMICRO-TI-KERNEL-FILES], [TESTER-FILES] and [TI-TESTER-FILES] are ignored by the Targeting Expert (the files listed are not included in the resulting Makefiles). This enables the customer to manage the complete list of files in custom (.its) files.

Host Configuration Options

The host configuration options are the default host configurations for different compilers when using the Target Tester, i.e. these options are only used for Cmicro applications. An example can be found below.

Example 508 : [HOST-CONFIGURATION-OPTIONS] (Borland compiler)

[HOST-CONFIGURATION-OPTIONS]
bcc32 "UNIT-NAME            sec"
bcc32 "UNIT-SCALE           1.0"
bcc32 "LENGTH_CHAR          1"
bcc32 "LENGTH_SHORT         2"
bcc32 "LENGTH_INT           4"
bcc32 "LENGTH_LONG          4"
bcc32 "LENGTH_FLOAT         4"
bcc32 "LENGTH_DOUBLE        8"
bcc32 "LENGTH_POINTER       4"
bcc32 "ALIGN_CHAR           8"
bcc32 "ALIGN_SHORT          8"
bcc32 "ALIGN_INT            8"
bcc32 "ALIGN_LONG           8"
bcc32 "ALIGN_FLOAT          8"
bcc32 "ALIGN_DOUBLE         8"
bcc32 "ALIGN_POINTER        8"
bcc32 "ENDIAN_CHAR          1"
bcc32 "ENDIAN_SHORT         21"
bcc32 "ENDIAN_INT           41"
bcc32 "ENDIAN_LONG          41"
bcc32 "ENDIAN_FLOAT         41"
bcc32 "ENDIAN_DOUBLE        81"
bcc32 "ENDIAN_POINTER       41"


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