PLANIFICACIÓN DE TAREAS REALIZADAS EN EL CURSO

In the following section, an overview concerning CAL is provided. The syntax and the semantic of this dataflow program are illustrated through simple but effective examples. The interested reader can refer to [51].

Lexical tokens

Lexical tokens help the user to understand the functionality provided by any language. A lexical token is a string of indivisible characters known as lexemes. The CAL lexical tokens, also summarized in Table 2.1, are described in the following:

• Keywords Keywords are a special type of identifiers. They are already reserved in the programming language by default. These keywords can never be used as identifiers in the code. Some of these keywords areaction,actor,begin,else,if,while,

2.5. The Cal Actor Language

• Operators Operators usually represent mathematical, logical or algebraic operations. Operators are written as any string of characters!,%,ˆ,&,*,/,+,-,=,<,>,?,˜and|.

• Delimiters Delimiters are used to indicate the start or the end of this syntactical element in the CAL. The following elements are used as delimiters:(,),[,],{and}.

• Comments Comments in CAL language are the same as in Java and C/C++. Single-line comments start with//and multiple-line comments start with/*and end with*/.

Table 2.1: CAL lexical tokens.

Keywords action,actor,procedure,function,begin,if,else,end,

foreach,while,do,procedure,in,list,int,uint,float,

bool,true,false

Operators !,%,ˆ,&,*,/,+,-,=,<,>,?,˜,| Delimiters (,),[,],{,},==>,->,:= Comments //,/*. . .*/

Actions, input patterns and output patterns

The simplest actor that can be described using CAL is theInverteractor defined in Listing 2.1. This actor consumes a token from its input port and produces a token on its output port. The actor header is defined in line 1, which contains the actor name, followed by a list of parameters contained inside the()construct (empty, in this case), and the declaration of the input and output ports. The input ports are those in front of the==>construct and the output ports are those after it. In this case the input and output port sets are defined as PInverteri n = {I} and PInverterout = {O} respectively. For each parameter and port, the data type is specified before the name (all defined with anintdata type, in this case). This actor contains only one action, labeled asinvertas defined in line 3. In this case, the action set is defined asλInverter= {invert}. Actioninvertdemonstrates how to specify token consumption and production. The part in front of the==>, which defines the input patterns, specifies how many tokens to consume, from which ports, and what to call those tokens in the rest of the action. In this case, there is one input pattern:I:[val]. This pattern indicates that one token is to be read (i.e. consumed) from the input portI, and that the token is to be calledvalin the rest of the action. Such an input pattern also defines a condition that must be met for this action to fire: if the required token is not present, this action will not be executed. Therefore, input patterns do the following:

• They define the number of tokens (for each port) that will be consumed when the action is executed (fired).

• They declare the variable symbols by which tokens consumed by an action firing will be referred to within the action.

• They define a firing condition for the action, i.e. a condition that must be met for the action to be able to fire.

The output patterns of an action are those defined after the==>construct. They simply define the number and values of the output tokens that will be produced on each output port by each firing of the action. In this case, the output patternO:[-v]says that exactly one token will be generated at output portO, and its value is-v. It is worth noting that although syntactically the use ofvin the input patternI:[a]looks the same as the one in the output expressionO:[-v], their meanings are very different. In the input pattern the namevis declared: in other words, it is introduced as the name of the token that is consumed whenever the action is fired. By contrast, the occurrence ofvin the output expression uses that name.

Listing 2.1: Inverter.cal

1 actor Inverter() int I ==> int O :

2

3 invert: action I:[val] ==> O:[-val] end

4 5 end

Guards

So far, the only firing condition for actions was that there be sufficient tokens for them to consume, as specified in their input patterns. However, in many cases, it is possible to specify additional criteria that need to be satisfied for an action to fire. Conditions, for instance, that depend on the values of the tokens, the actor internal variables, or both. These conditions can be specified using guards, as for example in theSplitactor, defined in Listing 2.2. This actor defines one input portI, two output portsO1andO2, and two actionsAandB. Those actions require the availability of one token inI, however their selection is guarded by the value of the input tokenvalread fromI, and respectively defined in line 4 and line 7. In this example, if

val >= 0then actionAis selected, otherwise actionBis selected.

Listing 2.2: Split.cal

1 actor Split() int I ==> int O1, int O2 :

2

3 A: action I:[val] ==> O1:[val]

4 guard val >= 0 end

5

6 B: action I:[val] ==> O2:[val]

7 guard val < 0 end

8 9 end

2.5. The Cal Actor Language

Actor parameters and internal variables

Using CAL, it is possible to define a set of actor parameters. These can be used when the same actor definition is used more then once in the same program definition. For example, the

ParametrizedProduceractor, defined in Listing 2.3 uses the parametermaxCounter. This parameter, defined in line 1, is used as a guard condition by the (only) actionproduce

as defined in line 7. This actor also defines the internal variablecounterthat is used and updated during each firing of the action as described in line 9.

Listing 2.3: ParametrizedProducer.cal

1 actor ParametrizedProducer(int maxCounter) ==> int O :

2

3 int counter := 0;

4

5 produce: action ==> O:[counter]

6 guard 7 counter < maxCounter 8 do 9 counter := counter + 1; 10 end 11 12 end

Priorities and State Machines

In thePingPongMergeactor, reported in Listing 2.4, a finite state machine schedule is used to force the action sequence to alternate between the two actionsAandB. The schedule statement introduces two statess1ands2. On the contrary, in theBiasedMergeactor, reported in Listing 2.5, the selection of which action to fire is not only determined by the availability of tokens, but also depends on the priority statement.

Listing 2.4: PingPongMerge.cal

1 actor PingPongMerge() T In1, T In2 ==> T O :

2

3 A: action In1:[val] ==> O:[val] end

4

5 B: action In2:[val] ==> O:[val] end

6 7 schedule fsm s1: 8 s1(A) --> B; 9 s2(B) --> A; 10 end 11 12 end

Listing 2.5: BiasedMerge.cal

1 actor BiasedMerge() T In1, T In2 ==> T O :

2

3 A: action In1:[val] ==> O:[val] end

4

5 B: action In2:[val] ==> O:[val] end

6 7 priority 8 A > B 9 end 10 11 end