J.7 At Clauses
This Reference Manual output has not been verified, and may contain omissions or errors. Report any problems on the tracking issue
Syntax
1at_clause ::= for direct_name use at expression;
Static Semantics
2An at_clause of the form “for x use at y;” is equivalent to an attribute_definition_clause of the form “for x'Address use y;”.
The preferred syntax for specifying the address of an entity is an attribute_definition_clause specifying the Address attribute. Therefore, the special-purpose at_clause syntax is now obsolete.
The above equivalence implies, for example, that only one at_clause is allowed for a given entity. Similarly, it is illegal to give both an at_clause and an attribute_definition_clause specifying the Address attribute.
Extensions to Ada 83
We now allow to define the address of an entity using an attribute_definition_clause. This is because Ada 83's at_clause is so hard to remember: programmers often tend to write “for X'Address use...;”.
Wording Changes from Ada 83
Ada 83's address_clause is now called an at_clause to avoid confusion with the new term “Address clause” (that is, an attribute_definition_clause for the Address attribute).
J.7.1 Interrupt Entries
1[Implementations are permitted to allow the attachment of task entries to interrupts via the address clause. Such an entry is referred to as an interrupt entry.
The address of the task entry corresponds to a hardware interrupt in an implementation-defined manner. (See Ada.Interrupts.Reference in C.3.2.)]
Static Semantics
3The following attribute is defined:
For any task entry X:
X'Address
- For a task entry whose address is specified (an interrupt entry), the value refers to the corresponding hardware interrupt. For such an entry, as for any other task entry, the meaning of this value is implementation defined. The value of this attribute is of the type of the subtype System.Address.
- Address may be specified for single entries via an
attribute_definition_clause.
Because of the equivalence of at_clauses and attribute_definition_clauses, an interrupt entry may be specified via either notation.
Dynamic Semantics
7As part of the initialization of a task object, the address clause for an interrupt entry is elaborated[, which evaluates the expression of the address clause]. A check is made that the address specified is associated with some interrupt to which a task entry may be attached. If this check fails, Program_Error is raised. Otherwise, the interrupt entry is attached to the interrupt associated with the specified address.
Upon finalization of the task object, the interrupt entry, if any, is detached from the corresponding interrupt and the default treatment is restored.
While an interrupt entry is attached to an interrupt, the interrupt is reserved (see C.3).
An interrupt delivered to a task entry acts as a call to the entry issued by a hardware task whose priority is in the System.Interrupt_Priority range. It is implementation defined whether the call is performed as an ordinary entry call, a timed entry call, or a conditional entry call; which kind of call is performed can depend on the specific interrupt.
Bounded (Run-Time) Errors
11It is a bounded error to evaluate E'Caller (see C.7.1) in an accept_statement for an interrupt entry. The possible effects are the same as for calling Current_Task from an entry body.
Documentation Requirements
12The implementation shall document to which interrupts a task entry may be attached.
Documentation Requirement: The interrupts to which a task entry may be attached.
The implementation shall document whether the invocation of an interrupt entry has the effect of an ordinary entry call, conditional call, or a timed call, and whether the effect varies in the presence of pending interrupts.
Documentation Requirement: The type of entry call invoked for an interrupt entry.
Implementation Permissions
14The support for this subclause is optional.
Interrupts to which the implementation allows a task entry to be attached may be designated as reserved for the entire duration of program execution[; that is, not just when they have an interrupt entry attached to them].
{8652/0077} Interrupt entry calls may be implemented by having the hardware execute directly the appropriate accept_statement. Alternatively, the implementation is allowed to provide an internal interrupt handler to simulate the effect of a normal task calling the entry.
The implementation is allowed to impose restrictions on the specifications and bodies of tasks that have interrupt entries.
It is implementation defined whether direct calls (from the program) to interrupt entries are allowed.
If a select_statement contains both a terminate_alternative and an accept_alternative for an interrupt entry, then an implementation is allowed to impose further requirements for the selection of the terminate_alternative in addition to those given in 9.3.
NOTE 1 {8652/0077} Queued interrupts correspond to ordinary entry calls. Interrupts that are lost if not immediately processed correspond to conditional entry calls. It is a consequence of the priority rules that an accept_statement executed in response to an interrupt can be executed with the active priority at which the hardware generates the interrupt, taking precedence over lower priority tasks, without a scheduling action.
NOTE 2 Control information that is supplied upon an interrupt can be passed to an associated interrupt entry as one or more parameters of mode in.
Examples
22Example of an interrupt entry:
task Interrupt_Handler is
entry Done;
for Done'Address use Ada.Interrupts.Reference(Ada.Interrupts.Names.Device_Done);
end Interrupt_Handler;
Wording Changes from Ada 83
RM83-13.5.1 did not adequately address the problems associated with interrupts. This feature is now obsolescent and is replaced by the Ada 95 interrupt model as specified in the Systems Programming Annex.