3.10. Annex C: Systems Programming

Q: C.1(3-5): Access to Machine Operations

The machine code or intrinsic support should allow access to all operations normally available to assembly language programmers for the target environment, including privileged instructions, if any.

Q: (continued)

The interfacing pragmas (see Annex B) should support interface to assembler; the default assembler should be associated with the convention identifier Assembler.

Q: (continued)

If an entity is exported to assembly language, then the implementation should allocate it at an addressable location, and should ensure that it is retained by the linking process, even if not otherwise referenced from the Ada code. The implementation should assume that any call to a machine code or assembler subprogram is allowed to read or update every object that is specified as exported.

Q: C.1(10-16): Access to Machine Operations

The implementation should ensure that little or no overhead is associated with calling intrinsic and machine-code subprograms.

Q: (continued)

It is recommended that intrinsic subprograms be provided for convenient access to any machine operations that provide special capabilities or efficiency and that are not otherwise available through the language constructs.

Q: (continued)

Atomic read-modify-write operations -- e.g., test and set, compare and swap, decrement and test, enqueue/dequeue.

Q: (continued)

Standard numeric functions -- e.g., sin, log.

Q: (continued)

String manipulation operations -- e.g., translate and test.

Q: (continued)

Vector operations -- e.g., compare vector against thresholds.

Q: (continued)

Direct operations on I/O ports.

Q: C.3(28): Interrupt Support

If the Ceiling_Locking policy is not in effect, the implementation should provide means for the application to specify which interrupts are to be blocked during protected actions, if the underlying system allows for a finer-grain control of interrupt blocking.

Q: C.3.1(20-21): Protected Procedure Handlers

Whenever possible, the implementation should allow interrupt handlers to be called directly by the hardware.

Q: (continued)

Whenever practical, violations of any implementation-defined restrictions should be detected before run time.

Q: C.3.2(25): Package Interrupts

If implementation-defined forms of interrupt handler procedures are supported, such as protected procedures with parameters, then for each such form of a handler, a type analogous to Parameterless_Handler should be specified in a child package of Interrupts, with the same operations as in the predefined package Interrupts.

Q: C.4(14): Pre-elaboration Requirements

It is recommended that pre-elaborated packages be implemented in such a way that there should be little or no code executed at run time for the elaboration of entities not already covered by the Implementation Requirements.

Q: C.5(8): Pragma Discard_Names

If the pragma applies to an entity, then the implementation should reduce the amount of storage used for storing names associated with that entity.

Q: C.7.2(30): The Package Task_Attributes

Some implementations are targeted to domains in which memory use at run time must be completely deterministic. For such implementations, it is recommended that the storage for task attributes will be pre-allocated statically and not from the heap. This can be accomplished by either placing restrictions on the number and the size of the task's attributes, or by using the pre-allocated storage for the first N attribute objects, and the heap for the others. In the latter case, N should be documented.