![]() ![]() |
||||||||||
|
||||||||||
A
subprogram component represents an execution entrypoint in source text. A subprogram may
not have any internal state (static data). All parameters and required access to external data
must be explicitly declared as part of the subprogram type declaration. In addition, any events
raised within a subprogram must be specified as part of its type declaration.
Subprograms
can be called from threads and from other subprograms. These calls are sequential
calls local to the virtual address space of the thread. Subprograms can also be called remotely
from threads in other virtual address spaces through server subprograms (see Section 8.3 ). A
subprogram call sequence is declared in a subprogram or thread implementation and may be
mode- specific.
Syntax
subprogram_call_sequence
::=
[ defining_call_sequence_identifier :]
{
{ subprogram_call }+ } [ in_modes ] ;
subprogram_call
::=
defining_call_identifier : subprogramcalled_subprogram
[ { { subcomponent_call_property_association }+} ] ;
called_subprogram
::=
subprogram_classifier_reference
| data_unique_type_reference . data_subprogram_identifier
NOTES:
Subprogram type and implementation declarations follow the syntax rules for component
types and
implementations. Subprograms are not instantiated as subcomponents. Instead subprogram calls
represent their instantiation (use) with a specific set of parameter values. The syntax for specifying
call
sequences is shown here.
Naming
Rules
The
defining identifier of a subprogram call sequence declaration, if present in a component
implementation, must be unique within the local namespace of the component implementation
that contains the subprogram call.
The
defining identifier of a subprogram call declaration must be unique within the local namespace
of the component implementation that contains the subprogram call.
If
the called subprogram name is a subprogram classifier reference, its component type identifier
or component implementation name must exist in the specified (package or anonymous)
namespace.
If
the called subprogram name is a subprogram feature reference in a data component, the data
component type identifier must refer to a data component type, or it must refer to a requires data
access declaration in the component type of the component containing the subprogram call
declaration.
Legality
Rules
A
subprogram type declaration can contain parameter, out event port, out event data port, and
port group declarations as well as required data access declarations. It can also contain a flow
specification subclause as well as property associations.
A
subprogram implementation can contain a connections subclause, a subprogram calls
subclause, a flows subclause, a modes subclause and subprogram property associations.
A
subprogram implementation must not contain a subcomponent subclause.
Only
one subprogram call sequence can apply to a given mode. In other words, a mode identifier
can be specified in the in_modessubclause of at most one subprogram call sequence.
Standard
Properties
--
Properties related to source text
Source_Name:
aadlstring
Source_Text: inherit list
of aadlstring
Source_Language:
Supported_Source_Languages
--
Properties specifying memory requirements of subprograms
Source_Code_Size:
Size
Source_Data_Size:
Size
Source_Stack_Size:
Size
Source_Heap_Size:
Size
Allowed_Memory_Binding_Class:
inherit list of
classifier (memory, system, processor)
Allowed_Memory_Binding: inherit
listof reference (memory, system,
processor)
--
execution related properties
Compute_Execution_Time:
Time_Range
Compute_Deadline:
Time
--
remote subprogram call related properties
Actual_Subprogram_Call: reference
(server subprogram)
Allowed_Subprogram_Call: list
ofreference (server subprogram)
Actual_Subprogram_Call_Binding: reference(bus, processor,
memory)
Allowed_Subprogram_Call_Binding:
inherit list
of reference (bus, processor, device)
Queue_Processing_Protocol:
Supported_Queue_Processing_Protocols => FIFO
Semantics
A
subprogram component represents sequentially executable source text that is called with
parameters. A subprogram type declaration specifies all interactions of the subprogram with
other parts of the application source text. Subprogram parameters are specified as features of
a
subprogram type (see Section 8.4). This includes in and in out parameters passed
into a
subprogram and out and in out parameters returned from a subprogram on a call In
addition,
events being raised from within the subprogram through its out event port and out event data
port, and required access to static data by the subprogram are specified as part of the features
subclause of a subprogram type declaration.
A
subprogram implementation represents implementation details that are relevant to architecture
modeling. It specifies calls to other subprograms and the mode in which the call sequence
occurs.
If
required data access is declared for a subprogram type, access to the data subcomponent is
performed in a critical region to assure concurrency control for calls from different threads (for
more on concurrency control see Sections 5.1 and 5.3).
Subprogram
source text can contain Raise_Eventservice calls to cause the transmission of
events and event data through its out event ports. The fact that events may emit from a
subprogram call is documented by the declaration of out event ports and out event data ports
as features of the subprogram.
Subprogram
implementations and thread implementations can contain subprogram calls. The flow
of parameter values between subprogram calls as well as to and from ports of enclosing threads
is specified through parameter connection declarations (see Section 9.1.2).
A
thread or subprogram can contain multiple calls to the same subprogram - with the same
parameters or with different parameters.
Ordering
of subprogram calls is by default determined by the order of the subprogram call
declarations. Annex-specific notations can be introduced to allow for other call order
specifications, such as conditional calls and iterations.
Declaration
of subprogram calls in thread and subprogram implementations implies that an
instance of the subprogram executable binaries exists in the load image of the process that
contains the thread performing the subprogram calls. For subprograms, whose source text
implementation is reentrant, it is assumed that a single instance of the subprogram binaries exist
in the process virtual address space. In the case of remote subprogram calls a proxy may be
loaded for the calling thread and the actual subprogram is part of the load image of the process
with the thread servicing the remote subprogram call.
Subprogram
calls can be calls to server subprograms provided in other threads. Such calls model
synchronous remote subprogram calls. AnAllowed_Subprogram_Callproperty, if present,
identifies the server subprogram(s) that are allowed to be used in a call binding.
AnActual_Call_Bindingproperty
records the actual binding to a server subprogram.
Constraints on the buses and processors over which such calls can be routed can be specified
with the Allowed_Subprogram_Call_Bindingsproperty.
Subprogram
call sequences can be declared to apply to specific modes. In this case a call
sequence is only executed if one of the specified modes is the current mode.
Modeling
of subprograms is not required and the level of detail is not prescribed by the standard.
Instead it is determined by the level of detail necessary for performing architecture analyses.
Processing
Requirements and Permissions
The
subprogram call order defines a default execution order for the subprogram calls. Alternate
call orders can be modeled in an annex subclause introduced for that purpose.
Examples
dataMatrix
endMatrix;
subprogramMatrix_delta
features
A: in parameter matrix;
B: in parameter matrix;
result: out parameter matrix;
endMatrix_delta;
subprogramInterpret_result
features
A: in parameter matrix;
result: out parameter weather_forecast;
endInterpret_result;
dataweather_DB
features
getCurrent: subprogram getCurrent;
getFuture: subprogram getFuture;
endweather_DB;
subprogramgetCurrent
features
result: out parameter Matrix;
endgetCurrent;
subprogramgetFuture
--
a subprogram whose source text contains a raise_event service call
--
the subprogram also has access to shared data
features
date: in
parameter date;
result: out parameter Matrix;
bad_date: out event port;
wdb: requires data access weather_DB;
endgetFuture;
threadPredict_Weather
features
target_date: in event data port date;
prediction: out event data portweather_forecast;
past_date: out event port;
weather_database: requires data accessweather_DB;
endPredict_Weather;
thread
implementation Predict_Weather.others
calls{
-- subprogram call on a data component subprogram feature
-- out parameter is not resolved, but will be identified by user of
value
current: subprogram weather_DB.getCurrent;
-- subprogram call on a data component subprogram feature with port
value
-- as additional parameter. Event is mapped to thread event
future: subprogram weather_DB.getFuture;
-- in parameter actuals are out parameter values of previous calls
-- they are identified by the call name and the out parameter name
diff: subprogram Matrix_delta;
-- call with out parameter value resolved to be passed on through a
port
interpret: subprogram Interpret_result;
};
connections
parameter
target_date -> future.date;
event
port future.bad_date -> past_date;
parameter
current.result -> diff.A;
parameter
future.result -> diff.B;
parameter
diff.result -> interpret.A;
parameter
interpret.result -> prediction;
data
access weather_database -> future.wdb;
endPredict_Weather.others;
|
||||||||||