PowerAda 2

From OC Systems Wiki!
< PowerAda:APPENDIX C. Implementation Characteristics‎ | Annex M
Revision as of 00:35, 25 April 2019 by imported>WikiVisor (Text replacement - """ to """)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


From 1.1.3, Conformity of an Implementation with the Standard,

(20) If an implementation detects the use of an unsupported Specialized Needs Annex feature at run time, it should raise Program_Error if feasible. ===
RECOMMENDATION FOLLOWED
In general, for the Annexes that PowerAda does not support, the compiler will report use of unsupported features at compile time.

(21) If an implementation wishes to provide implementation-defined extensions to the functionality of a language-defined library unit, it should normally do so by adding children to the library unit.
RECOMMENDATION FOLLOWED

From 1.1.5 Classification of Errors

(12) If an implementation detects a bounded error or erroneous execution, it should raise Program_Error.
RECOMMENDATION FOLLOWED

From 2.8, Pragmas:

(16) Normally, implementation-defined pragmas should have no semantic effect for error-free programs; that is, if the implementation-defined pragmas are removed from a working program, the program should still be legal, and should still have the same semantics.
RECOMMENDATION FOLLOWED

(17) Normally, an implementation should not define pragmas that can make an illegal program legal, except as follows

(18) A pragma used to complete a declaration, such as a pragma Import;

(19) A pragma used to configure the environment by adding, removing, or replacing library_items.
RECOMMENDATION FOLLOWED

From 3.5.2 Character Types:

(5) If an implementation supports a mode with alternative interpretations for Character and Wide_Character, the set of graphic characters of Character should nevertheless remain a proper subset of the set of graphic characters of Wide_Character. Any character set ``localizations" should be reflected in the results of the subprograms defined in the language-defined package Characters.Handling (See A.3) available in such a mode. In a mode with an alternative interpretation of Character, the implementation should also support a corresponding change in what is a legal identifier_letter.
RECOMMENDATION NOT APPLICABLE
No alternative mode is supported.

From 3.5.4 Integer Types:

(28) An implementation should support Long_Integer in addition to Integer if the target machine supports 32-bit (or longer) arithmetic. No other named integer subtypes are recommended for package Standard. Instead, appropriate named integer subtypes should be provided in the library package Interfaces (See B.2).
RECOMMENDATION NOT FOLLOWED
Long_Integer is supported, but the following integer subtypes are also supported in package STANDARD:
type SHORT_SHORT_INTEGER
        is range -128 .. 127;
type SHORT_INTEGER
        is range -32768 .. 32767;

SHORT_INTEGER and SHORT_SHORT_INTEGER are defined in package STANDARD for backwards compatibility. Users are encouraged to use INTEGER_8 and INTEGER_16 in package INTERFACES to ensure portability.

(29) An implementation for a two's complement machine should support modular types with a binary modulus up to System.Max_Int*2+2. An implementation should support a non-binary modulus up to Integer'Last.
RECOMMENDATION FOLLOWED

From package System:

Max_Binary_Modulus    : CONSTANT := 2 ** Long_Integer'Size;
Max_Nonbinary_Modulus : CONSTANT := Max_Int;

From 3.5.5 Operations of Discrete Types:

(8) For the evaluation of a call on S'Pos for an enumeration subtype, if the value of the operand does not correspond to the internal code for any enumeration literal of its type (perhaps due to an uninitialized variable), then the implementation should raise Program_Error. This is particularly important for enumeration types with noncontiguous internal codes specified by an enumeration_representation_clause.
RECOMMENDATION NOT FOLLOWED
No exception is raised if operand to 'Pos does not correspond to internal code for any enumeration literal. The result is undefined.

From 3.5.7 Floating Point Types:

(17) An implementation should support Long_Float in addition to Float if the target machine supports 11 or more digits of precision. No other named floating point subtypes are recommended for package Standard. Instead, appropriate named floating point subtypes should be provided in the library package Interfaces (

See B.2).

RECOMMENDATION FOLLOWED

From 3.6.2 Operations of Array Types:

