CAL Actor Language: Difference between revisions

Revision as of 14:35, 16 May 2019

Latest revision as of 13:31, 3 January 2025

(9 intermediate revisions by 8 users not shown)

Line 1:

{{Short description|Programming language}}

{{multiple issues|

{{manualhow-to|date=December 2016}}

{{confusing|date=May 2019}}

}}

Line 46 ⟶ 47:

== CAL features ==

=== The Structurestructure of Actorsactors ===

Actors perform their computation in a sequence of steps called firings. In each of those steps:

* 1. the actor may consume tokens from its input ports,

Line 52 ⟶ 53:

* 3. it may produce tokens at its output ports.

Consequently, describing an actor involves describing its interface to the outside, the ports, the structure of its internal state, as well as the steps it can perform, what these steps do (in terms of token production and consumption, and the update of the actor state), and how to pick the step that the actor will [[perform]] next. This section discusses some of the constructs in the CAL language that deal with these issues. [[Acting|Actions]] describe the things that happen during a step that an actor takes. In fact, it is accurate to say that a step consists of executing an action. Recall that when an actor takes a step, it may consume input tokens and produce output tokens.

Therefore, input patterns do the following:

Line 64 ⟶ 65:

=== Non determinism ===

A [[wikt:nondeterminism|Nonnon-determinismdeterministic]] is a non-deterministic actor is one that, for the same input sequences, allows more than one run and more than one possible output. Non-determinism can be very powerful when used appropriately, but it can also be a very troublesome source of errors. A particular concern is that non-determinism might be introduced into an actor inadvertently, i.e. the author thinks the actor is deterministic even though it isn’tisn't. One of the key design goals of the CAL language was to allow the description of non-deterministic actors, while at the same time permitting tools to identify possible sources of non-determinism, so that they can warn the user about them.

A key consequence of a non-deterministic actor like '''NDMerge''' is that during an actual execution, its output may depend on the timing of its input. If both its input queues are empty, and '''NDMerge''' is waiting for input, then whatever input the next token arrives at may be the one that is copied next to the output. Consequently, the scheduling of activities in the actor network, or the relative speeds of the actors feeding into an actor like '''NDMerge''' may affect the output of the system. This may, occasionally, by desirable, and at other times it may not. In any event, it is a property that one needs to be aware of.

Line 73 ⟶ 74:

The guard clause of an action contains a number of expressions that all need to be true in order for the action to be fireable. For the first action to be fireable, the incoming token needs to be greater or equal to zero, in which case it will be sent to output ''P''. Otherwise that action cannot fire. Conversely, for the second action to be fireable, the token needs to be less than zero, in which case it is sent to output N. A run of this actor might look like this: An actor could run into trouble if it ever encounters a zero token, because none of its actions will be able to fire on it.

It’sIt's not illegal to write actors that terminate on some input, and in fact it may be important to have a few of those in some systems. But it is a pitfall that one needs to be aware of. Secondly, the guard conditions are also disjoint in addition to being exhaustive.

Finally, note that guard conditions can ”peek” at the incoming tokens without actually consuming them — if the guards happen to be false or the action is not fired for some other reason, and if the token is not consumed by another action, then it remains where it is, and will be available for the next firing. (Or it will remain there forever, as in the case of the zero token in front of '''SplitDead''', which is never removed because the actor is dead.)

Line 80 ⟶ 81:

=== Actors with state ===

In all the actors so far, nothing an action firing did would in any way affect subsequent firings of actions of the same actor. Using state variables, action firings can leave information behind for subsequent firings of either the same or a different action of the same actor. The way this actor is written, the selection of the next input token and the actual copying of the token to the output is one atomic step.

Note that Select and '''IterSelect''' are almost, but not entirely, equivalent. First of all, '''IterSelect''' makes twice as many steps in order to process the same number of tokens. Secondly, it actually reads, and therefore consumes, the S input token, irrespective of whether a matching data token is available on ''A'' or ''B''.

Line 86 ⟶ 87:

==Schedules==

The '''IterSelect''' actor of the previous section illustrated the use of state to control the selection of actions. This is an extremely common thing to do in practice, and the CAL language provides special syntax for this purpose in the form of schedules. Conceptually, one can think of schedules as codifying a particular pattern of using a state variable—they do not add anything to the language in terms of expressiveness. The rationale for using schedules is twofold:

# They are usually easier to use and less error prone than using a state variable and lots ofmany guards and assignments.

# Tools can use the information encoded in a schedule more easily, and thus recognize regularities in the actor that might help them to produce more efficient code, or perform other analyses that help in implementation and design.

Line 108 ⟶ 109:

=== Simple composite expressions ===

CAL provides operators of two kinds to build expressions: [[Unary operation|unary]] and [[Binary operation}|binary]]. A unary operator in CAL is always a prefix operator, i.e. it appears before its single operand. A binary operator occurs between its two operands.

==Statements==

Line 124 ⟶ 125:

== Supporting tools ==

=== OpenDF framework ===

{{EmptysectionEmpty section|date=February 2013}}

=== Open RVC-CAL Compilercompiler ===

{{empty section|date=April 2018}}

== References ==

{{reflist}}

==External links==

* [http://opendf.sf.net/ Open Dataflow (OpenDF in short)]

* [http://orcc.sf.net/ Open RVC-CAL Compiler (Orcc)]

* [http://openforge.sf.net/ Openforge Compiler or Cal2HDL]

[[Category:High-level programming languages]]