Table of Contents 
Previous Chapter 36 The Master Library
This section is a reference to the macros that are used together with the generated C code from the C Code Generator (C Advanced). Here the macros are just enumerated and explained. The section is divided in a number of subsection, each treating one major aspect of the code. Within the subsections the macros are enumerated in alphabetic order.
The context in which macros are used and the sequence of generated macro calls are not discussed here. Such information can be found in the section "Structure of Generated Code" on page 2199.
Information about some of the macros (Library versions, Adaption to Compilers, and General Properties) can also be found in the section "Compilation Switches" on page 2269.
To fully understand the descriptions of the macros in this section it is also necessary to know the basic data structures used, especially for the static structures, i.e. the xIdNodes. This information can be found in the section "The Symbol Table" on page 2131.
The information about the data types used for the dynamic structure of the system, i.e. about process instances, signal, timers, and so on, are also of interest. This can be found in "The SDL Model" on page 2157.
Application.
Application without clock.
Stand alone simulator for any environment. Should be executed from OS.
Stand alone simulator with real time for any environment. Should be executed from OS.
Simulator with real time for host. Can be executed from SDT or from OS.
Stand alone simulator, with real time and env functions, for any environment. Should be executed from OS.
Simulator, with real time and env functions, for any environment. May be executed from OS or from simulator GUI.
Simulator for host. Can be executed from SDT or from OS.
Application with minimal memory requirements. Real cannot be used. No channel information
Application with minimal memory requirements. Real cannot be used. Const for all channel information
Suitable for execution of performance simulations.
cc for the ALPHA architecture.
cc for the IBM RS/6000 architecture.
ANSI cc for HP-300 and HP-400 (Motorola architecture).
ASCI cc for HP-700 (PA-RISC architecture).
cc for HP-300 and HP-400 (Motorola architecture).
cc for HP-700 (PA-RISC architecture).
PC compilers.
The IAR compiler.
GNU cc for linux.
The OASYS cross compiler.
ANSI cc for Sun OS 4.
cc for Sun OS 4.
GNU cc for Sun OS 4.
ANSI cc for Sun OS 5.
cc for Sun OS 5.
GNU cc for Sun OS 5.
C++ for SUN.
cc for ULTRIX.
cc for VAX/VMS.
Should be defined as:
#define COMMENT(P)
The macro is used to insert comments in included C code.
A random generation function. Usually rand() or random().
The max int value generated by function mentioned in GETINTRAND. Usually 2147483647 (32-bit integers).
Defined in generated code if C code generator version 2.02 was used. This is the C Code Generator in SDT 3.02.
Should concatenate token P1 and P2. Possibilities:
#define XCAT(P1,P2) P1##P2
or
#define XCAT(P1,P2) P1/**/P2
or
#define XCAT(P1,P2) XCAT2(P1)P2
#define XCAT2(P2) P2
Should be defined if there is no support for C signals. This feature is only of interest in simulations.
Should be defined if prototypes are not to be used.
Should be defined if there is no support for the select function found in Unix operating systems. This is used to implement "user defined interrupt" by typing the return key while simulating.
If this macro is defined there will be no version check between the generated code and the scttypes.h file.
Should be defined as nothing if XNOPROTO is defined, otherwise as x. The macro is used to produce function prototypes with or without parameters (ANSI-C or old style).
Defined in generated code if CBasic was used.
Defined in generated code if CAdvanced was used.
Defined in scttypes.h in a way that it possible to include the scttypes.h file several times with out any problems.
Should be defined if xint32 is int.
Should be defined if xptrint is unsigned long.
Can be used to connect an application with a monitor on a target system with SDT running on a host computer.
Detect and report user defined assertions that are not valid.
Use the clock function in sctos.c (not simulated time). Time is whatever the clock function returns.
Use the clock function in sctos.c (not simulated time). Time is zero at system start up.
Compile with code to store information about the current coverage of the SDL system. This information can also be printed in the monitor.
Compile preserving the possibility to report the current C line number during simulations.
Defines XNOPROTO, XEINTDIV, XEREALDIV, XECSOP, XEFIXOF, XERANGE, XEINDEX, XECREATE, XEDECISION, XEEXPORT, XEVIEW, XEERROR, and XASSERT.
For more information see these macros.
Detect and report if more static instances are created at start up, then the maximum number of concurrent instances.
Detect and report errors in the charstring operators.
Detect and report when there is no possible path out from a decision.
Detect and report the usage of the error term in an SDL expression.
Detect and report errors in import actions.
Detect and report integer overflow in the operator fix.
Detect and report index out of bounds in arrays.
Detect and report integer division with 0.
Call the env functions.
Insert the VarP pointer in the xSignalNode so that signals conform with their implementation in SDT 2.3.
Detect and report warnings in outputs (mainly outputs where signal is immediately discarded).
Detect and report subrange errors.
Detect and report real division with 0.0.
Detect and report errors in view actions.
Compile with the trace in source SDL graphs enabled.
Enable the possibility for an executable to communicate with ITEX via the SDT Postmaster.
If this macro is defined the main function in generated code will be renamed to the name given by the macro.
Compile with the monitor system. This macro will implicitly set up a number of other macros as well.
Compile with the MSC trace enabled.
If this macro is defined the main function in the generated code will be removed.
Make the code necessary to handle partitioning available.
Enable the possibility for an executable to communicate via the SDT Postmaster.
Use priorities on process instance sets.
Use first priorities on process instance sets and then priorities on signal instances.
Enable the possibility to communicate with a user-defined UI.
Call the xSignalLog and xProcessLog functions.
Use priorities on signal instances.
Use first priorities on signal instances and then priorities on process instance sets.
Enable the possibility to communicate with the simulator UI.
As XENV but call xInEnv at specified times (next event time is out parameter from function xInEnv).
Compile with the textual trace enabled.
The majority of the xIdNode structs can be made const by defining CONST as const. This is only possible in applications (not simulations).
This should be defined as const if XCONST is const and partitioning is not used.
This should normally be defined as const if XCONST is const. It is used to introduce const in the component declarations within the xIdNode structs.
Do not include functions to calculate the expressions in continuous signals. This saves also one function pointer in the xIdNode for the states. If this switch is defined, continuous signals cannot be used.
Do not include functions to calculate the expressions in enabling conditions. This saves also one function pointer in the xIdNode for the states. If this switch is defined, enabling conditions cannot be used.
Do not include function to compare the parameters of two timers. This saves also one function pointer in the xIdNode for the signals. If this switch is defined, timers with parameters cannot be used.
Do not include xIdNodes for remote variable definitions.
Do not include xSignalIdNodes for signals and timers.
Do not include xSignalIdNodes for start up signals.
All data and code needed to handle services are removed.
The type real and all operations on real are removed.
Defines XOPTSIGPARA, XOPTDCL, XOPTFPAR, XOPTSTRUCT, XOPTLIT, and XOPTSORT.
For more information see these macros.
Do not include xIdNodes for channels, signal routes, and gates. Information in services and processes about connections to signal routes and gates are also removed.
----------------------------------------------------------------------
Note:
If this compilation switch is defined all outputs must either be sent
TO a process or the receiver must be possible to calculate during
code generation.
----------------------------------------------------------------------
Do not include xIdNodes for variables.
Do not include xIdNodes for formal parameters.
Do not include xIdNodes for literals.
Do not include xIdNodes for signal parameters.
Do not include xIdNodes for newtypes and syntypes.
Do not include xIdNodes for struct components.
Optimize memory for process instances. All memory for a process instance can be reused, but signal sending to a stopped process, who's memory has been reused by a new process, cannot be detected. The new process will in this case receive the signal.
Should be used mainly if the MONITOR or GRTRACE switches are defined. It will make the functions and struct components for SDT references available and is also used to expand the macros XAT_FIRST_SYMBOL, XBETWEEN_SYMBOLS, XBETWEEN_SYMBOLS_PRD, XBETWEEN_STMTS, XBETWEEN_STMTS_PRD, XAFTER_VALUE_RET_PRDCALL, and XAT_LAST_SYMBOL to suitable function calls. These functions are used to interrupt a transition between symbols during simulation.
See XCASELABELS below. The SDL symbols just after an SDL procedure call have to be treated specially, as the symbol number (=case label) for these symbols are used as the restart address for the calling graph. Normally this macro should be defined. If SDL procedure calls are transformed to proper C function calls, and SDL return is translated to a C return, and nextstate in a procedure is NOT translated to a C return (i.e. the process will be hanging in the C function representing the SDL procedure) then it is not necessary to define XCASEAFTERPRDLABELS.
The function implementing the behavior of a process, procedure, or service contains one large switch statement with a case label for each SDL symbol in the graph. This switch is used to be able to restart the execution of a process, procedure, or service at any symbol. In an application most of these label can be removed (all except for those symbols that start a transition, i.e. start, input, continuous signal). The macro XCASELABELS should be defined to introduce the case labels for all SDL symbol. This means that XCASELABELS should be defined in a simulation but not in an application.
If XCONNECTPM is defined the SDL simulation will try to connect itself to the SDT postmaster. This is necessary if GR trace (XGRTRACE), communicating simulations (XPMCOMM), or communication with ITEX (XITEXCOMM) is to be used. The XCONNECTPM feature is normally only used in simulations.
Count the number of timers that are removed at a reset operation. This information is used by the textual trace system (XTRACE) to present this information. The information is really only of interest at a stop action when more then one timer might be (implicitly) reset. XCOUNTRESETS should not be defined in an application.
This macro is used to determine the number of signals sent to the environment that, during simulation, should be saved in the input port of the env process instance. Such signals can be inspected with the normal monitor commands for viewing of signals. This macro is only of interest in a simulation and has the default value 20.
Insert the data structure to represent an "error" state that can be used if no path is found out from a decision. This should normally be defined if XEDECISION is defined.
If this macro is defined xFree functions are inserted for every data type that is implemented as a pointer or that contains a pointer. Basic such types are charstring and types that the used has specified as having a xFree function (in the #ADT directive). The free functions will perform free on the appropriate allocated data areas. This macro should be defined if either XFREESIGNALFUNCS or XFREEVARS is defined.
Insert free functions for each signal, timer, or startup signal that contains a parameter of a type having a free function. These signal free functions can the be used to free allocated data within a signal.
Insert free function calls for all variables of a type with free function, just before stop or return actions. This means that free actions are performed on allocated data referred to from variables is before the object ceases to exist.
This macro is used to determine if the SDL name of an SDL object should be stored in the xIdNode for the object. This character string is used for communication with the user in for example the monitor. Normally this macro should not be used in an application. Sometime it might be useful for target debugging to define XIDNAMES, as it is then fairly easy to identify objects by just printing the SDL name from a debugger. On average this seems to cost approximately 5% more memory.
This macro should be defined if process instance numbers are to be maintained. The instance number is the number in the monitor printout Test:2, identifying the individual instances of the process instance set Test in this case. XNRINST is normally only used in a simulation.
Include the function xSDLOpError in sctsdl.c. This function is used to print run-time errors in ADT operators.
Store the value of sender also in the xPrsNode. The normal place is in the latest received signal. This is only needed in a simulation as sender might be accessed from the monitor system after the transition is completed and the signal has been returned to the pool of available memory.
Include the functions for basic Read and Write. This is needed mainly in simulations.
Allow the removal of timer signals for not-executing PIds. This is needed only in simulations to implement the monitor commands set-timer and reset-timer.
If this macro is defined then the functions xIsPath and xFindReceiver will return the path of signal routes, channels, and gates from the sender to the receiver, as out parameters. This information can then be used in the monitor system, for example, to produce signal logs. This macro should normally not be defined in an application.
The XSYMBTLINK macro is used to determine if a complete tree should be built from the xIdNodes of the system. If XSYMBTLINK is defined then all xIdNodes contains a Parent, a Suc, and a First pointer. The value of the Parent pointer is generated directly into the xIdNodes. Suc and First, however, are calculated in the yInit function by calling the xInsertIdNode function. The Suc and First pointers are needed by the monitor system, but not in an application, i.e. XSYMBTLINK should be defined in a simulation but not in an application.
This macro is used to include or remove test functions for syntype (or newtypes) with range conditions. The yTest function is used by the monitor system and by the functions to test index out of bounds in arrays and to test subranges. This means that XTESTF should be defined if the monitor is used or if XERANGE or XEINDEX is defined.
If partitioning is not used this macro should be defined as:
#define XTRACHANNELSTOENV 0
If XPARTITION is defined then the macro should be defined to the maximum number of channels that might be reconnected to the env.
Example 153
#define XTRACHANNELSTOENV 10
See also XTRACHANNELLIST below.
If partitioning is not used this macro should be defined as:
#define XTRACHANNELLIST
If XPARTITION is defined then the macro should be defined as a list of ",0" (the same number of ",0" as XTRACHANNELLIST is defined as).
Example 154
#define XTRACHANNELLIST ,0,0,0,0,0,0,0,0,0,0
All generated struct values for block, block type, and block instance structs contain this macro last in the struct. By defining this macro new components can be inserted. Note that the type xBlockIdStruct must be updated as well. Normally this macro should be empty.
Example 155
#define XBLO_EXTRAS ,0
All generated struct values for block substructure structs contain this macro last in the struct. By defining this macro new components can be inserted. Note that the type xBlockSubstIdStruct must be updated as well. Normally this macro should be empty.
Example 156
#define XBLS_EXTRAS ,0
All generated struct values for xIdNode structs contain this macro after the common components. This means that it is possible to insert new components in all xIdNodes by defining this macro. Normally this macro should be empty.
Example 157
To insert a new int component with value 0 the following definition can
be used:
#define XCOMMON_EXTRAS ,0
All generated struct values for literal structs contain this macro last in the struct. By defining this macro new components can be inserted. Note that the type xLiteralIdStruct must be updated as well. Normally this macro should be empty.
Example 158
#define XLIT_EXTRAS ,0
All generated struct values for package structs contain this macro last in the struct. By defining this macro new components can be inserted. Note that the type xPackageIdStruct must be updated as well. Normally this macro should be empty.
Example 159
#define XSYS_EXTRAS ,0
All generated struct values for procedure structs contain this macro last in the struct. By defining this macro new components can be inserted. Note that the type xPrdIdStruct must be updated as well. Normally this macro should be empty.
Example 160
#define XSYS_EXTRAS ,0
(PREFIX_PROC_NAME)
All generated struct values for process, process type, and process instance structs contain this macro last in the struct. By defining this macro new components can be inserted. Note that the type xPrsIdStruct must be updated as well.
Example 161
#define XPRS_EXTRAS(PREFIX_PROC_NAME) \
,#XCAT(PREFIX_PROC_NAME,_STACKSIZE)
All generated struct values for signal, timer, RPC_signal, startup signal structs contain this macro last in the struct. By defining this macro new components can be inserted. Note that the type xSignalIdStruct must be updated as well. Normally this macro should be empty.
Example 162
#define XSIG_EXTRAS ,0
All generated struct values for signal parameter structs contain this macro last in the struct. By defining this macro new components can be inserted. Note that the type xVarIdStruct must be updated as well (Note that variables, formal parameters, signal parameters, and struct components are all handled in xVarIdStruct.) Normally this macro should be empty.
Example 163
#define XSPA_EXTRAS ,0
All generated struct values for newtype and syntype structs contain this macro last in the struct. By defining this macro new components can be inserted. Note that the type xSortIdStruct must be updated as well. Normally this macro should be empty.
Example 164
#define XSRT_EXTRAS ,0
All generated struct values for service, service type, and service instance structs contain this macro last in the struct. By defining this macro new components can be inserted. Note that the type xSrvIdStruct must be updated as well. Normally this macro should be empty.
Example 165
#define XSRV_EXTRAS ,0
All generated struct values for state structs contain this macro last in the struct. By defining this macro new components can be inserted. Note that the type xStateIdStruct must be updated as well. Normally this macro should be empty.
Example 166
#define XSTA_EXTRAS ,0
All generated struct values for system, system type, and system instance structs contain this macro last in the struct. By defining this macro new components can be inserted. Note that the type xSystemIdStruct must be updated as well. Normally this macro should be empty.
Example 167
#define XSYS_EXTRAS ,0
This macro gives the possibility to introduce global variables declared in the beginning of the C file containing the implementation of the SDL system unit.
If extern definitions are needed for the data declared in XSYSTEMVARS, this is the place to introduce it. These definitions will be present in the .h file for the system unit (if separate generation is used).
All generated struct values for variables, formal parameters, and struct components structs contain this macro last in the struct. By defining this macro new components can be inserted. Note that the type xVarIdStruct must be updated as well (Note that signal parameters also uses the type xVarIdStruct). Normally this macro should be empty.
Example 168
#define XVAR_EXTRAS ,0
The struct components that are needed for each procedure instance. Example: state.
The struct components that are needed for each process instance. Example: state, parent, offspring, self, sender, inputport.
The struct components that are needed for each service instance. Example: state
This macro is used to declare the yVarP pointer (which is a pointer to the yVDef struct for the process) in a procedure defined outside of a process. As a global procedure never can access process local data, it is suitable to let yVarP be a pointer to a struct only containing the components defined in the macro PROCESS_VARS.
This macro is used to declare the yVarP pointer (which is a pointer to the yVDef struct for the process) in a service type defined outside of a process. As a global service type never can access process local data, it is suitable to let yVarP be a pointer to a struct only containing the components defined in the macro PROCESS_VARS.
Local variables in the PAD function for a process or service. Example: temporary variables needed for outputs, create actions.
Declaration of the ySVarP pointer used to refer to the received signal. Normally ySVarP is void *.
(VDEF_TYPE)
This macro is used within a process and in a service defined within a process. It should be expanded to a declaration of yVarP, which is the pointer that is used to access SDL variables in the process. yVarP should be of type VDEF_TYPE *, where VDEF_TYPE is the type of the yVDef struct for the process. If the pointer to the yVDef struct is passed as parameter to the PAD function, yVarP can be assigned its correct value already in the declaration.
Local variables in the function implementing the behavior of an SDL procedure.
(VDEF_TYPE)
This macro is used within a procedure defined in a process. It should be expanded to a declaration of yVarP, which is the pointer that is used to access SDL variables in the process. yVarP should be of type VDEF_TYPE *, where VDEF_TYPE is the type of the yVDef struct for the process. If the pointer to the yVDef struct is passed as parameter to the procedure function, yVarP can be assigned its correct value already in the declaration.
(VDEF_TYPE)
BEGIN_PAD is a macro that can be used to insert code that is executed in the beginning of the PAD functions. VDEF_TYPE is the yVDef type for the process.
(STARTUP_PAR_TYPE)
This macro can be used to introduce code that is executed at the beginning of the start transition. STARTUP_PAR_TYPE is the yPDef struct for the startup signal for this process.
This macro is used in the PAD function of a process that contains services. It should be expanded to a call to PAD function for the service that should execute the next transition (ActiveSrv).
(PAD)
During the start transition of a process all inherited PAD functions up to and including the PAD function containing the START symbol have to be called. The reason is to initialize all variables defined in the process. This macro is used to perform a call to the inherited PAD function (the macro parameter PAD). Usually this macro is expanded to something like:
yVarP-> RestartPAD = PAD; PAD(VarP);
followed by either a return or a goto NewTransition depending on execution model.
(PRD, THISPRD)
This macro is used in the same way as CALL_SUPER_PAD_START (see above) but for the start transition in a procedure. THISPRD is the executing procedure function, while PRD is the inherited procedure function.
(PAD)
This macro is used in the same way as CALL_SUPER_PAD_START (see above) but for the start transition in a service. PAD is the inherited PAD function.
The LOOP_LABEL macro should be used to form the loop from a nextstate operation to the next input operation necessary in the OS where OS tasks does not perform return at end of transition (most commercial OS). This macro is also suitable to handle free on received signals and the treatment of the save queue. In an OS where SDL nextstate is implemented using a C return (the Master Library for example) the LOOP_LABEL macro is usually empty.
Similar to LOOP_LABEL but used in procedures with states.
Similar to LOOP_LABEL but used in procedures without states. This macro is in many circumstances expanded to nothing.
Similar to LOOP_LABEL but used in the PAD function for a process containing services.
Should return the value of offspring.
Should return the value of parent.
Should return the value of self.
Should return the value of sender.
This macro is used in the PAD function of a process that contains services. It should be expanded in such a way that the start transitions for all of the services are executed.
This is a macro generated at the end of a function that represents the behavior of a procedure. It needs not to be expanded to anything. To define it as return (xbool)0; might remove a compiler warning that the end of a value returning function might be reached.
Should usually be expanded to the type xPrsNode.
How to reach the xPrsIdNode from a PAD function. Normally this is yVarP->NameNode.
How to reach the xPrdIdNode from a PRD function. Normally this is yPrdVarP->NameNode.
How to reach the xSrvIdNode from a PAD function. Normally this is ySrvVarP->NameNode.
(PAD)
The function heading of the PAD function given as parameter.
(PAD)
The function prototype of the PAD function given as parameter.
(PRD)
The function heading of the PRD function given as parameter.
(PRD)
The function prototype of the PRD function given as parameter.
This macro is placed in the beginning of the yInit function in the file containing code for the system. It can be expanded to variable declarations and initialization code.
This macro is used to create a env process instance, if such instance is needed in the translation model.
(SYSID)
This macro can be used to set up a global pointer to the system xSystemIdStruct. The name of this struct is passed as the macro parameter SYSID.
(PROC_NAME, PROC_NAME_STRING, PREFIX_PROC_NAME,
PAD_FUNCTION, VDEF_TYPE)
This macro can be used to introduce code for each process instance set in the system.
Parameters:
- PROC_NAME
the name of the process without prefix.
- PROC_NAME_STRING
the name of the process as a character string.
- PREFIX_PROC_NAME
the name of the process with prefix.
- PAD_FUNCTION
the PAD function for this process instance set.
- VDEF_TYPE
the yVDef struct for this process.
(PROC_NAME, PROC_NAME_STRING, PREFIX_PROC_NAME,
PAD_FUNCTION, VDEF_TYPE)
This macro can be used to introduce extern declaration (placed in the proper .h file) for each process instance set in the system.
Parameters:
- PROC_NAME
the name of the process without prefix.
- PROC_NAME_STRING
the name of the process as a character string.
- PREFIX_PROC_NAME
the name of the process with prefix.
- PAD_FUNCTION
the PAD function for this process instance set.
- VDEF_TYPE
the yVDef struct for this process.
In the yInit function the function xInsertIdNode is called for each IdNode. In an application this is not necessary, and xInsertIdNode can be defined as
#define xInsertIdNode(Node)
The function xInsertIdNode is needed if XSYMBTLINK, XCOVERAGE, or XMONITOR is defined.
This macro is placed in all yInit functions and can be expanded to local variables needed within the yInit function.
(SIG_NAME, SIG_IDNODE, RECEIVER, SIG_PAR_TYPE)
These macros are used to allocate a data area for a signal to be sent. ALLOC_SIGNAL is used if the signal has no parameters, while ALLOC_SIGNAL_PAR is used if the signal has parameters. The resulting data area should be reference by the variable mentioned by the macro OUTSIGNAL_DATA_PTR (see below).
Parameters:
- SIG_NAME
the name of the signal without prefix.
- SIG_IDNODE
the xSignalIdNode of the signal.
- RECEIVER
the receiver given in the TO clause, or calculated. In a NO_TO output, RECEIVER is xNotDefPId.
- SIG_PAR_TYPE
the yPDef type of the signal. If the signal has no parameters this macro parameter is XSIGNALHEADERTYPE (see below).
This macro should be expanded to the identification of the currently received signal. It is used to distinguish between signals when several signal is enumerated in the same input symbol.
This should be the pointer refering to be signal data area while building the signal during an output. It should be assigned its value in ALLOC_SIGNAL or ALLOC_SIGNAL_PAR, and will then be used during assignment of signal parameters and in the SDL_2OUTPUT macro just below.
(PRIO, VIA, SIG_NAME, SIG_IDNODE, RECEIVER,
SIG_PAR_SIZE, SIG_NAME_STRING)
These six macros are used to send the signal created in ALLOC_SIGNAL or ALLOC_SIGNAL_PAR. The SDL_ALT versions of the macros are used if the directive /*#ALT*/ has been given in the output. The version without suffix is used for an output TO, while the suffix _COMPUTED_TO is used for an output without to but it was possible to compute the receiver during code generation time. The suffix _NO_TO indicates an output without to, where the receiver cannot be calculated during code generation time.
Parameters:
- PRIO
the priority of the signal specified in a #PRIO directive.
- VIA
the via list given in the output.
- SIG_NAME
the name of the signal without prefix
- SIG_IDNODE
the xSignalIdNode for the signal.
- RECEIVER
the receiver given in the TO clause, or calculated. In a NO_TO output, RECEIVER is xNotDefPId.
- SIG_PAR_SIZE
the size of the yPDef struct of the signal. If signal without parameters SIG_PAR_SIZE is 0.
- SIG_NAME_STRING
the name of the signal as a character string.
In an output TO THIS in SDL, the RECEIVER parameter in the ALLOC_SIGNAL and SDL_2OUTPUT macros discussed above will become SDL_THIS.
(P)
This macro makes it possible to store a signal code (signal number) in the xSignalIdNode for a signal. The macro parameter P is the signal name without prefix.
This macro is inserted after the ALLOC_SIGNAL macro and the assignment of parameter values to the signal. It can be used to test if the alloc was successful or not.
This macro is inserted after the SDL_2OUTPUT macro.
(SIG_NAME, SIG_IDNODE)
This macro should be expanded to an identification of the signal given as parameter. Normally the identification is either the xSignalIdNode for the signal or an int value. If the id is an int value it is suitable to insert defines of type #define signal_name number.
Parameters:
- SIG_NAME
the name of the signal without parameters
- SIG_IDNODE
the xSignalIdNode for the signal.
The struct components that are needed for each signal instance. Example: sender, receiver, signal type.
(PROC_NAME, PROC_IDNODE)
This macro is used as RECEIVER in the ALLOC_SIGNAL and SDL_2OUTPUT macros if the signal is sent to a process instance set in SDL.
Parameters:
- PROC_NAME
the name of the receiving process without prefix.
- PROC_IDNODE
the xPrsIdNode of the receiving process.
(SIG_NAME, SIG_IDNODE, RECEIVER, SIG_PAR_TYPE)
These macros are used as alternative for the ALLOC_SIGNAL macros (see these macros above) if the directive #TRANSFER if given in the output.
- SIG_NAME
the name of the signal without prefix.
- SIG_IDNODE
the xSignalIdNode of the signal.
- RECEIVER
the receiver given in the TO clause, or calculated. In a NO_TO output, RECEIVER is xNotDefPId.
- SIG_PAR_TYPE
the yPDef type of the signal. If the signal has no parameters this macro parameter is XSIGNALHEADERTYPE (see below).
The representation for a none signal.
This macro is used to indicate a yPDef struct for a signal without parameters. Such a signal has no generated yPDef struct. It is suitable to let XSIGNALHEADERTYPE be the name of a struct just containing the components in SIGNAL_VARS.
Depending on the representation of the signal type that is used (xSignalIdNode or int) this macro should either be xSignalIdNode or int.
(SIG_NAME, SIG_IDNODE, RECEIVER, SIG_PAR_TYPE)
These macros are used to allocate the Reply signal in the signal exchange in an RPC. The suffix _PAR is used if the reply signal contains parameters. The suffix _PRD is used if the implicit RPC transition is part of a procedure.
Parameters:
- SIG_NAME
the reply signal name without prefix.
- SIG_IDNODE
the xSignalIdNode for the reply signal.
- RECEIVER
the receiver of the reply signal. The macro XRPC_SENDER_IN_ALLOC or XRPC_SENDER_IN_ALLOC_PRD are used as actual parameter. The suffix _PRD is used if the implicit RPC transition is part of a procedure.
- SIG_PAR_TYPE
the yPDef type for the reply signal. If the reply signal does not contain any parameters the macro name XSIGNALHEADERTYPE is generated as actual parameter.
This should be a reference to the data area for the reply signal that is allocated in the ALLOC_REPLY_SIGNAL macro. The suffix _PRD is used if the implicit RPC transition is part of a procedure.
(PREPLY_IDNODE, PREPLY_NAME, RESTARTADDR)
These macros are used to implement the implicit nextstate operation in the caller of an RPC. The suffix _PRD is used if the implicit RPC transition is part of a procedure.
Parameters:
- PREPLY_IDNODE
the xSignalIdNode for the reply signal.
- PREPLY_NAME
the name without prefix for the reply signal.
- RESTARTADDR
the restart address (symbol number) for the implicit input of the reply signal.
(PRIO, VIA, SIG_NAME, SIG_IDNODE, RECEIVER,
SIG_PAR_SIZE, SIG_NAME_STRING)
Send the call signal of an RPC.
Parameters:
- PRIO
priority of signal.
- VIA
the via list, which in this case always is (xIdNode *)0, i.e. no via list.
- SIG_NAME
the RPC call signal name without prefix.
- SIG_IDNODE
the xSignalIdNode for the RPC call signal.
- RECEIVER
the receiver of the call signal. This is either expressed as an ordinary TO-expression or using the macro XGETEXPORTINGPRS (see below) in case of no explicit receiver specified in the call.
- SIG_PAR_SIZE
the size of the yPDef struct for the call signal. If the call signal has no parameters this parameter will be 0.
- SIG_NAME_STRING
the name of the RPC call signal as a character string.
(PRIO, VIA, SIG_NAME, SIG_IDNODE, RECEIVER,
SIG_PAR_SIZE, SIG_NAME_STRING)
These macros are used to send the RPC reply signal. The suffix _PRD is used if the implicit RPC transition is part of a procedure.
Parameters:
- PRIO
priority of signal.
- VIA
the via list, which in this case always is (xIdNode *)0, i.e. no via list.
- SIG_NAME
the RPC reply signal name without prefix.
- SIG_IDNODE
the xSignalIdNode for the RPC reply signal.
- RECEIVER
the receiver of the reply signal. This is expressed using the macro XRPC_SENDER_IN_OUTPUT or XRPC_SENDER_IN_OUTPUT_PRD.
- SIG_PAR_SIZE
the size of the yPDef struct for the reply signal. If the reply signal has no parameters this parameter will be 0.
- SIG_NAME_STRING
the name of the RPC reply signal as a character string.
(REMOTENODE)
This macro should be expanded to an expression that given the remote procedure given as actual macro parameter (more exactly the IdNode for the remote procedure), returns one possible exporter of this remote procedure. Usually this macro is expanded to a call of the library function xGetExportingPrs.
Macros that can be used for special processing needed to receive an RPC reply signal. The macros are usually expanded to nothing.
These macros can be used to save the sender of a received RPC call signal, for further use when the reply signal is to be sent. The suffix _PRD is used if the implicit RPC transition is part of a procedure.
These macros are used to obtain the receiver of the reply signal (from the sender of the call signal) in the ALLOC_REPLY_SIGNAL macros. The suffix _PRD is used if the implicit RPC transition is part of a procedure.
These macros are used to obtain the receiver of the reply signal (from the sender of the call signal) in the SDL_2OUTPUT_RPC_REPLY macros. The suffix _PRD is used if the implicit RPC transition is part of a procedure.
The state number used for a RPC wait state. XRPC_WAIT_STATE is usually defined as -3.
(REMOTENODE, EXPORTER, IS_DEF_EXPORTER)
This macro should be expanded to an expression that returns the address of the exported variable. Usually the function xGetExportAddr is called.
Parameters:
- REMOTENODE
the IdNode for the remote variable.
- EXPORTER
the value of the optional PId expression. If no PId expression is given this parameter is SDL_NULL.
- IS_DEF_EXPORTER
has the value (xbool)1 if a PId expression was found in the import statement, otherwise it is (xbool)0.
(PID_EXPR, HAS_EXPR, VAR_NAME_STRING, REVEALED_LIST,
SORT_SIZE)
This macro should be expanded to an expression that returns the address of the viewed variable. Usually the function SDL_View is called.
Parameters:
- PID_EXPR
the value of the optional PId expression. If no PId expression is given this parameter is SDL_NULL.
- HAS_EXPR
has the value (xbool)1 if a PId expression was found in the view statement, otherwise it is (xbool)0.
- VAR_NAME_STRING
the name of the viewed variable as a character string.
- REVEALED_LIST
the list of the revealed variables.
- SORT_SIZE
the size of the sort of the revealed variable.
(PROC_NAME, STARTUP_IDNODE, STARTUP_PAR_TYPE)
Allocate the data area for a startup signal and let the pointer mentioned in the macro STARTUP_DATA_PTR refer to this data area. The suffix _PAR is used if the startup signal contains parameters.
Parameters:
- PROC_NAME
the name without prefix for the created process.
- STARTUP_IDNODE
the xSignalIdNode for the startup signal of the created process.
- STARTUP_PAR_TYPE
the yPDef for the startup signal of the created process.
Allocate the data area for a startup signal and let the pointer mentioned in the macro STARTUP_DATA_PTR refer to this data area. This macro is used in a create THIS operation.
(PROC_NAME, PREFIX_PROC_NAME, PROC_IDNODE,
PROC_NAME_STRING, MAX_NO_OF_INST, STATIC_INST,
VDEF_TYPE, PRIO, PAD_FUNCTION)
This macro will be call once for each process instance set in the yInit function. It should be used to initiated common features for all instances of a process instance set.
Parameters:
- PROC_NAME
the name without prefix for the process instance set.
- PREFIX_PROC_NAME
the name with prefix for the process instance set.
- PROC_IDNODE
the xPrsIdNode for the process instance set.
- PROC_NAME_STRING
the name as character string for the process instance set.
- MAX_NO_OF_INST
the maximum number of instances of this process instance set.
- STATIC_INST
the number of static instances of this process instance set.
- VDEF_TYPE
the yVDef type for this process instance set.
- PRIO
the priority for process instance set.
- PAD_FUNCTION
the PAD for this process instance set.
(PROC_NAME, PROC_IDNODE, PROC_NAME_STRING)
This macro is used to create (a create action) a process instance.
Parameters:
- PROC_NAME
the name without prefix for the process instance set.
- PROC_IDNODE
the xPrsIdNode for the process instance set.
- PROC_NAME_STRING
he name as character string for the process instance set.
This macro is used to implement create this.
(PROC_NAME, PREFIX_PROC_NAME, PROC_IDNODE,
PROC_NAME_STRING, STARTUP_IDNODE, STARTUP_PAR_TYPE,
VDEF_TYPE, PRIO, PAD_FUNCTION, BLOCK_INST_NUMBER)
This macro is called in the yInit function once for each static process instances that should be created of a process instance set.
Parameters:
- PROC_NAME
the name without prefix for the process instance set.
- PREFIX_PROC_NAME
the name with prefix for the process instance set.
- PROC_IDNODE
the xPrsIdNode for the process instance set.
- PROC_NAME_STRING
the name as character string for the process instance set.
- STARTUP_IDNODE
the xSignalIdNode for the startup signal for the process instance set.
- STARTUP_PAR_TYPE
the yPDef type for the startup signal for the process instance set.
- VDEF_TYPE
the yVDef type for the process instance set.
- PRIO
the priority for the process instance set.
- PAD_FUNCTION
the PAD function for the process instance set.
- BLOCK_INST_NUMBER
if this process instance set is part if a block instance set then this macro is the block instance number for the block instance set that this process belongs to. Otherwise this macro parameter is 1.
This macro is used to implement the SDL operation stop (both in processes and in services).
This macro is inserted after the ALLOC_STARTUP macro and the assignment of parameter values to the signal. It can be used to test if the alloc was successful or not.
This macro is inserted after the SDL_CREATE macro.
This macro should be expanded to a temporary variable used to store a reference to the startup signal data area. It should be assigned in the ALLOC_STARTUP macro and will be used to assign the actual signal parameters (the fpar values) to the startup signal.
This macro can be used to insert additional general components in the startup signals. In all startup signal yPDef structs SIGNAL_VARS will be followed by STARTUP_VARS.
(TIMER_NAME, TIMER_IDNODE, TIMER_PAR_TYPE)
Allocate a data area for the timer signal with parameters.
Parameters:
- TIMER_NAME
the name without prefix of the timer.
- TIMER_IDNODE
the xSignalIdNode for the timer.
- TIMER_PAR_TYPE
the yPDef for the timer.
(TIMER_VAR)
There will be one application of this macro in the yVDef type for the process for each timer declaration the process contains. These declarations can be used to introduce components (timer variables) in the yVDef struct to track timers. The parameter TIMER_VAR is a suitable name for such a variable. The suffix _PARA is used if the timer has parameters.
(TIMER_VAR)
These macros will be inserted in start transitions, during initialization of process variables. This makes it possible to initialize the timer variables that might be inserted in the DEF_TIMER_VAR macro. The parameter TIMER_VAR is the name for such a variable. The suffix _PARA is used if the timer has parameters.
(TIMER_VAR)
These macros will be inserted at an input operation on a timer signal. This makes it possible to update the timer variables that might be inserted in the DEF_TIMER_VAR macro. The parameter TIMER_VAR is the name for such a variable. The suffix _PARA is used if the timer has parameters. Note that if a timer signal is received in an input * statement, no INPUT_TIMER_VAR will be present in this case.
(TIMER_VAR)
These macros will be inserted at a stop. This makes it possible to perform cleaning up of the timer variables that might be inserted in the DEF_TIMER_VAR macro. The parameter TIMER_VAR is the name for such a variable. The suffix _PARA is used if the timer has parameters.
(TIMER_NAME, TIMER_IDNODE, TIMER_VAR)
This macro is used to implement the SDL operation active on a timer. Note that active on timers with parameters is not implemented in the C Code Generator.
Parameters:
- TIMER_NAME
the name without prefix of the timer.
- TIMER_IDNODE
the xSignalIdNode for the timer.
- TIMER_VAR
the timer variable that might be inserted in the macro DEF_TIMER_VAR.
This is the implementation of now in SDL.
(TIMER_NAME, TIMER_IDNODE, TIMER_VAR,
TIMER_NAME_STRING)
This macro is used to implement the SDL operation reset on a timer without parameters.
Parameters:
- TIMER_NAME
the name without prefix of the timer.
- TIMER_IDNODE
the xSignalIdNode for the timer.
- TIMER_VAR
the timer variable that might be inserted in the macro DEF_TIMER_VAR.
- TIMER_NAME_STRING
the name of the timer as a character string.
(EQ_FUNC, TIMER_VAR, TIMER_NAME_STRING)
This macro is used to implement the SDL operation reset on a timer with parameters. Before this macro a timer signal with the timer parameters in the reset operation is created.
Parameters:
- EQ_FUNC
the name of the generated equal function that can test if two timer instance are equal or not.
- TIMER_VAR
the timer variable that might be inserted in the macro DEF_TIMER_VAR.
- TIMER_NAME_STRING
the name of the timer as a character string.
(TIME_EXPR, TIMER_NAME, TIMER_IDNODE, TIMER_VAR,
TIMER_NAME_STRING)
(TIME_EXPR, TIMER_NAME, TIMER_IDNODE,
TIMER_PAR_TYPE, EQ_FUNC, TIMER_VAR,
TIMER_NAME_STRING)
(TIME_EXPR, DUR_EXPR, TIMER_NAME, TIMER_IDNODE,
TIMER_VAR, TIMER_NAME_STRING)
(TIME_EXPR, DUR_EXPR, TIMER_NAME, TIMER_IDNODE,
TIMER_PAR_TYPE, EQ_FUNC, TIMER_VAR,
TIMER_NAME_STRING)
(TIME_EXPR, DUR_EXPR, TIMER_NAME, TIMER_IDNODE,
TIMER_VAR, TIMER_NAME_STRING)
(TIME_EXPR, DUR_EXPR, TIMER_NAME, TIMER_IDNODE,
TIMER_PAR_TYPE, EQ_FUNC, TIMER_VAR,
TIMER_NAME_STRING)
These six SDL_SET macros are used to implement the SDL operation set on a timer. The suffix _WITH_PARA indicates the set of a timer with parameters. In this case the SDL_SET macro is preceded by an ALLOC_TIMER_SIGNAL_PAR macro call, plus the assignment of the timer parameters. The suffix _DUR is used if the time value in the set operation is expressed as:
now + expression
In this case both the time value and the duration value (the expression above) is available as macro parameter. The suffix _TICKS is used if the time value in the set operation is expressed as:
now + TICKS(...)
where TICKS is an operator returning a duration value. In this case both the time value and the duration value (the TICKS expression above) is available as macro parameter.
Parameters:
- TIME_EXPR
the time expression.
- DUR_EXPR
the duration expression (only in _DUR and _TICKS).
- TIMER_NAME
the timer name without prefix.
- TIMER_IDNODE
the xSignalIdNode for the timer.
- TIMER_PAR_TYPE
the yPDef struct for the timer (only in _WITH_PARA)
- EQ_FUNC
the function that can be used to test if two timers have the same parameter values (only in _WITH_PARA).
- TIMER_VAR
the name of the timer variable that might be introduced in the macro DEF_TIMER_VAR.
- TIMER_NAME_STRING
the name of the timer as a character string.
This should be the pointer refering to be timer data area while building
the timer. It should be assigned its value in ALLOC_TIMER_SIGNAL_PAR, and will then be used during assignment of signal parameters and in the SDL_SET macro
This macro is inserted after the ALLOC_TIMER_SIGNAL_PAR macro and the assignment of parameter values to the timer. It can be used to test if the alloc was successful or not.
This macro is inserted after the SDL_SET macro.
The struct components that are needed for each timer instance. Example: sender, receiver, timer type.
As timers are signals as well, after the timer signal has been sent, TIMER_VARS has to be identical to SIGNAL_VARS, except that new component may be add last in TIMER_VARS.
This macro is used to indicate a yPDef struct for a timer without parameters. Such a timer has no generated yPDef struct. It is suitable to let XTIMERHEADERTYPE be the name of a struct just containing the components in TIMER_VARS.
(PROC_NAME, PROC_IDNODE, VAR_SIZE)
Allocate a data area (yVDef) for the called procedure.
Parameters:
- PROC_NAME
the name of procedure with prefix.
- PROC_IDNODE
the xPrdIdNode of the called procedure
- VAR_SIZE
the size of the yVDef struct for the procedure.
Allocate a data area (yVDef) for a procedure when call THIS is used.
(PROC_IDNODE)
Allocate a data area (yVDef) for the called procedure when calling a virtual procedure. The PROC_IDNODE parameter is the xPrdIdNode for the call procedure.
(PROC_NAME, PROC_IDNODE, LEVELS, RESTARTADDR)
These macros are used to implement a call operation in SDL. The yVDef struct has been allocated earlier (in ALLOC_PROCEDURE) and the actual parameters have been assigned to components in this struct. The suffix _IN_PRD indicates that the procedure call is made in a procedure.
Parameters:
- PROC_NAME
the name of procedure with prefix, which is the same as the name of the C function representing the behavior of the procedure.
- PROC_IDNODE
the xPrdIdNode of the called procedure.
- LEVELS
the scope level between the caller and the called procedure.
- RESTARTADDR
the restart address the symbol number for the symbol after the procedure call.
These two macros are only of interest if the PAD functions are left via a return at the end of transitions. In that case any outstanding procedure must be restarted when the process becomes active again.
(RESTARTADDR)
This macro is used to implement a call THIS operation in SDL. RESTARTADDR is the restart address the symbol number for the symbol after the procedure call.
(PROC_IDNODE, LEVELS, RESTARTADDR)
These macros are used to implement a call operation on a virtual procedure in SDL. The yVDef struct has been allocated earlier (in ALLOC_VIRT_PROCEDURE) and the actual parameters have been assigned to components in this struct. The suffix _IN_PRD indicates that the procedure call is made in a procedure.
Parameters:
- PROC_IDNODE
the xPrdIdNode of the called procedure.
- LEVELS
the scope level between the caller and the called procedure.
- RESTARTADDR
the restart address the symbol number for the symbol after the procedure call.
This macro is inserted after the ALLOC_PROCEDURE macro and the assignment of parameter values to the procedure parameters. It can be used to test if the alloc was successful or not.
This macro is inserted after the CALL_PROCEDURE macro.
This macro should be expanded to a temporary variable used to store a reference to the procedure data area. It should be assigned in the ALLOC_PROCEDURE macro and will be used to assign the actual procedure parameters (the fpar values).
The implementation of return in SDL.
If this macro is defined then all the code discussed for the macro CALL_PROCEDURE_STARTUP (just above) is removed.
---------------------------------------------------------------------
Note:
Implicit nextstate operations in RPC calls are treated in the RPC sec
tion.
---------------------------------------------------------------------
The state number for an asterisk state. ASTERISK_STATE is usually defined as -1.
The state number used for the error state. ERROR_STATE is usually defined as -2.
The state number for the start state. START_STATE should be defined as 0.
The state number for the start state in a procedure. START_STATE should be defined as 0.
(STATE_NAME, PREFIX_STATE_NAME, STATE_NAME_STRING)
Nextstate operation (in process or service) of the given state.
Parameters:
- STATE_NAME
the name without prefix of the state.
- PREFIX_STATE_NAME
the name with prefix for the state. This identifier is defined as a suitable state number in generated code and is usually used as the representation of the state.
- STATE_NAME_STRING
the name of the state as a character string.
Dash nextstate operation in a process.
Dash nextstate operation in a service.
(STATE_NAME, PREFIX_STATE_NAME, STATE_NAME_STRING)
Nextstate operation (in procedure) of the given state.
Parameters:
- STATE_NAME
the representation of the state.
- PREFIX_STATE_NAME
the name with prefix for the state. This identifier is defined as a suitable state number in generated code and is usually used as the representation of the state.
- STATE_NAME_STRING
the name of the state as a character string.
Dash nextstate operation in a procedure.
An any decision with two paths are generated according to the following structure:
BEGIN_ANY_DECISION(2)
DEF_ANY_PATH(1, 2)
DEF_ANY_PATH(2, 0)
END_DEFS_ANY_PATH(2)
BEGIN_FIRST_ANY_PATH(1)
statements
END_ANY_PATH
BEGIN_ANY_PATH(2)
statements
END_ANY_PATH
END_ANY_DECISION
(NO_OF_PATHS)
Start of the any decision. NO_OF_PATHS is the number of paths in the decision.
(PATH_NO)
A path (not the first) in implementation part of the any decision. PATH_NO is the path number.
(PATH_NO)
The first possible path in implementation part of the any decision. PATH_NO is the path number.
(PATH_NO, SYMBOLNUMBER)
Definition of a path in the decision.
Parameters:
- PATH_NO
the path number.
- SYMBOLNUMBER
the symbol number for the first symbol in this path.
The end of the any decision.
End of one of the paths in the implementation section.
(NO_OF_PATHS)
End of the definition part of the any decision. NO_OF_PATHS is the number of paths in the decision.
The implementation of informal decisions are similar to any decisions.
(PATH_NO)
The first possible path in implementation part of the informal decision. PATH_NO is the path number.
(NO_OF_PATHS, QUESTION)
Start of the any decision.
Parameters:
- NO_OF_PATHS
the number of paths in the decision.
- QUESTION
the question charstring.
(PATH_NO)
The else path in implementation part of the any decision. PATH_NO is the path number.
(PATH_NO)
A path in implementation part of the any decision. PATH_NO is the path number.
(PATH_NO, ANSWER, SYMBOLNUMBER)
Definition of a path in the decision.
Parameters:
- PATH_NO
the path number.
- ANSWER
the answer string.
- SYMBOLNUMBER
the symbol number for the first symbol in this path.
(PATH_NO, SYMBOLNUMBER)
Definition of the else path in the decision.
Parameters:
- PATH_NO
the path number.
- SYMBOLNUMBER
the symbol number for the first symbol in this path.
(NO_OF_PATHS)
End of the definition part of the informal decision. NO_OF_PATHS is the number of paths in the decision.
End of the else paths in the implementation section.
The end of the informal decision.
End of one of the paths in the implementation section.
(SYMB_NO)
A macro generated between the implementation of a value returning procedure call (implicit call symbol) and the symbol containing the value returning procedure call. SYMB_NO is the symbol number of the symbol containing the value returning procedure call.
(SYMB_NO)
A macro generated between an input or start symbol and the first symbol in the transition. SYMB_NO is the symbol number of the first symbol in the transition.
A macro generated immediately before a nextstate or stop operation.
(SYMB_NO, C_LINE_NO)
A macro generated between statements in a task. The suffix _PRD indicates that these statements are part of a procedure.
Parameters:
- SYMB_NO
the symbol number of the next statement.
- C_LINE_NO
line number in C of this statement.
(SYMB_NO, C_LINE_NO)
A macro generated between symbols in a transition. The suffix _PRD indicates that these symbols are part of a procedure.
Parameters:
- SYMB_NO
the symbol number of the next symbol.
- C_LINE_NO
line number in C of this statement.
(LABEL_NAME)
This macro gives the possibility to insert label at the beginning of transitions. Such labels can be useful during debugging. The LABEL_NAME parameter is a concatenation of state name and the signal name. the * in state *; and input *; will cause the name ASTERISK to appear.
(SIG_NAME_STRING)
This macro is generated at input statements and can, for example, be used to generated trace information about inputs. The SIG_NAME_STRING parameter is the name of the signal in the input.
(PRS_NAME_STRING)
This macro is generated among the declarations of variables in the PAD function for a process. It can, for example, be used to declare a char * variable containing the name of the process. Such a variable can be useful during debugging. The PRS_NAME_STRING parameter is the name of the process as a character string.
(PRD_NAME_STRING)
This macro is generated among the declarations of variables in the PRD function for a procedure. It can, for example, be used to declare a char* variable containing the name of the procedure. Such a variable can be useful during debugging. The PRD_NAME_STRING parameter is the name of the procedure as a character string.
The following sequence of macros should be inserted. Most of them concern removal of struct components (in IdNodes) that are not used due to the combination of other switches used.
#define NIL 0
#define XSYSD xSysD.
#if defined(XPRSPRIO) || defined(XSIGPRSPRIO) ||
defined(XPRSSIGPRIO)
#define xPrsPrioPar(p) , p
#else
#define xPrsPrioPar(p)
#endif
#if defined(XSIGPRIO) || defined(XSIGPRSPRIO) ||
defined(XPRSSIGPRIO)
#define xSigPrioPar(p) , p
#define xSigPrioParS(p) p;
#else
#define xSigPrioPar(p)
#define xSigPrioParS(p)
#endif
#ifdef XTESTF
#define xTestF(p) , p
#else
#define xTestF(p)
#endif
#ifdef XREADANDWRITEF
#define xRaWF(p) , p
#else
#define xRaWF(p)
#endif
#ifdef XFREEFUNCS
#define xFreF(p) , p
#else
#define xFreF(p)
#endif
#ifdef XFREESIGNALFUNCS
#define xFreS(p) , p
#else
#define xFreS(p)
#endif
#define xAssF(p)
#define xEqF(p)
#ifdef XIDNAMES
#define xIdNames(p) , p
#else
#define xIdNames(p)
#endif
#ifndef XOPTCHAN
#define xOptChan(p) , p
#else
#define xOptChan(p)
#endif
#ifdef XBREAKBEFORE
#define xBreakB(p) , p
#else
#define xBreakB(p)
#endif
#ifdef XGRTRACE
#define xGRTrace(p) , p
#else
#define xGRTrace(p)
#endif
#ifdef XMSCE
#define xMSCETrace(p) , p
#else
#define xMSCETrace(p)
#endif
#ifdef XTRACE
#define xTrace(p) , p
#else
#define xTrace(p)
#endif
#ifdef XCOVERAGE
#define xCoverage(p) , p
#else
#define xCoverage(p)
#endif
#ifdef XNRINST
#define xNrInst(p) , p
#else
#define xNrInst(p)
#endif
#ifdef XSYMBTLINK
#define xSymbTLink(p1, p2) , p1, p2
#else
#define xSymbTLink(p1, p2)
#endif
#ifdef XEVIEW
#define xeView(p) p,
#define xeViewS(p) p;
#else
#define xeView(p)
#define xeViewS(p)
#endif
#ifdef XCTRACE
#define xCTrace(p) p,
#define xCTraceS(p) p;
#else
#define xCTrace(p)
#define xCTraceS(p)
#endif
#ifndef XNOUSEOFSERVICE
#define xService(p) , p
#else
#define xService(p)
#endif
#if !defined(XPMCOMM) && !defined(XENV)
#define xGlobalNodeNumber() 1
#endif
#define xSizeOfPathStack 50
#ifndef xOffsetOf
#define xOffsetOf(type, field) \
((xptrint) &((type *) 0)->field)
#endif
#define xToLower(C) \
((C >= `A' && C <= `Z') ? \
(char)((int)C - (int)'A' + (int)'a') : C)
#ifndef xDefaultPrioProcess
#define xDefaultPrioProcess 100
#endif
#ifndef xDefaultPrioSignal
#define xDefaultPrioSignal 100
#endif
#ifndef xDefaultPrioTimerSignal
#define xDefaultPrioTimerSignal 100
#endif
#ifndef xDefaultPrioContSignal
#define xDefaultPrioContSignal 100
#endif
#ifndef xDefaultPrioCreate
#define xDefaultPrioCreate 100
#endif
#define xbool int
#ifndef MAX_READ_LENGTH
#define MAX_READ_LENGTH 5000
/* max length of input line */
#endif
#ifndef MAX_WRI_LENGTH
#define MAX_WRI_LENGTH 5000
#endif
#ifndef MAX_M_WRI_LENGTH
#define MAX_M_WRI_LENGTH 2*MAX_WRI_LENGTH
#endif
#define XASS 0
#define XASSMAKE 1
#define XASS2MAKE 2
The xDefaultPrio macros above should, of course, be defined to the suitable default values.
Other macros that should be defined are.
a null value for the type PId.
which is used as RECEIVER parameter in the SDL_2OUTPUT macros. Please see also the section were signals are treated.
Table of Contents 
Next Chapter