![]() |
![]() |
![]() |
![]() |
![]() |
List of All Compilation Switches
Introduction
This section is a reference to the macros that are used together with the generated C code from the Cadvanced/Cbasic SDL to C Compiler. 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.
Information about some of the macros (Library Version Macros, Compiler Definition Section Macros, and General Properties) can also be found in the section Compilation Switches.
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.
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.
Library Version Macros
SCTAPPLCLENV
SCTAPPLENV
SCTDEB
Stand-alone simulator for any environment. Should be executed from OS.
SCTDEBCL
Stand-alone simulator with real time for any environment. Should be executed from OS.
SCTDEBCLCOM
Simulator with real time for host. Can be executed from the SDL Suite or from OS.
SCTDEBCLENV
Stand-alone simulator, with real time and env functions, for any environment. Should be executed from OS.
SCTDEBCLENVCOM
Simulator, with real time and env functions, for any environment. May be executed from OS or from simulator GUI.
SCTDEBCOM
Simulator for host. Can be executed from the SDL Suite or from OS.
SCTOPT1APPLCLENV
Application with minimal memory requirements. Real cannot be used. No channel information
SCTOPT2APPLCLENV
Application with minimal memory requirements. Real cannot be used. Const for all channel information.
SCTPERFSIM
Suitable for execution of performance simulations.
Compiler Definition Section Macros
SCT_POSIX
Set up for UNIX/POSIX like compilers/systems.
SCT_WINDOWS
Set up for compilers on Windows
Some Configuration Macros
COMMENT(P)
#define COMMENT(P)The macro is used to insert comments in included C code. See Example 377.
GETINTRAND
A random generation function. Usually rand() or random().
GETINTRAND_MAX
The max int value generated by function mentioned in GETINTRAND. Usually RAND_MAX or 2147483647 (32-bit integers).
SCT_VERSION_6_3
Defined in generated code if the Cadvanced/Cbasic SDL to C Compiler version 6.3 was used.
XCAT(P1,P2)
Should concatenate token P1 and P2. Possibilities:
#define XCAT(P1,P2) P1##P2#define XCAT(P1,P2) P1/**/P2#define XCAT(P1,P2) XCAT2(P1)P2#define XCAT2(P2) P2XMULTIBYTE_SUPPORT
Should be set if the compiler supports multi byte characters.
XNOSELECT
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.
XNO_VERSION_CHECK
If this macro is defined there will be no version check between the generated code and the scttypes.h file.
XSCT_CBASIC
Defined in generated code if Cbasic was used.
XSCT_CADVANCED
Defined in generated code if Cadvanced was used.
X_SCTTYPES_H
Defined in scttypes.h in a way that it possible to include the scttypes.h file several times without any problems.
X_XINT32_INT
Should be defined if xint32 is int.
X_XPTRINT_LONG
Should be defined if xptrint is unsigned long.
General Properties
TARGETSIM
Can be used to connect an application with a monitor on a target system with the SDL Suite running on a host computer.
XASSERT
Detect and report user defined assertions that are not valid.
XCALENDARCLOCK
Use the clock function in sctos.c (not simulated time). Time is whatever the clock function returns.
XCLOCK
Use the clock function in sctos.c (not simulated time). Time is zero at system start up.
XCOVERAGE
Compile with code to store information about the current coverage of the SDL system. This information can also be printed in the monitor.
XCTRACE
Compile preserving the possibility to report the current C line number during simulations.
XEALL
Defines XEOUTPUT, XEINTDIV, XEREALDIV, XECSOP, XEFIXOF, XERANGE, XEINDEX, XECREATE, XEDECISION, XEEXPORT, XEVIEW, XEERROR, XEUNION, XECHOICE, XEOPTIONAL, XEREF, XEOWN, and XASSERT.
For more information, see these macros.
XECHOICE
Detect and report attempts to access non-active components in Choice variables.
XECREATE
Detect and report if more static instances are created at start up, than the maximum number of concurrent instances.
XECSOP
Detect and report errors in ADT operators.
XEDECISION
Detect and report when there is no possible path out from a decision.
XEERROR
Detect and report the usage of the error term in an SDL expression.
XEEXPORT
Detect and report errors in import actions.
XEFIXOF
Detect and report integer overflow in the operator fix.
XEINDEX
Detect and report index out of bounds in arrays.
XEINTDIV
Detect and report integer division with 0.
XENV
XENV_CONFORM_2_3
Insert the VarP pointer in the xSignalNode so that signals conform with their implementation in SDT 2.3.
XEOPTIONAL
Detect and report attempts to access optional struct components that are not present.
XEOUTPUT
Detect and report warnings in outputs (mainly outputs where signal is immediately discarded).
XEOWN
Detect and report illegal usage of Own and ORef pointers.
XERANGE
Detect and report subrange errors.
XEREALDIV
Detect and report real division with 0.0.
XEREF
Detect and report attempts to dereference null pointer.
XEUNION
Detect and report attempts to access non-active components in a #UNION.
XEVIEW
Detect and report errors in view actions.
XGRTRACE
Compile with the trace in source SDL graphs enabled.
XITEXCOMM
Enable the possibility for an executable to communicate with the TTCN Suite via the Postmaster.
XMAIN_NAME
If this macro is defined the main function in sctsdl.c will be renamed to the name given by the macro.
XMONITOR
Compile with the monitor system. This macro will implicitly set up a number of other macros as well.
XMSCE
Compile with the MSC trace enabled.
XNOMAIN
If this macro is defined the main function in sctsdl.c will be removed.
XPMCOMM
Enable the possibility for an executable to communicate via the Postmaster.
XPRSPRIO
Use priorities on process instance sets.
XPRSSIGPRIO
Use first priorities on process instance sets and then priorities on signal instances.
XSDLENVUI
Enable the possibility to communicate with a user-defined UI.
XSIGLOG
Call the xSignalLog and xProcessLog functions.
XSIGPRIO
Use priorities on signal instances.
XSIGPRSPRIO
Use first priorities on signal instances and then priorities on process instance sets.
XSIMULATORUI
Enable the possibility to communicate with the simulator UI.
XTENV
As XENV but call xInEnv at specified times (next event time is out parameter from function xInEnv).
XTRACE
Compile with the textual trace enabled.
Code Optimization
XCONST
The majority of the xIdNode structs can be made const by defining CONST as const. This is only possible in applications (not simulations).
XCONST_COMP
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.
XNOCONTSIGFUNC
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.
XNOENABCONDFUNC
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.
XNOEQTIMERFUNC
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.
XNOREMOTEVARIDNODE
Do not include xIdNodes for remote variable definitions.
XNOSIGNALIDNODE
Do not include xSignalIdNodes for signals and timers.
XNOSTARTUPIDNODE
Do not include xSignalIdNodes for start up signals.
XNOUSEOFOBJECTIDENTIFIER
The type Object_identifier and all operations on that type are removed.
XNOUSEOFOCTETBITSTRING
The types Bit_string, Octet, Octet_string and all operations on these types are removed.
XNOUSEOFSERVICE
All data and code needed to handle services are removed.
XNOUSEOFREAL
The type real and all operations on real are removed.
XOPT
Defines XOPTSIGPARA, XOPTDCL, XOPTFPAR, XOPTSTRUCT, XOPTLIT, and XOPTSORT.
For more information see these macros.
XOPTCHAN
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.
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.
XOPTDCL
Do not include xIdNodes for variables.
XOPTFPAR
Do not include xIdNodes for formal parameters.
XOPTLIT
Do not include xIdNodes for literals.
XOPTSIGPARA
Do not include xIdNodes for signal parameters.
XOPTSORT
Do not include xIdNodes for newtypes and syntypes.
XOPTSTRUCT
Do not include xIdNodes for struct components.
XPRSOPT
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.
XSYNTVAR
If this compilation switch is defined, xVarIdNodes are inserted for the Present components for optional struct components. This feature is only needed by the Explorer and by LINK. It should not be defined otherwise.
Definitions of Minor Features
XBREAKBEFORE
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.
XCASEAFTERPRDLABELS
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.
XCASELABELS
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.
XCONNECTPM
If XCONNECTPM is defined the SDL simulation will try to connect itself to the postmaster. This is necessary if GR trace (XGRTRACE), communicating simulations (XPMCOMM), or communication with the TTCN Suite (XITEXCOMM) is to be used. The XCONNECTPM feature is normally only used in simulations.
XCOUNTRESETS
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.
XENVSIGNALLIMIT
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.
XERRORSTATE
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.
XFREESIGNALFUNCS
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. This macro should be defined if Master Library is used.
XFREEVARS
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 should be defined.
XIDNAMES
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.
XNRINST
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.
XOPERRORF
Include the function xSDLOpError in sctsdl.c. This function is used to print run-time errors in ADT operators.
XPRSSENDER
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.
XREADANDWRITEF
Include the functions for basic Read and Write. This is needed mainly in simulations.
XREMOVETIMERSIG
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.
XSIGPATH
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.
XSYMBTLINK
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.
XTESTF
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.
XTRACHANNELSTOENV
When using partitioning of a system a problem during the redirection of channels is that the number of channels going to the environment is not known at code generation time, which means that the size of the data area used for the connections is not known. This problem is solved in two ways.
Either the function handling redirections allocates more memory, which is the default, or the user specifies how many channels that will be redirected (which could be difficult to compute, but will lead to less need of memory).
In the first case (allocation of more memory) the macros:
#define XTRACHANNELSTOENV 0#define XTRACHANNELLISTshould be defined like above. This is the standard in scttypes.h. If the user wants to specify the number of channels himself then
#define XTRACHANNELSTOENV 10#define XTRACHANNELLIST ,0,0,0,0,0,0,0,0,0,0i.e. XTRACHANNELSTOENV should be the number of channels, while XTRACHANNELLIST should be a list of that many zeros.
XTRACHANNELLIST
See XTRACHANNELSTOENV just above.
Static Data, Mainly xIdNodes
XBLO_EXTRAS
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.
#define XBLO_EXTRAS ,0XBLS_EXTRAS
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.
#define XBLS_EXTRAS ,0XCOMMON_EXTRAS
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.
To insert a new int component with value 0 the following definition can be used:
#define XCOMMON_EXTRAS ,0XLIT_EXTRAS
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.
#define XLIT_EXTRAS ,0XPAC_EXTRAS
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.
#define XSYS_EXTRAS ,0XPRD_EXTRAS
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.
#define XSYS_EXTRAS ,0XPRS_EXTRAS
(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.
#define XPRS_EXTRAS(PREFIX_PROC_NAME) \,XCAT(PREFIX_PROC_NAME,_STACKSIZE)XSIG_EXTRAS
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.
#define XSIG_EXTRAS ,0XSPA_EXTRAS
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.
#define XSPA_EXTRAS ,0XSRT_EXTRAS
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.
#define XSRT_EXTRAS ,0XSRV_EXTRAS
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.
#define XSRV_EXTRAS ,0XSTA_EXTRAS
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.
#define XSTA_EXTRAS ,0XSYS_EXTRAS
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.
#define XSYS_EXTRAS ,0XSYSTEMVARS
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.
XSYSTEMVARS_H
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).
XVAR_EXTRAS
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.
#define XVAR_EXTRAS ,0Data in Processes, Procedures and Services
PROCEDURE_VARS
The struct components that are needed for each procedure instance. Example: state.
PROCESS_VARS
The struct components that are needed for each process instance. Example: state, parent, offspring, self, sender, inputport.
SERVICE_VARS
The struct components that are needed for each service instance. Example: state
YGLOBALPRD_YVARP
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.
YGLOBALSRV_YVARP
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.
YPAD_TEMP_VARS
Local variables in the PAD function for a process or service. Example: temporary variables needed for outputs, create actions.
YPAD_YSVARP
Declaration of the ySVarP pointer used to refer to the received signal. Normally ySVarP is void *.
YPAD_YVARP
(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.
YPRD_TEMP_VARS
Local variables in the function implementing the behavior of an SDL procedure.
YPRD_YVARP
(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.
Some Macro Used Within PAD Functions
BEGIN_PAD
(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.
BEGIN_START_TRANSITION
(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.
CALL_SERVICE
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).
CALL_SUPER_PAD_START
(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.
CALL_SUPER_PRD_START
(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.
CALL_SUPER_SRV_START
(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.
LOOP_LABEL
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.
LOOP_LABEL_PRD
Similar to LOOP_LABEL but used in procedures with states.
LOOP_LABEL_PRD_NOSTATE
Similar to LOOP_LABEL but used in procedures without states. This macro is in many circumstances expanded to nothing.
LOOP_LABEL_SERVICEDECOMP
Similar to LOOP_LABEL but used in the PAD function for a process containing services.
SDL_OFFSPRING
Should return the value of offspring.
SDL_PARENT
Should return the value of parent.
SDL_SELF
Should return the value of self.
SDL_SENDER
Should return the value of sender.
START_SERVICES
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.
XEND_PRD
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.
XPRSNODE
Should usually be expanded to the type xPrsNode.
XNAMENODE
How to reach the xPrsIdNode from a PAD function. Normally this is yVarP->NameNode.
XNAMENODE_PRD
How to reach the xPrdIdNode from a PRD function. Normally this is yPrdVarP->NameNode.
XNAMENODE_SRV
How to reach the xSrvIdNode from a PAD function. Normally this is ySrvVarP->NameNode.
YPAD_FUNCTION
(PAD)The function heading of the PAD function given as parameter.
YPAD_PROTOTYPE
(PAD)The function prototype of the PAD function given as parameter.
YPRD_FUNCTION
(PRD)The function heading of the PRD function given as parameter.
YPRD_PROTOTYPE
(PRD)The function prototype of the PRD function given as parameter.
yInit Function
BEGIN_YINIT
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.
XPROCESSDEF_C
(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.
- 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.XPROCESSDEF_H
(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.
- 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.xInsertIdNode
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.
YINIT_TEMP_VARS
This macro is placed in all yInit functions and can be expanded to local variables needed within the yInit function.
Implementation of Signals and Output
ALLOC_SIGNAL
ALLOC_SIGNAL_PAR
(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).
- 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).INSIGNAL_NAME
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.
OUTSIGNAL_DATA_PTR
This should be the pointer referring 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.
SDL_2OUTPUT
SDL_2OUTPUT_NO_TO
SDL_2OUTPUT_COMPUTED_TO
SDL_ALT2OUTPUT
SDL_ALT2OUTPUT_NO_TO
SDL_ALT2OUTPUT_COMPUTED_TO
(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.
- 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.SDL_THIS
In an output TO THIS in SDL, the RECEIVER parameter in the ALLOC_SIGNAL and SDL_2OUTPUT macros discussed above will become SDL_THIS.
SIGCODE
(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.
SIGNAL_ALLOC_ERROR
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.
SIGNAL_ALLOC_ERROR_END
This macro is inserted after the SDL_2OUTPUT macro.
SIGNAL_NAME
(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. A file containing such defines can be generated using the Generate Signal Numbers feature in Cadvanced/Cbasic.
SIGNAL_VARS
The struct components that are needed for each signal instance. Example: sender, receiver, signal type.
TO_PROCESS
(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.
- PROC_NAME
the name of the receiving process without prefix.- PROC_IDNODE
the xPrsIdNode of the receiving process.TRANSFER_SIGNAL
TRANSFER_SIGNAL_PAR
(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).XNONE_SIGNAL
The representation for a none signal.
XSIGNALHEADERTYPE
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.
XSIGTYPE
Depending on the representation of the signal type that is used (xSignalIdNode or int) this macro should either be xSignalIdNode or int.
Implementation of RPC
ALLOC_REPLY_SIGNAL
ALLOC_REPLY_SIGNAL_PAR
ALLOC_REPLY_SIGNAL_PRD
ALLOC_REPLY_SIGNAL_PRD_PAR
(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.
- 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.REPLYSIGNAL_DATA_PTR
REPLYSIGNAL_DATA_PTR_PRD
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.
SDL_RPCWAIT_NEXTSTATE
SDL_RPCWAIT_NEXTSTATE_PRD
(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.
- 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.SDL_2OUTPUT_RPC_CALL
(PRIO, VIA, SIG_NAME, SIG_IDNODE, RECEIVER, SIG_PAR_SIZE, SIG_NAME_STRING)Send the call signal of an RPC.
- 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.SDL_2OUTPUT_RPC_REPLY
SDL_2OUTPUT_RPC_REPLY_PRD
(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.
- 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.XGETEXPORTINGPRS
(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.
XRPC_REPLY_INPUT
XRPC_REPLY_INPUT_PRD
Macros that can be used for special processing needed to receive an RPC reply signal. The macros are usually expanded to nothing.
XRPC_SAVE_SENDER
XRPC_SAVE_SENDER_PRD
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.
XRPC_SENDER_IN_ALLOC
XRPC_SENDER_IN_ALLOC_PRD
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.
XRPC_SENDER_IN_OUTPUT
XRPC_SENDER_IN_OUTPUT_PRD
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.
XRPC_WAIT_STATE
The state number used for a RPC wait state. XRPC_WAIT_STATE is usually defined as -3.
Implementation of View and Import
XGETEXPORTADDR
(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.
- 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.SDL_VIEW
(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.
- 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.Implementation of Static and Dynamic Create and Stop
ALLOC_STARTUP
ALLOC_STARTUP_PAR
(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.
- 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.ALLOC_STARTUP_THIS
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.
INIT_PROCESS_TYPE
(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.
- 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.SDL_CREATE
(PROC_NAME, PROC_IDNODE, PROC_NAME_STRING)This macro is used to create (a create action) a process instance.
- 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.SDL_CREATE_THIS
This macro is used to implement create this.
SDL_STATIC_CREATE
(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.
- 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.SDL_STOP
This macro is used to implement the SDL operation stop (both in processes and in services).
STARTUP_ALLOC_ERROR
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.
STARTUP_ALLOC_ERROR_END
This macro is inserted after the SDL_CREATE macro.
STARTUP_DATA_PTR
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.
STARTUP_VARS
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.
Implementation of Timers, Timer Operations and Now
ALLOC_TIMER_SIGNAL_PAR
(TIMER_NAME, TIMER_IDNODE, TIMER_PAR_TYPE)Allocate a data area for the timer signal with 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.DEF_TIMER_VAR
DEF_TIMER_VAR_PARA
(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.
INIT_TIMER_VAR
INIT_TIMER_VAR_PARA
(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.
INPUT_TIMER_VAR
INPUT_TIMER_VAR_PARA
(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.
RELEASE_TIMER_VAR
RELEASE_TIMER_VAR_PARA
(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.
SDL_ACTIVE
(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 Cadvanced/Cbasic SDL to C Compiler.
- 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.SDL_NOW
This is the implementation of now in SDL.
SDL_RESET
(TIMER_NAME, TIMER_IDNODE, TIMER_VAR, TIMER_NAME_STRING)This macro is used to implement the SDL operation reset on a timer without 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.SDL_RESET_WITH_PARA
(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.
- 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.SDL_SET
(TIME_EXPR, TIMER_NAME, TIMER_IDNODE, TIMER_VAR, TIMER_NAME_STRING)SDL_SET_WITH_PARA
(TIME_EXPR, TIMER_NAME, TIMER_IDNODE, TIMER_PAR_TYPE, EQ_FUNC, TIMER_VAR, TIMER_NAME_STRING)SDL_SET_DUR
(TIME_EXPR, DUR_EXPR, TIMER_NAME, TIMER_IDNODE, TIMER_VAR, TIMER_NAME_STRING)SDL_SET_DUR_WITH_PARA
(TIME_EXPR, DUR_EXPR, TIMER_NAME, TIMER_IDNODE, TIMER_PAR_TYPE, EQ_FUNC, TIMER_VAR, TIMER_NAME_STRING)SDL_SET_TICKS
(TIME_EXPR, DUR_EXPR, TIMER_NAME, TIMER_IDNODE, TIMER_VAR, TIMER_NAME_STRING)SDL_SET_TICKS_WITH_PARA
(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 + expressionIn 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.
- 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.TIMER_DATA_PTR
This should be the pointer referring 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 macroTIMER_SIGNAL_ALLOC_ERROR
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.
TIMER_SIGNAL_ALLOC_ERROR_END
This macro is inserted after the SDL_SET macro.
TIMER_VARS
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.
XTIMERHEADERTYPE
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.
Implementation of Call and Return
ALLOC_PROCEDURE
(PROC_NAME, PROC_IDNODE, VAR_SIZE)Allocate a data area (yVDef) for the called procedure.
- 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.ALLOC_THIS_PROCEDURE
Allocate a data area (yVDef) for a procedure when call THIS is used.
ALLOC_VIRT_PROCEDURE
(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.
CALL_PROCEDURE
CALL_PROCEDURE_IN_PRD
(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.
- 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.CALL_PROCEDURE_STARTUP
CALL_PROCEDURE_STARTUP_SRV
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.
CALL_THIS_PROCEDURE
(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.
CALL_VIRT_PROCEDURE
CALL_VIRT_PROCEDURE_IN_PRD
(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.
- 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.PROCEDURE_ALLOC_ERROR
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.
PROCEDURE_ALLOC_ERROR_END
This macro is inserted after the CALL_PROCEDURE macro.
PROC_DATA_PTR
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).
SDL_RETURN
The implementation of return in SDL.
XNOPROCATSTARTUP
If this macro is defined then all the code discussed for the macro CALL_PROCEDURE_STARTUP (just above) is removed.
Implementation of Join
Joins in SDL are normally implemented as goto:s in C, but in one case a more complex implementation is needed. This is when the label, mentioned in the join, is in a super type.
XJOIN_SUPER_PRS
(RESTARTADDR,RESTARTPAD)XJOIN_SUPER_PRD
(RESTARTADDR,RESTARTPRD)XJOIN_SUPER_SRV
(RESTARTADDR,RESTARTSRV)These macros represent join to super type in processes, procedures, and services, in that order.
- RESTARTADDR
The restart address in the super type.- RESTARTPAD, RESTARTPRD, RESTARTSRV
The PAD function for the super type.Implementation of State and Nextstate
Implicit nextstate operations in RPC calls are treated in the RPC section.
ASTERISK_STATE
The state number for an asterisk state. ASTERISK_STATE is usually defined as -1.
ERROR_STATE
The state number used for the error state. ERROR_STATE is usually defined as -2.
START_STATE
The state number for the start state. START_STATE should be defined as 0.
START_STATE_PRD
The state number for the start state in a procedure. START_STATE_PRD should be defined as 0.
SDL_NEXTSTATE
(STATE_NAME, PREFIX_STATE_NAME, STATE_NAME_STRING)Nextstate operation (in process or service) of the given state.
- 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.SDL_DASH_NEXTSTATE
Dash nextstate operation in a process.
SDL_DASH_NEXTSTATE_SRV
Dash nextstate operation in a service.
SDL_NEXTSTATE_PRD
(STATE_NAME, PREFIX_STATE_NAME, STATE_NAME_STRING)Nextstate operation (in procedure) of the given state.
- 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.SDL_DASH_NEXTSTATE_PRD
Dash nextstate operation in a procedure.
Implementation of Any Decisions
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)statementsEND_ANY_PATHBEGIN_ANY_PATH(2)statementsEND_ANY_PATHEND_ANY_DECISIONBEGIN_ANY_DECISION
(NO_OF_PATHS)Start of the any decision. NO_OF_PATHS is the number of paths in the decision.
BEGIN_ANY_PATH
(PATH_NO)A path (not the first) in implementation part of the any decision. PATH_NO is the path number.
BEGIN_FIRST_ANY_PATH
(PATH_NO)The first possible path in implementation part of the any decision. PATH_NO is the path number.
DEF_ANY_PATH
(PATH_NO, SYMBOLNUMBER)Definition of a path in the decision.
END_ANY_DECISION
END_ANY_PATH
End of one of the paths in the implementation section.
END_DEFS_ANY_PATH
(NO_OF_PATHS)End of the definition part of the any decision. NO_OF_PATHS is the number of paths in the decision.
Implementation of Informal Decisions
The implementation of informal decisions are similar to any decisions.
BEGIN_FIRST_INFORMAL_PATH
(PATH_NO)The first possible path in implementation part of the informal decision. PATH_NO is the path number.
BEGIN_INFORMAL_DECISION
(NO_OF_PATHS, QUESTION)BEGIN_INFORMAL_ELSE_PATH
(PATH_NO)The else path in implementation part of the any decision. PATH_NO is the path number.
BEGIN_INFORMAL_PATH
(PATH_NO)A path in implementation part of the any decision. PATH_NO is the path number.
DEF_INFORMAL_PATH
(PATH_NO, ANSWER, SYMBOLNUMBER)Definition of a path in the decision.
- PATH_NO
the path number.- ANSWER
the answer string.- SYMBOLNUMBER
the symbol number for the first symbol in this path.DEF_INFORMAL_ELSE_PATH
(PATH_NO, SYMBOLNUMBER)Definition of the else path in the decision.
END_DEFS_INFORMAL_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_INFORMAL_ELSE_PATH
End of the else paths in the implementation section.
END_INFORMAL_DECISION
The end of the informal decision.
END_INFORMAL_PATH
End of one of the paths in the implementation section.
Macros for Component Selection Tests
The macros in this section handles testing the validity of for example a component selection of a choice or #UNION variable. Also tests for optional components in structs and for de-referencing of pointers is treated here.
XCHECK_CHOICE_USAGE
(TAG,VALUE,NEQTAG,COMPNAME,CURR_VALUE,TYPEINFO)XSET_CHOICE_TAG
(TAG,VALUE,ASSTAG,NEQTAG,COMPNAME,CURR_VALUE,TYPEINFO)XSET_CHOICE_TAG_FREE
(TAG,VALUE,ASSTAG,NEQTAG,FREEFUNC,COMPNAME,CURR_VALUE,TYPEINFO)The CHOICE macros are used to test and to set the implicit tag in a choice variable. The XSET_CHOICE_TAG and XSET_CHOICE_TAG_FREE set the tag when some component of the choice is assigned a value. The FREE version of the macro is used if the choice contains some component that has a Free function. The XCHECK_CHOICE_USAGE is used to test if an accessed component is active or not.
- TAG
The implicit tag component- VALUE
The new or expected tag value- ASSTAG
The assignment function for the tag type- NEQTAG
The equal test function for the tag type- FREEFUNC
The Free function for the Choice type- COMPNAME
The name of the selected component as a char string- CURR_VALUE
The current value of the tag type- TYPEINFO
The type info node for the tag type.XCHECK_OPTIONAL_USAGE
(PRESENT_VAR,COMPNAME)This macro is used to check that a selected optional component is present. The PRESENT_VAR parameter is the present variable for this component, while COMPNAME is the selected components name as a char string.
XCHECK_UNION_TAG_USAGE
(TAG,VALUE,NEQTAG,COMPNAME,CURR_VALUE,TYPEINFO)XCHECK_UNION_TAG
(TAG,VALUE,ASSTAG,NEQTAG,COMPNAME,CURR_VALUE,TYPEINFO)XCHECK_UNION_TAG_FREE
(TAG,VALUE,ASSTAG,NEQTAG,FREEFUNC,COMPNAME,CURR_VALUE,TYPEINFO)The UNION macros are used to test tag in a union variable. The XCHECK_UNION_TAG and XCHECK_UNION_TAG_FREE check the tag when some component of the union is assigned a value. The FREE version of the macro is used if the union contains some component that has a Free function. The XCHECK_UNION_USAGE is used to test if an accessed component is active or not.
- TAG
The tag component- VALUE
The expected tag value- ASSTAG
The assignment function for the tag type- NEQTAG
The equal test function for the tag type- FREEFUNC
The Free function for the UNION type- COMPNAME
The name of the selected component as a char string- CURR_VALUE
The current value of the tag type- TYPEINFO
The type info node for the tag type.XCHECK_REF
XCHECK_OWN
XCHECK_OREF
(VALUE,REF_TYPEINFO,REF_SORT)These macros are used to implement a test that Null pointers (using the Ref, Own, or ORef generator) are not de-referenced. These macros are inserted before each statement containing a Ref/Own/ORef pointer de-referencing. In case of an ORef pointer it is also checked that the ORef is valid, i.e. that it refers to an object owned by the current process.
- VALUE
This is the value of the pointer.- REF_TYPEINFO
The typeinfo node for the Ref sort.- REF_SORT
The C type that corresponds to the Ref instantiation newtype.XCHECK_OREF2
(VALUE)Checks that a ORef pointer is a valid pointer, i.e. NULL, or that it refers to an object owned by the current process.
Debug and Simulation Macros
XAFTER_VALUE_RET_PRDCALL
(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.
XAT_FIRST_SYMBOL
(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.
XAT_LAST_SYMBOL
A macro generated immediately before a nextstate or stop operation.
XBETWEEN_STMTS
XBETWEEN_STMTS_PRD
(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.
XBETWEEN_SYMBOLS
XBETWEEN_SYMBOLS_PRD
(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.
XDEBUG_LABEL
(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.
XOS_TRACE_INPUT
(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.
YPRSNAME_VAR
(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.
YPRDNAME_VAR
(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.
Utility Macros to Be Inserted
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 XXFREE xFree#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 */#endifThe xDefaultPrio macros above should, of course, be defined to the suitable default values.
Other macros that should be defined are.
SDL_NULL
a null value for the type PId.
xNotDefPId
which is used as RECEIVER parameter in the SDL_2OUTPUT macros. Please see also the section were signals are treated.
http://www.ibm.com/rational |
![]() |
![]() |
![]() |
![]() |