(11) An implementation should normally represent multidimensional arrays in row-major order, consistent with the notation used for multidimensional array aggregates (See 4.3.3). However, if a pragma Convention( Fortran, ...) applies to a multidimensional array type, then column-major order should be used instead (See B.5, ``Interfacing with Fortran).
RECOMMENDATION NOT FOLLOWED
Column-major order is not supported.

From 9.6 Delay Statements, Duration, and Time:

(30) Whenever possible in an implementation, the value of Duration'Small should be no greater than 100 microseconds.
RECOMMENDATION FOLLOWED
Duration'Small = 61 microseconds

(31) The time base for delay_relative_statements should be monotonic; it need not be the same time base as used for Calendar.Clock.
RECOMMENDATION FOLLOWED

From 10.2.1 Elaboration Control,

(12) In an implementation, a type declared in a preelaborated package should have the same representation in every elaboration of a given version of the package, whether the elaborations occur in distinct executions of the same program, or in executions of distinct programs or partitions that include the given version.
RECOMMENDATION FOLLOWED

From 11.4.1 The Package Exceptions,

(19) Exception_Message (by default) and Exception_Information should produce information useful for debugging. Exception_message should be short (about one line), whereas Exception_Information can be long. Exception_Message should not include the Exception_Name. Exception_Information should include both the Exception_Name and the Exception_Message.
RECOMMENDATION FOLLOWED

From 11.5 Suppressing Checks

(28) The implementation should minimize the code executed for checks that have been suppressed.
RECOMMENDATION FOLLOWED

From 13.1 Representation Items

(22) An implementation need not support representation items containing nonstatic expressions, except that an implementation should support a representation item for a given entity if each nonstatic expression in the representation item is a name that statically denotes a constant declared before the entity.
RECOMMENDATION FOLLOWED

(23) An implementation need not support a specification for the Size for a given composite subtype, nor the size or storage place for an object (including a component) of a given composite subtype, unless the constraints on the subtype and its composite subcomponents (if any) are all static constraints.
RECOMMENDATION FOLLOWED

(24) An aliased component, or a component whose type is by-reference, should always be allocated at an addressable location.
RECOMMENDATION FOLLOWED

From 13.2 Pragma Pack:

(6) If a type is packed, then the implementation should try to minimize storage allocated to objects of the type, possibly at the expense of speed of accessing components, subject to reasonable complexity in addressing calculations.
RECOMMENDATION FOLLOWED

(7) The recommended level of support for pragma Pack is

  • (8) For a packed record type, the components should be packed as tightly as possible subject to the Sizes of the component subtypes, and subject to any record_representation_clause that applies to the type; the implementation may, but need not, reorder components or cross aligned word boundaries to improve the packing. A component whose Size is greater than the word size may be allocated an integral number of words.
RECOMMENDATION FOLLOWED

  • (9) For a packed array type, if the component subtype's Size is less than or equal to the word size, and Component_Size is not specified for the type, Component_Size should be less than or equal to the Size of the component subtype, rounded up to the nearest factor of the word size.
RECOMMENDATION NOT FOLLOWED
In the absence of a Component_Size clause packed arrays are always packed as tightly as possible (i.e.. the size of the component is not rounded up to the nearest factor of the word size). Note that a Component_Size clause can be used to achieve the recommended effect. If an application requires a given component size then a Component_Size clause should be used to insure portability.

From 13.3 Representation Attributes:

