![]() |
![]() |
![]() |
![]() |
![]() |
Generation of Identifiers
Processes and Process IDs (PID)
In order to implement the environment functions, it is important to notice that process IDs in Cmicro are generated into the sdl_cfg.h file, which must be included by the user's environment C module. These IDs are coded like it is described in Generated Configuration File. More explanations are given in the following.
Since process IDs might become ambiguous, especially in block type and process type instantiations in SDL'92, the names of process IDs that are to be used in the environment functions are to be given a prefix. Using this prefix within the environment functions (xInEnv), it can be guaranteed that different process IDs (equates to "instance sets" in SDL'92) with the same name can be distinguished, which is necessary in order to send signals to the right process instance within the SDL system. On the other hand, prefixes are not necessary when all the process instance sets within the system have a different name. The Cmicro SDL to C Compiler uses an algorithm to calculate the prefixes in the most convenient way.
For example, if a process named "myprocess" exists only once within the SDL system, there will be no automatic prefix generated, e.g. the full process ID is
#define XPTID_myprocess 0If, as another example, the process "myprocess" exists twice, for example once within a block called "myfirstblock" and once more within a block called "mysecondblock", the Cmicro SDL to C Compiler then creates two definitions which guarantee that the processes can be distinguished:
#define XPTID_myfirstblock_myprocess 0#define XPTID_mysecondblock_myprocess 1In this way, by adding scope names (block names), prefixes are always generated in a way so that no naming conflicts occur. Of course, for process and block type instantiations, the name of the instance is being used to generate this unambiguous prefix.
SDL process types (process instance sets in SDL'92), as well as SDL process instances are numbered consecutively beginning with zero. The ordering of these numbers is the same as the ordering of the processes in the SDL/PR file.
The values 250 to 255 are reserved for internal purposes and must not be used for process type numbering. The Targeting Expert checks this rule automatically. For small systems this does not create any problems.
The Cmicro Kernel assumes the above definitions.
In the generated C code, the SDL values self, sender, parent and offspring, and variables of this type are represented by the typedef xPID. The intention is to have unique numbering of processes and their instances in the whole SDL system. This becomes necessary because of the Cmicro Code no longer containing the structure of the SDL system (system, block...). The typedef xPID is defined as
- unsigned char or unsigned int
if there are only (x,1) declarations in the system no distinction between instances is necessary. This is automatically detected. See the flag XMK_USED_ONLY_X_1 in the section Automatic Scaling Included in Cmicro.- unsigned int or unsigned long
if there is at minimum one (x, N) declaration in the system, where N > 1, instances need to be distinguishable from each other.There are a few macros defined to extract the process type number or the process instance number from a variable of the type xPID and to build an xPID variable from a process type number and a process instance number, the users do not have to think about the internal representation:
Example 601 : Macros to extract process type or instance number
processtype = EPIDTYPE(xPID_variable)processinstance = EPIDINST(xPID_variable)xPID_variable = GLOBALPID(processtype, processinstance)Signals and Timers
SDL signals and timers are numbered automatically by the Cmicro SDL to C Compiler so that they have a unique number over the complete system. Timers are represented by the values 1, 2, 3.... MT to the last timer of the MT timers in the system. After that follow ordinary SDL signal numbers beginning with MT+1, MT+2, MT+3... MT + MS.
When using the standard Cmicro Package, as delivered, then the values 0 and 251 to 255 are reserved for internal purposes. If the upper limit of 250 signals and timers is being reached, then the signal ID type has to be changed from unsigned char to unsigned int, thus allowing more than 60000 signals/timers to be handled. All these changes will be done if the flag XMK_USE_MORE_THAN_250_SIGNALS is set.
C code generated for signals and timers:
#define znnn_SignalName 1#define znnn_SignalName 2Where znnn_ is the automatically generated prefix which is required to cope with the SDL scope rules. Remember, that processes in SDL can have the same name as signals, states etc. Prefixing, however, ensures uniquely named SDL objects in the generated C Code.
A system with 2 signals S1 and S2, and a timer TIMER1:
#define z049_TIMER1 1#define z050_S1 2#define z051_S2 3When it comes to connecting the environment to the SDL system, the automatic numbering of signal IDs and timer IDs may not be required. If the user wants to prevent the automatic numbering of signals, then it is possible to #include a file containing all the signal and timer numbers. The file may contain something like:
#undef SignalOrTimerName#define SignalOrTimerName AnyValueAccordingToKernelRulesStates
SDL states are consecutively numbered from 1 through to N for each process type. The values 0, and 250 to 255 are reserved for internal purposes in the Cmicro Package. This restriction incurs no foreseeable difficulty as processes should never have more than 50 States as a recommendation.
If there are even more states per process the flag XMK_USE_HUGE_TRANSITIONTABLES must be set.
The following C code generation is supplied for the header-section of the generated C file(s).
#define znnn_State1Name 1#define znnn_State2Name 2....#define znnn_State3Name 3For a process with 2 states S1 and S2:
#define z020_S1#define z021_S2These values are used in the state-index-table and in the generated C functions, wherever a nextstate is referenced.
http://www.ibm.com/rational |
![]() |
![]() |
![]() |
![]() |