![]() |
![]() |
![]() |
![]() |
![]() |
Implementation
In this section some implementation details are presented, that can be useful for understanding how a generated simulation or application behaves. Abstract data types are treated in the next section.
Time
A generated C program can be executed in two modes with respect to the treatment of time:
Simulated Time
Using simulated time, which is the most useful mode for simulations, means that the time in the simulation has no connection with the wall clock. Instead the discrete event simulation technique is used. This technique is based on the idea that the current value for the simulation time (Now in SDL) is equal to the time at which the currently executing event is scheduled. After one event is finished, the simulation time is increased to the time when the next event is scheduled and this event is started. Events in SDL will be process transitions, timer outputs, and signals sent to the system from the environment. As an example, the use of the discrete event simulation technique means that if the next event is a timer output scheduled one hour from now, and the next transition is allowed to execute, the timer output will occur immediately. The simulation time will be increased by one hour, but the user does not have to wait one hour.
Real Time
If real time is used, then there will be a connection between the clock in the executing program and the wall clock. In the example above the user would have to wait one hour until the timer output took place. To implement real time a clock function provided by the operating system is used. Not all systems are suitable to simulate in this way. The time scale in the system ought to be seconds or maybe minutes, not milliseconds and not hours.
At program start up the system time, SDL Now, is zero. The system clock is stopped during the time the program spends in the monitor system.
Scheduling
The process instances in the simulated system will execute transitions that consist of actions like tasks, decisions, outputs, procedure calls, etc., according to the rules of SDL. It is assumed that a transition takes no time and that a signal instance is immediately placed in the input port of the receiver when an output operation occurs.
A transition is always executed without any interrupts, if the user does not manually rearrange the ready queue using an appropriate command provided by the monitor system (Rearrange-Ready-Queue). It is possible to execute a few SDL symbols in one transition and then to re-arrange the ready queue and execute another transition. The interrupted transition can afterwards be executed to its end.
A quasi-parallel strategy for selecting transitions to be executed is thus the basic scheduling mechanism. SDL does not in itself define an execution strategy so the selected strategy is therefore an allowed, but not the only, possible strategy for execution.
As a consequence of the execution strategy, a generated simulator is not directly suited for simulation of "timing effects", that is, situations where the time or order of actions in different process instances is of vital importance.
An example of such a situation is: Suppose a process instance A outputs two signal instances during the same transition, one to process instance B and one to process instance C. During the corresponding transitions of B and C, a signal instance is sent to process instance D.
If the behavior of the system is dependent on the order in which the signal instances are received in the input port of D, this is a hazard situation where the execution speed of process instances and the delay of signals in channels will determine the behavior. The way to handle such a situation would be to manually decide the order in which transitions should be executed.
As the Cadvanced SDL to C Compiler is also intended to generate applications, process priority has been introduced as an additional feature. For more information about how to assign priorities to processes see sub-section Assigning Priorities - Directive #PRIO.
The Ready Queue
The ready queue is a queue containing all process instances which have received a signal that can cause a transition, but which have not yet completed that transition. The ready queue is ordered firstly according to the priority and secondly according to insert time, that is a process which will be inserted last among the processes with the same priority, but before all processes with lower priority (high priority value = low priority). A process will never be inserted before the process currently executing, as pre-emptive scheduling is not used. In more detail:
- If a process outputs a signal to another process, which immediately can receive the signal, the receiving process will be inserted into the ready queue last among the processes with the same priority, but never before the currently executing process.
- If the processes currently executing a nextstate immediately can continue to execute another transition, it will be inserted into the ready queue last among the processes with the same priority. This means that it can remain as first process in the ready queue, but it can also be re-inserted somewhere else.
- If the receiving process at a timer output immediately can execute a transition as response to the received signal, the process will be inserted into the ready queue last among the processes with the same priority. This means that it can be inserted anywhere in the queue.
Enabling Conditions and Continuous Signals
Enabling conditions and continuous signals are additional concepts in SDL. The model for these concepts use repetitive signal sending, to have the expressions recalculated repeatedly. This model is not suitable during simulation, and definitely not acceptable in an application. We have therefore used an implementation strategy closer to the described behavior of the concepts, rather than the model used to define the concepts.
Implementation Strategy
First we distinguish between those enabling conditions and continuous signals that are dynamic and those that are static, that is containing expressions that can or cannot change their value when the corresponding process is waiting in the state. The expression in a dynamic enabling condition or continuous signal contains some part that can change its value, even though the process does not execute any statements. Or, put more precisely, it contains at least one import, view, or reference to Now.
Static enabling conditions or continuous signals do not provide any problems or any execution overhead, except that the corresponding expressions have to be calculated at nextstate operations. Dynamic enabling conditions or continuous signals, however, have to repeatedly be recalculated. The strategy selected for these expressions is to recalculate them after each transition or timer output performed by any process (and additionally also before the monitor is entered within a transition). In other words, each process waiting in a state containing a dynamic enabling condition or continuous signal executes an implicit nextstate operation between each transition or timer output performed by other processes.
Synonyms
Synonyms
An SDL synonym is implemented either as a C macro (#define) or as a C variable. To be translated to a macro the expression defining the value of the synonym must be:
- Of one of the predefined SDL sorts (Integer, Real etc.).
- Possible to calculate at analyze time, i.e. it may only contain literals and operators defined in the predefined SDL sorts and other synonyms which are possible to calculate at analyze time.
All other synonyms are implemented as variables given their values at program start up.
The reason for raising this question is because it is relevant to the implementation of arrays and powersets. There are two different implementations for each of these concepts, see Array and Powerset. An array in SDL can either be translated to an array in C or to a linked list in C. A powerset can either be translated to a bit array in C or to a linked list. The translation method is selected by looking at the index type. If the index type is a syntype with one limited range, the array and bit array scheme is used, otherwise the linked list is used.
If a synonym translated to a variable is used in a range condition of a syntype and the syntype is used as an index sort in an array or powerset instantiation, the linked list scheme is used to implement the array or powerset. The reason for this is that the length of the array cannot depend on a variable in C.
External Synonyms
External synonyms can be used to parameterize an SDL system and thereby also a generated program. The values that should be used for the external synonyms can either be read by the generated program during start up, or included as macro definitions into the generated code. The Cadvanced/Cbasic SDL to C Compiler can handle both these cases - it is not necessary to select which way should be used for each synonym until the program is compiled.
Using a Macro Definition
To use a macro definition in C to specify the value of an external synonym, perform the following steps:
Example 356 : Macro Definition
#define synonym1 value1#define synonym2 value2
- The synonym names are the SDL names (without any prefixes) and with any character not in letters, digits or underscore removed.
- Introduce the following #CODE directive at the system level among the SDL definitions of, for example, synonyms, sorts, and signals but before any use of the synonyms.
/*#CODE#TYPE#include "filename"*/
- If this structure is used, the value of an external synonym can be changed merely by changing the corresponding macro definition and recompiling the system.
When an application is created, macro definitions should be used for all external synonyms, as the function for reading synonym values stored on file is not available. (See below.)
Reading Values at Program Start up
The other way to supply the values of the external synonyms is to read the values at program start up. If there are any external synonyms that do not have a corresponding macro definition, it is possible to choose between supplying the values of the remaining external synonyms from the keyboard or to use a file containing the values.
When the application is started, the following prompt appears:
External synonym file :
- Press <Return> to indicate that the values should be read from the terminal.
- Or type the name of a file that contains the values and press <Return>.
If the user chooses to read the values from the terminal, he will be prompted for each value. In the other case the user should have created a file containing the external synonym names and their corresponding value according the following example:
Example 358 : Values at Program Startup
synonym1 value1synonym2 value2The synonyms may be defined in any order.
Evaluation of Include Expressions
A synonym value can be followed by a simulator only comment:
mySynonym myValue /*SIMULATOR_ONLY*/This value will not be used when evaluating include expressions.
This value will only used by the simulator when simulating the system.
Import - Export
These concepts are not implemented with the full semantics according to the model in the SDL recommendation. The model says that an imported value should be obtained using a signal interchange between the importer and exporter.
In the Cadvanced/Cbasic SDL to C Compiler we use a model where the imported value is directly obtained from the exporter, which of course makes the import operation much faster. However, the scheduling effect of the signal interchange is lost, as well as the change of SENDER in the involved processes. If these effects are important for an application, remote procedure calls can be used instead, see below.
Remote Procedure Calls
Remote procedure calls (RPC) have much in common with import/export, except that instead of obtaining one value, RPCs give the opportunity to execute a procedure in the exporting process. In the Cadvanced/Cbasic SDL to C Compiler, the model described in the SDL recommendation is used in detail to implement RPCs.
This means that a remote procedure call is translated to:
- output of pCALL signal with all parameters.
- nextstate in pWAIT, i.e. a implicit wait state.
- input of pREPLY signal with all IN/OUT parameters.
In the exporting process there will be implicit transitions where the pCALL signal can be handled.
- input pCALL.
- call remote procedure with parameters from pCALL.
- output pREPLY with the IN/OUT parameters.
- nextstate -
For more details about this model, please see the SDL recommendation.
Procedure Calls and Operator Calls
In SDL-92 value returning procedures (and remote procedures) are introduced. This means that an SDL procedure can be called within an expression. In the Cadvanced/Cbasic SDL to C Compiler such procedure calls are implemented according to the model in the SDL recommendation, that is by inserting an extra CALL just before the statement containing the value returning procedure call. The result from the call is stored in an anonymous variable, which is then used in the expression.
TASK i := (call p(1)) + (call Q(i,k));
- is translated to:
CALL p(1, Temp1);CALL q(i, k , Temp2);TASK i := Temp1 + Temp2;
The value returning procedure calls are transformed to ordinary calls, by adding a new IN/OUT parameter for the procedure result, last in the call.
Operators which are defined using operator diagrams, are according the models in the SDL recommendation, treated exactly as value returning procedure.
External Procedures And Operators
External procedures is a extension to SDL introduced in SDL-96. An external procedure is defined in a text symbol as a procedure heading:
procedure test; fpar a integer; returns integer;external;Instead of giving an implementation for the procedure the keyword external is inserted. The purpose of external procedures in SDL are to specify the existence of procedures without giving their implementation.
The Cadvanced/Cbasic SDL to C Compiler will generate no code for an external procedure declaration and will translate a call to such a procedure to an ordinary C function call. It is then up to the user to provide the C implementation of this function. Note that the code generator will in the generated function call use the name of the external procedure as it is. No prefix is inserted in this case, just as for external synonyms.
External operators are handled in the same way as external procedures. The name of the external operator is used in C just as it is. A quoted operator will cause an infix operator to be generated, while operators with ordinary names will cause C function calls to be generated.
Any
There are two different applications of any. It is possible to write
any(SortName)within an expression, or to write just
anyin a decision. The second case, with any in a decision, is implemented in the following way:
The first case, the any(SortName) within an expression, is implemented using a random number generator to draw a random number of the given type.
If any(SortName) is used for a sort violating the note above, there will be a C compilation error on the symbol ANY_SortNameWithPrefix. This means that a user can implement any for such sorts himself by defining a C macro with this name, that implements any for the given sort. Such a macro should be inserted in the #TYPE section of a #ADT directive in the syntype.
Calculation of Receiver in Outputs
The Cadvanced/Cbasic SDL to C Compiler contains an algorithm that calculates the receiving process instance set, for outputs without TO, considering channels, signal routes, connection points, and via list. There are however a few restrictions for the algorithm:
- Outputs in process types, or in processes in block types or system types cannot be handled. The reason is that the same output might lead to different receivers in different instantiation.
- Paths (channels - signal routes) that lead into other units that are separate (see Edit Separation) cannot be followed by the algorithm, as that would violate the separate generation scheme.
- Outputs in global procedures cannot be handled, as the receiver depends on the caller of the procedure.
This algorithm means that for an ordinary SDL-88 system, that is not generated using separate units, no information about the channels and signal routes are needed to direct signal to the correct receiver. For more information about the possible optimizations in applications, please see the compilation switch XOPTCHAN and the ADT PidLit (The Data Type PIdLit). Please note that XOPTCHAN and PidLit is almost impossible to use if the SDL system contains system types, block types, or process types.
http://www.ibm.com/rational |
![]() |
![]() |
![]() |
![]() |