(14) For an array X, X'Address should point at the first component of the array, and not at the array bounds.
RECOMMENDATION NOT FOLLOWED
In some cases PowerAda will attach an 8 byte "dope vector" to the front of the memory allocated to an array. X'Address will return the address of the first 4 bytes of this dope vector. The dope vector is used when the array type is unconstrained and the array object is allocated from the heap.
Programs should use X(X'first)'Address to address the first element of an array to guarantee portability.

(15) The recommended level of support for the Address attribute is

(16) X'Address should produce a useful result if X is an object that is aliased or of a by-reference type, or is an entity whose Address has been specified.
RECOMMENDATION FOLLOWED

(17) An implementation should support Address clauses for imported subprograms.
RECOMMENDATION FOLLOWED
If an address is specified PowerAda will create a subprogram value object and place the specified address in the subprogram value. Calls to the imported subprogram will be made using the subprogram value. It is up to the programmer to insure the address being used in the subprogram value is a legal address to branch to.

(18) Objects (including subcomponents) that are aliased or of a by-reference type should be allocated on storage element boundaries.
RECOMMENDATION FOLLOWED

(19) If the Address of an object is specified, or it is imported or exported, then the implementation should not perform optimizations based on assumptions of no aliases.
RECOMMENDATION FOLLOWED

(29) The recommended level of support for the Alignment attribute for subtypes is

(30) An implementation should support specified Alignments that are factors and multiples of the number of storage elements per word, subject to the following

(31) An implementation need not support specified Alignments for combinations of Sizes and Alignments that cannot be easily loaded and stored by available machine instructions.
RECOMMENDATION FOLLOWED
All alignments must be powers of two. Alignments that are less restrictive then the natural alignment are ignored (e.g.. specifying an alignment of 4 for a long_float type (natural alignment of 8) will be ignored).

(32) An implementation need not support specified Alignments that are greater than the maximum Alignment the implementation ever returns by default.
RECOMMENDATION FOLLOWED
The maximum specifiable alignment in PowerAda is 8. Hence the only specifiable alignments are 1, 2, 4, and 8 (bytes).

(33) The recommended level of support for the Alignment attribute for objects is

(34) Same as above, for subtypes, but in addition
RECOMMENDATION FOLLOWED

(35) For stand-alone library-level objects of statically constrained subtypes, the implementation should support all Alignments supported by the target linker. For example, page alignment is likely to be supported for such objects, but not for subtypes.
RECOMMENDATION FOLLOWED

(42) The recommended level of support for the Size attribute of objects is

(43) A Size clause should be supported for an object if the specified Size is at least as large as its subtype's Size, and corresponds to a size in storage elements that is a multiple of the object's Alignment (if the Alignment is nonzero).
RECOMMENDATION FOLLOWED

(50) If the Size of a subtype is specified, and allows for efficient independent addressability (See 9.10) on the target architecture, then the Size of the following objects of the subtype should equal the Size of the subtype

(51) Aliased objects (including components).
RECOMMENDATION FOLLOWED

(52) Unaliased components, unless the Size of the component is determined by a component_clause or Component_Size clause.
RECOMMENDATION FOLLOWED

(53) A Size clause on a composite subtype should not affect the internal layout of components.
RECOMMENDATION FOLLOWED

(54) The recommended level of support for the Size attribute of subtypes is

(55) The Size (if not specified) of a static discrete or fixed point subtype should be the number of bits needed to represent each value belonging to the subtype using an unbiased representation, leaving space for a sign bit only if the subtype contains negative values. If such a subtype is a first subtype, then an implementation should support a specified Size for it that reflects this representation.
RECOMMENDATION FOLLOWED

(56) For a subtype implemented with levels of indirection, the Size should include the size of the pointers, but not the size of what they point at.
RECOMMENDATION FOLLOWED

(71) The recommended level of support for the Component_Size attribute is

(72) An implementation need not support specified Component_Sizes that are less than the Size of the component subtype.
RECOMMENDATION FOLLOWED

(73) An implementation should support specified Component_Sizes that are factors and multiples of the word size. For such Component_Sizes, the array should contain no gaps between components. For other Component_Sizes (if supported), the array should contain no gaps between components when packing is also specified; the implementation should forbid this combination in cases where it cannot support a no-gaps representation.
RECOMMENDATION FOLLOWED

From 13.4 Enumeration Representation Clauses:

(9) The recommended level of support for enumeration_representation_clauses is

  • (10) An implementation should support at least the internal codes in the range System.Min_Int..System.Max_Int. An implementation need not support enumeration_representation_clauses for boolean types.
RECOMMENDATION FOLLOWED
PowerAda does not support enumeration_representation_clauses for boolean types.

From 13.5.1 Record Representation Clauses:

(17) The recommended level of support for record_representation_clauses is

  • (18) An implementation should support storage places that can be extracted with a load, mask, shift sequence of machine code, and set with a load, shift, mask, store sequence, given the available machine instructions and run-time model.
RECOMMENDATION FOLLOWED

  • (19) A storage place should be supported if its size is equal to the Size of the component subtype, and it starts and ends on a boundary that obeys the Alignment of the component subtype.
RECOMMENDATION FOLLOWED

  • (20) If the default bit ordering applies to the declaration of a given type, then for a component whose subtype's Size is less than the word size, any storage place that does not cross an aligned word boundary should be supported.
RECOMMENDATION FOLLOWED

  • (21) An implementation may reserve a storage place for the tag field of a tagged type, and disallow other components from overlapping that place.
RECOMMENDATION FOLLOWED
The tag field is reserved as permitted.

  • (22) An implementation need not support a component_clause for a component of an extension part if the storage place is not after the storage places of all components of the parent type, whether or not those storage places had been specified.
RECOMMENDATION FOLLOWED

From 13.5.2 Storage Place Attributes:

(5) If a component is represented using some form of pointer (such as an offset) to the actual data of the component, and this data is contiguous with the rest of the object, then the storage place attributes should reflect the place of the actual data, not the pointer. If a component is allocated discontiguously from the rest of the object, then a warning should be generated upon reference to one of its storage place attributes.
RECOMMENDATION FOLLOWED
Components are never allocated discontiguously.

From 13.5.3 Bit Ordering:

(7) The recommended level of support for the nondefault bit ordering is

  • (8) If Word_Size = Storage_Unit, then the implementation should support the nondefault bit ordering in addition to the default bit ordering.
RECOMMENDATION NOT APPLICABLE.

From package System:

        Storage_Unit : CONSTANT := 8;
        Word_Size    : CONSTANT := 32;

From 13.7 The Package System:

(37) Address should be of a private type.
RECOMMENDATION FOLLOWED

From 13.7.1 The Package System.Storage_Elements:

(16) Operations in System and its children should reflect the target environment semantics as closely as is reasonable. For example, on most machines, it makes sense for address arithmetic to "wrap around". Operations that do not make sense should raise Program_Error.
RECOMMENDATION NOT FOLLOWED
System.Address is not a modular type.

From 13.9 Unchecked Type Conversions:

(14) The Size of an array object should not include its bounds; hence, the bounds should not be part of the converted data.
RECOMMENDATION FOLLOWED

(15) The implementation should not generate unnecessary run-time checks to ensure that the representation of S is a representation of the target type. It should take advantage of the permission to return by reference when possible. Restrictions on unchecked conversions should be avoided unless required by the target environment.
RECOMMENDATION FOLLOWED

(16) The recommended level of support for unchecked conversions is

  • (17) Unchecked conversions should be supported and should be reversible in the cases where this clause defines the result. To enable meaningful use of unchecked conversion, a contiguous representation should be used for elementary subtypes, for statically constrained array subtypes whose component subtype is one of the subtypes described in this paragraph, and for record subtypes without discriminants whose component subtypes are described in this paragraph.
RECOMMENDATION FOLLOWED

From 13.11 Storage Management:

(23) An implementation should document any cases in which it dynamically allocates heap storage for a purpose other than the evaluation of an allocator.
RECOMMENDATION FOLLOWED

From Chapter 8, "How a PowerAda Program Arranges its Memory":

The evaluation of the Ada new statement reserves some memory from the heap. The access variables in your program refer to objects that are allocated this way from the heap. UNCHECKED_DEALLOCATION operations return memory to the heap. Programs also use the heap to manage objects, such as arrays with variable bounds, whose size the compiler cannot determine at compile time; the program refers to these objects through access variables, even though these variables might not appear in your source code.

(24) A default (implementation-provided) storage pool for an access-to- constant type should not have overhead to support deallocation of individual objects.
RECOMMENDATION NOT APPLICABLE.
There is no separate storage pool for access-to-constant types.

(25) A storage pool for an anonymous access type should be created at the point of an allocator for the type, and be reclaimed when the designated object becomes inaccessible.
RECOMMENDATION NOT FOLLOWED
There is no storage pool created for anonymous access types.

From 13.11.2 Unchecked Storage Deallocation:

(17) For a standard storage pool, Free should actually reclaim the storage.
RECOMMENDATION FOLLOWED

From 13.13.2 Stream-Oriented Attributes:

(17) If a stream element is the same size as a storage element, then the normal in-memory representation should be used by Read and Write for scalar objects. Otherwise, Read and Write should use the smallest number of stream elements needed to represent all values in the base range of the scalar type.
RECOMMENDATION FOLLOWED

From A.1 The Package Standard

(52) If an implementation provides additional named predefined integer types, then the names should end with "Integer" as in "Long_Integer". If an implementation provides additional named predefined floating point types, then the names should end with "Float" as in "Long_Float".
RECOMMENDATION FOLLOWED

From A.3.2 The Package Characters.Handling

(47) If an implementation provides a localized definition of Character or Wide_Character, then the effects of the subprograms in Characters.Handling should reflect the localizations. See also 3.5.2.
RECOMMENDATION FOLLOWED
PowerAda does not provide a localized definition of Character.

From A.4.4 Bounded-Length String Handling

(106) Bounded string objects should not be implemented by implicit pointers and dynamic allocation.
RECOMMENDATION FOLLOWED

From A.5.2 Random Number Generation:

(46) Any storage associated with an object of type Generator should be reclaimed on exit from the scope of the object.
RECOMMENDATION FOLLOWED

(47) If the generator period is sufficiently long in relation to the number of distinct initiator values, then each possible value of Initiator passed to Reset should initiate a sequence of random numbers that does not, in a practical sense, overlap the sequence initiated by any other value. If this is not possible, then the mapping between initiator values and generator states should be a rapidly varying function of the initiator value.
RECOMMENDATION FOLLOWED

From A.10.7 Input-Output of Characters and Strings:

(23) The Get_Immediate procedures should be implemented with unbuffered input. For a device such as a keyboard, input should be ``available" if a key has already been typed, whereas for a disk file, input should always be available except at end of file. For a file associated with a keyboard-like device, any line-editing features of the underlying operating system should be disabled during the execution of Get_Immediate.
RECOMMENDATION FOLLOWED

From B.1 Interfacing Pragmas:

(39) If an implementation supports pragma Export to a given language, then it should also allow the main subprogram to be written in that language. It should support some mechanism for invoking the elaboration of the Ada library units included in the system, and for invoking the finalization of the environment task. On typical systems, the recommended mechanism is to provide two subprograms whose link names are "adainit" and "adafinal". Adainit should contain the elaboration code for library units. Adafinal should contain the finalization code. These subprograms should have no effect the second and subsequent time they are called.
RECOMMENDATION FOLLOWED
adainit and adafinal are supported.

(40) Automatic elaboration of preelaborated packages should be provided when pragma Export is supported.
RECOMMENDATION FOLLOWED

(41) For each supported convention L other than Intrinsic, an implementation should support Import and Export pragmas for objects of L-compatible types and for subprograms, and pragma Convention for L-eligible types and for subprograms, presuming the other language has corresponding features. Pragma Convention need not be supported for scalar types.
RECOMMENDATION FOLLOWED

From B.2 The Package Interfaces:

(12) For each implementation-defined convention identifier, there should be a child package of package Interfaces with the corresponding name. This package should contain any declarations that would be useful for interfacing to the language (implementation) represented by the convention. Any declarations useful for interfacing to any language on the given hardware architecture should be provided directly in Interfaces.
RECOMMENDATION FOLLOWED

(13) An implementation supporting an interface to C, COBOL, or Fortran should provide the corresponding package or packages described in the following clauses.
RECOMMENDATION FOLLOWED

From B.3 Interfacing with C:

(63) An implementation should support the following interface correspondences between Ada and C.

(64) An Ada procedure corresponds to a void-returning C function.
RECOMMENDATION FOLLOWED

(65) An Ada function corresponds to a non-void C function.
RECOMMENDATION FOLLOWED

(66) An Ada in scalar parameter is passed as a scalar argument to a C function.
RECOMMENDATION FOLLOWED

(67) An Ada in parameter of an access-to-object type with designated type T is passed as a t* argument to a C function, where t is the C type corresponding to the Ada type T.
RECOMMENDATION FOLLOWED

(68) An Ada access T parameter, or an Ada out or in out parameter of an elementary type T, is passed as a t* argument to a C function, where t is the C type corresponding to the Ada type T. In the case of an elementary out or in out parameter, a pointer to a temporary copy is used to preserve by-copy semantics.
RECOMMENDATION FOLLOWED

(69) An Ada parameter of a record type T, of any mode, is passed as a t* argument to a C function, where t is the C struct corresponding to the Ada type T.
RECOMMENDATION FOLLOWED
The user must ensure C struct layout corresponds to Ada record.

(70) An Ada parameter of an array type with component type T, of any mode, is passed as a t* argument to a C function, where t is the C type corresponding to the Ada type T.
RECOMMENDATION FOLLOWED

(71) An Ada parameter of an access-to-subprogram type is passed as a pointer to a C function whose prototype corresponds to the designated subprogram's specification.
RECOMMENDATION FOLLOWED

From B.4 Interfacing with COBOL:

(95) An Ada implementation should support the following interface correspondences between Ada and COBOL.

(96) An Ada access T parameter is passed as a BY REFERENCE data item of the COBOL type corresponding to T.
RECOMMENDATION NOT APPLICABLE.
No interface to COBOL is provided.

(97) An Ada in scalar parameter is passed as a ``BY CONTENT data item of the corresponding COBOL type.
RECOMMENDATION NOT APPLICABLE.
No interface to COBOL is provided.

(98) Any other Ada parameter is passed as a ``BY REFERENCE data item of the COBOL type corresponding to the Ada parameter type; for scalars, a local copy is used if necessary to ensure by-copy semantics.
RECOMMENDATION NOT APPLICABLE.
No interface to COBOL is provided.

From B.5 Interfacing with Fortran:

(22) An Ada implementation should support the following interface correspondences between Ada and Fortran
No interface to FORTRAN is provided.

(23) An Ada procedure corresponds to a Fortran subroutine.
No interface to FORTRAN is provided.

(24) An Ada function corresponds to a Fortran function.
No interface to FORTRAN is provided.

(25) An Ada parameter of an elementary, array, or record type T is passed as a Tf argument to a Fortran procedure, where Tf is the Fortran type corresponding to the Ada type T, and where the INTENT attribute of the corresponding dummy argument matches the Ada formal parameter mode; the Fortran implementation's parameter passing conventions are used. For elementary types, a local copy is used if necessary to ensure by-copy semantics.
No interface to FORTRAN is provided.

(26) An Ada parameter of an access-to-subprogram type is passed as a reference to a Fortran procedure whose interface corresponds to the designated subprogram's specification.
No interface to FORTRAN is provided.

From C.1 Access to Machine Operations

(3) The machine code or intrinsics support should allow access to all operations normally available to assembly language programmers for the target environment, including privileged instructions, if any.
RECOMMENDATION NOT FOLLOWED
OC Systems does not yet support intrinsic access to machine operations.

(4)The interfacing pragmas (see Annex B) should support interface to assembler; the default assembler should be associated with the convention identifier Assembler.
RECOMMENDATION NOT FOLLOWED
Interface to assembler is not supported.

(5) 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.
RECOMMENDATION NOT FOLLOWED
Interface to assembler is not supported. However objects exported to C or declared as ALIASED are not optimized away.

(10) The implementation should ensure that little or no overhead is associated with calling intrinsic and machine-code subprograms.
RECOMMENDATION FOLLOWED
(11) 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.
RECOMMENDATION FOLLOWED

From C.3 Interrupt Support

(28) 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.
RECOMMENDATION FOLLOWED
Ceiling_Locking is always in effect.

From C.3.1 Protected Procedure Handlers

(20) Whenever possible, the implementation should allow interrupt handlers to be called directly by the hardware.
RECOMMENDATION NOT FOLLOWED
AIX does not allow hardware to signal user code directly.

(21) Whenever practical, the implementation should detect violations of any implementation-defined restrictions before run time.
RECOMMENDATION FOLLOWED
Specifying Pragma Attach_Handler with a signal that is out of the range 0..63 will cause the compiler to issue a warning.

From C.3.2 The Package Interrupts

(25) 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 the predefined package Interrupts.
RECOMMENDATION FOLLOWED
There are no implementation-defined forms of interrupt handler procedures.

From C.4 Preelaboration Requirements

(14) It is recommended that preelaborated 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.
RECOMMENDATION FOLLOWED

From C.5 Pragma Discard_Names

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

From C.7.2 The Package Task_Attributes

(30) 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 he 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 attributes objects, and the heap for the others. In the latter case, N should be documented.
RECOMMENDATION NOT FOLLOWED
All attributes are allocated from the heap.

From D.3 Priority Ceiling Locking

(17) The implementation should use names that end with "_Locking" for implementation-defined locking policies.
RECOMMENDATION FOLLOWED
There are no implementation-defined locking policies.

From D.4 Entry Queuing Policies

(16) The implementation should use names that end with "_Queuing" for implementation-defined queuing policies.
RECOMMENDATION FOLLOWED
There are no implementation-defined queuing policies.

From D.6 Preemptive Abort

(9) Even though the abort_statement is included in the list of potentially blocking operations (see 9.5.1), it is recommended that this statement be implemented in a way that never requires the task executing the abort_statement to block.
RECOMMENDATION FOLLOWED

(10) On a multi-processor, the delay associated with aborting a task on another processor should be bounded; the implementation should use periodic polling, if necessary, to achieve this.
RECOMMENDATION FOLLOWED
PowerAda uses POSIX signals to abort running tasks.

From D.7 Tasking Restrictions

(21) When feasible, the implementation should take advantage of the specified restrictions to produce a more efficient implementation.
RECOMMENDATION NOT FOLLOWED
The following restrictions are checked and, if violated, a SEMANTIC ERROR is reported at bind time:
NO_TASK_HIERARCHY
NO_NESTED_FINALIZATION
NO_ABORT_STATEMENTS
NO_TERMINATE_ALTERNATIVES
NO_TASK_ALLOCATORS
NO_DYNAMIC_PRIORITIES
NO_ASYNCHRONOUS_CONTROL
MAX_SELECT_ALTERNATIVES
MAX_TASK_ENTRIES
MAX_PROTECTED_ENTRIES

From D.8 Monotonic Time

(47) When appropriate, implementations should provide configuration mechanisms to change the value of Tick.
RECOMMENDATION FOLLOWED
It is not appropriate.

(48) It is recommended that Calendar.Clock and Real_Time.Clock be implemented as transformations of the same time base.
RECOMMENDATION FOLLOWED

(49) It is recommended that the "best" time base which exists in the underlying system be available to the application through Clock. "Best" may mean highest accuracy or largest range.
RECOMMENDATION FOLLOWED
PowerAda uses the POSIX call Gettimeofday to get the number of seconds and nanoseconds since January 1, 1970. This value is converted to what ever value is required.

From E.5 Partition Communication Subsystem

(28) Whenever possible, the PCS on the called partition should allow for multiple tasks to call the RPC-receiver with different messages and should allow them to block until the corresponding subprogram body returns.
ANNEX E IS NOT IMPLEMENTED
(29) The Write operation on the stream of type Params_Stream_type should raise Storage_Error if it runs out of space trying to write the Item into the stream.
ANNEX E IS NOT IMPLEMENTED

From F Information Systems

(7) If COBOL (respectively, C) is widely supported in the target environment, implementations supporting the Information Systems Annex should provide the child package Interfaces. COBOL (respectively, Interfaces.C) specified in Annex B and should support a convention_identifier of COBOL (respectively, C) in the interfacing pragmas (see Annex B), thus allowing Ada programs to interface with programs written in that language.
ANNEX F IS NOT SUPPORTED

From F.1 Machine_Radix Attribute Definition Clause

(2) Packed decimal should be used as the internal representation for objects of subtype S when S'Machine_Radix=10.
ANNEX F IS NOT SUPPORTED

From G Numerics:

(7) If Fortran (respectively, C) is widely supported in the target environment, implementations supporting the Numerics Annex should provide the child package Interfaces.Fortran (respectively, Interfaces.C) specified in Annex B and should support a convention_identifier of Fortran (respectively, C) in the interfacing pragmas (see Annex B), thus allowing Ada programs to interface with programs written in that language.
RECOMMENDATION NOT FOLLOWED
Convention Fortran is not supported.

From G.1.1 Complex Types:

(56) Because the usual mathematical meaning of multiplication of a complex operand and a real operand is that of the scaling of both components of the former by the latter, an implementation should not perform this operation by first promoting the real operand to complex type and then performing a full complex multiplication. In systems that, in the future, support an Ada binding to IEC 559
1989, the latter technique will not generate the required result when one of the components of the complex operand is infinite. (Explicit multiplication of the infinite component by the zero component obtained during promotion yields a NaN that propagates into the final result.) Analogous advice applies in the case of multiplication of a complex operand and a pure-imaginary operand, and in the case of division of a complex operand by a real or pure-imaginary operand.
RECOMMENDATION FOLLOWED
(57) Likewise, because the usual mathematical meaning of addition of a complex operand and a real operand is that the imaginary operand remains unchanged, an implementation should not perform this operation by first

  • promoting the real operand to complex type and then performing a full complex addition. In implementations in which the Signed_Zeros attribute of the component type is True (and which therefore conform to IEC 559:1989 in regard to the handling of the sign of zero in predefined arithmetic operations), the latter technique will not generate the required result when the imaginary component of the complex operand is a negatively signed zero. (Explicit addition of the negative zero to the zero obtained during promotion yields a positive zero.) Analogous advice applies in the case of addition of a complex operand and a pure-imaginary operand, and in the case of subtraction of a complex operand and a real or pure-imaginary operand.
RECOMMENDATION FOLLOWED

(58) Implementations in which Real'Signed_Zeros is True should attempt to provide a rational treatment of the signs of zero results and result components. As one example, the result of the Argument function should have the sign of the imaginary component of the parameter X when the point represented by that parameter lies on the positive real axis; as another, the sign of the imaginary component of the Compose_From_Polar function should be the same as (resp., the opposite of) that of the Argument parameter when that parameter has a value of zero and the Modulus parameter has a nonnegative (resp., negative) value.
RECOMMENDATION FOLLOWED

From G.1.2 Complex Elementary Functions

(49) Implementations in which Complex_Types.Real'Signed_Zeros is True should attempt to provide a rational treatment of the signs of zero results and result components. For example, many of the complex elementary functions have components that are odd functions of one of the parameter components; in these cases, the result component should have the sign of the parameter component at the origin. Other complex elementary functions have zero components whose sign is opposite that of a parameter component at the origin, or is always positive or always negative.
RECOMMENDATION FOLLOWED

From G.2.4 Accuracy Requirements for the Elementary Functions:

(19) The versions of the forward trigonometric functions without a Cycle parameter should not be implemented by calling the corresponding version with a Cycle parameter of 2.0*Numerics.Pi, since this will not provide the required accuracy in some portions of the domain. For the same reason, the version of Log without a Base parameter should not be implemented by calling the corresponding version with a Base parameter of Numerics.e.
RECOMMENDATION FOLLOWED

From G.2.6 Accuracy Requirements for Complex Arithmetic

(15) The version of the Compose_From_Polar function without a Cycle parameter should not be implemented by calling the corresponding version with a Cycle parameter of 2.0*Numerics.Pi, since this will not provide the required accuracy in some portions of the domain.
RECOMMENDATION FOLLOWED

From H.1 Pragma Normalize_Scalars

(6) Whenever possible, the implicit initial value for a scalar subtype should be an invalid representation (see 13.9.1).
Annex H is not supported.

(19) The implementation should provide the above information in both a human-readable and machine-readable form, and should document the latter so as to ease further processing by automated tools.
Annex H is not supported.
(20) Object code listing should be provided both in a symbolic format and also in an appropriate numeric format (such as hexadecimal or octal).
Annex H is not supported.