4 Implementation Defined Characteristics
In addition to the implementation dependent pragmas and attributes, and
the implementation advice, there are a number of other features of Ada
95 that are potentially implementation dependent. These are mentioned
throughout the Ada 95 Reference Manual, and are summarized in annex M.
A requirement for conforming Ada compilers is that they provide
documentation describing how the implementation deals with each of these
issues. In this chapter, you will find each point in annex M listed
followed by a description in italic font of how GNAT
handles the implementation dependence.
You can use this chapter as a guide to minimizing implementation
dependent features in your programs if portability to other compilers
and other operating systems is an important consideration. The numbers
in each section below correspond to the paragraph number in the Ada 95
Reference Manual.
2. Whether or not each recommendation given in Implementation
Advice is followed. See 1.1.2(37).
|
See Implementation Advice.
3. Capacity limitations of the implementation. See 1.1.3(3).
|
The complexity of programs that can be processed is limited only by the
total amount of available virtual memory, and disk space for the
generated object files.
4. Variations from the standard that are impractical to avoid
given the implementation's execution environment. See 1.1.3(6).
|
There are no variations from the standard.
5. Which code_statement s cause external
interactions. See 1.1.3(10).
|
Any code_statement
can potentially cause external interactions.
6. The coded representation for the text of an Ada
program. See 2.1(4).
|
See separate section on source representation.
7. The control functions allowed in comments. See 2.1(14).
|
See separate section on source representation.
8. The representation for an end of line. See 2.2(2).
|
See separate section on source representation.
9. Maximum supported line length and lexical element
length. See 2.2(15).
|
The maximum line length is 255 characters an the maximum length of a
lexical element is also 255 characters.
10. Implementation defined pragmas. See 2.8(14).
|
See Implementation Defined Pragmas.
11. Effect of pragma Optimize . See 2.8(27).
|
Pragma Optimize
, if given with a Time
or Space
parameter, checks that the optimization flag is set, and aborts if it is
not.
12. The sequence of characters of the value returned by
S'Image when some of the graphic characters of
S'Wide_Image are not defined in Character . See
3.5(37).
|
The sequence of characters is as defined by the wide character encoding
method used for the source. See section on source representation for
further details.
13. The predefined integer types declared in
Standard . See 3.5.4(25).
|
Short_Short_Integer
- 8 bit signed
Short_Integer
- (Short) 16 bit signed
Integer
- 32 bit signed
Long_Integer
- 64 bit signed (Alpha OpenVMS only)
32 bit signed (all other targets)
Long_Long_Integer
- 64 bit signed
14. Any nonstandard integer types and the operators defined
for them. See 3.5.4(26).
|
There are no nonstandard integer types.
15. Any nonstandard real types and the operators defined for
them. See 3.5.6(8).
|
There are no nonstandard real types.
16. What combinations of requested decimal precision and range
are supported for floating point types. See 3.5.7(7).
|
The precision and range is as defined by the IEEE standard.
17. The predefined floating point types declared in
Standard . See 3.5.7(16).
|
Short_Float
- 32 bit IEEE short
Float
- (Short) 32 bit IEEE short
Long_Float
- 64 bit IEEE long
Long_Long_Float
- 64 bit IEEE long (80 bit IEEE long on x86 processors)
18. The small of an ordinary fixed point type. See 3.5.9(8).
|
Fine_Delta
is 2**(−63)
19. What combinations of small, range, and digits are
supported for fixed point types. See 3.5.9(10).
|
Any combinations are permitted that do not result in a small less than
Fine_Delta
and do not result in a mantissa larger than 63 bits.
If the mantissa is larger than 53 bits on machines where Long_Long_Float
is 64 bits (true of all architectures except ia32), then the output from
Text_IO is accurate to only 53 bits, rather than the full mantissa. This
is because floating-point conversions are used to convert fixed point.
20. The result of Tags.Expanded_Name for types declared
within an unnamed block_statement . See 3.9(10).
|
Block numbers of the form B
nnn, where nnn is a
decimal integer are allocated.
21. Implementation-defined attributes. See 4.1.4(12).
|
See Implementation Defined Attributes.
22. Any implementation-defined time types. See 9.6(6).
|
There are no implementation-defined time types.
23. The time base associated with relative delays.
|
See 9.6(20). The time base used is that provided by the C library
function gettimeofday
.
24. The time base of the type Calendar.Time . See
9.6(23).
|
The time base used is that provided by the C library function
gettimeofday
.
25. The time zone used for package Calendar
operations. See 9.6(24).
|
The time zone used by package Calendar
is the current system time zone
setting for local time, as accessed by the C library function
localtime
.
26. Any limit on delay_until_statements of
select_statements . See 9.6(29).
|
There are no such limits.
27. Whether or not two non overlapping parts of a composite
object are independently addressable, in the case where packing, record
layout, or Component_Size is specified for the object. See
9.10(1).
|
Separate components are independently addressable if they do not share
overlapping storage units.
28. The representation for a compilation. See 10.1(2).
|
A compilation is represented by a sequence of files presented to the
compiler in a single invocation of the gcc
command.
29. Any restrictions on compilations that contain multiple
compilation_units. See 10.1(4).
|
No single file can contain more than one compilation unit, but any
sequence of files can be presented to the compiler as a single
compilation.
30. The mechanisms for creating an environment and for adding
and replacing compilation units. See 10.1.4(3).
|
See separate section on compilation model.
31. The manner of explicitly assigning library units to a
partition. See 10.2(2).
|
If a unit contains an Ada main program, then the Ada units for the partition
are determined by recursive application of the rules in the Ada Reference
Manual section 10.2(2-6). In other words, the Ada units will be those that
are needed by the main program, and then this definition of need is applied
recursively to those units, and the partition contains the transitive
closure determined by this relationship. In short, all the necessary units
are included, with no need to explicitly specify the list. If additional
units are required, e.g. by foreign language units, then all units must be
mentioned in the context clause of one of the needed Ada units.
If the partition contains no main program, or if the main program is in
a language other than Ada, then GNAT
provides the binder options -z
and -n
respectively, and in this case a
list of units can be explicitly supplied to the binder for inclusion in
the partition (all units needed by these units will also be included
automatically). For full details on the use of these options, refer to
the GNAT User's Guide sections on Binding and Linking.
32. The implementation-defined means, if any, of specifying
which compilation units are needed by a given compilation unit. See
10.2(2).
|
The units needed by a given compilation unit are as defined in
the Ada Reference Manual section 10.2(2-6). There are no
implementation-defined pragmas or other implementation-defined
means for specifying needed units.
33. The manner of designating the main subprogram of a
partition. See 10.2(7).
|
The main program is designated by providing the name of the
corresponding ALI file as the input parameter to the binder.
34. The order of elaboration of library_items . See
10.2(18).
|
The first constraint on ordering is that it meets the requirements of
chapter 10 of the Ada 95 Reference Manual. This still leaves some
implementation dependent choices, which are resolved by first
elaborating bodies as early as possible (i.e. in preference to specs
where there is a choice), and second by evaluating the immediate with
clauses of a unit to determine the probably best choice, and
third by elaborating in alphabetical order of unit names
where a choice still remains.
35. Parameter passing and function return for the main
subprogram. See 10.2(21).
|
The main program has no parameters. It may be a procedure, or a function
returning an integer type. In the latter case, the returned integer
value is the return code of the program.
36. The mechanisms for building and running partitions. See
10.2(24).
|
GNAT itself supports programs with only a single partition. The GNATDIST
tool provided with the GLADE package (which also includes an implementation
of the PCS) provides a completely flexible method for building and running
programs consisting of multiple partitions. See the separate GLADE manual
for details.
37. The details of program execution, including program
termination. See 10.2(25).
|
See separate section on compilation model.
38. The semantics of any non-active partitions supported by the
implementation. See 10.2(28).
|
Passive partitions are supported on targets where shared memory is
provided by the operating system. See the GLADE reference manual for
further details.
39. The information returned by Exception_Message . See
11.4.1(10).
|
Exception message returns the null string unless a specific message has
been passed by the program.
40. The result of Exceptions.Exception_Name for types
declared within an unnamed block_statement . See 11.4.1(12).
|
Blocks have implementation defined names of the form B
nnn
where nnn is an integer.
41. The information returned by
Exception_Information . See 11.4.1(13).
|
Exception_Information
returns a string in the following format:
Exception_Name: nnnnn
Message: mmmmm
PID: ppp
Call stack traceback locations:
0xhhhh 0xhhhh 0xhhhh ... 0xhhh
where
nnnn
is the fully qualified name of the exception in all upper
case letters. This line is always present.
mmmm
is the message (this line present only if message is non-null)
ppp
is the Process Id value as a decimal integer (this line is
present only if the Process Id is non-zero). Currently we are
not making use of this field.
- The Call stack traceback locations line and the following values
are present only if at least one traceback location was recorded.
The values are given in C style format, with lower case letters
for a-f, and only as many digits present as are necessary.
The line terminator sequence at the end of each line, including
the last line is a single LF
character (16#0A#
).
42. Implementation-defined check names. See 11.5(27).
|
No implementation-defined check names are supported.
43. The interpretation of each aspect of representation. See
13.1(20).
|
See separate section on data representations.
44. Any restrictions placed upon representation items. See
13.1(20).
|
See separate section on data representations.
45. The meaning of Size for indefinite subtypes. See
13.3(48).
|
Size for an indefinite subtype is the maximum possible size, except that
for the case of a subprogram parameter, the size of the parameter object
is the actual size.
46. The default external representation for a type tag. See
13.3(75).
|
The default external representation for a type tag is the fully expanded
name of the type in upper case letters.
47. What determines whether a compilation unit is the same in
two different partitions. See 13.3(76).
|
A compilation unit is the same in two different partitions if and only
if it derives from the same source file.
48. Implementation-defined components. See 13.5.1(15).
|
The only implementation defined component is the tag for a tagged type,
which contains a pointer to the dispatching table.
49. If Word_Size = Storage_Unit , the default bit
ordering. See 13.5.3(5).
|
Word_Size
(32) is not the same as Storage_Unit
(8) for this
implementation, so no non-default bit ordering is supported. The default
bit ordering corresponds to the natural endianness of the target architecture.
50. The contents of the visible part of package System
and its language-defined children. See 13.7(2).
|
See the definition of these packages in files system.ads and
s-stoele.ads.
51. The contents of the visible part of package
System.Machine_Code , and the meaning of
code_statements . See 13.8(7).
|
See the definition and documentation in file s-maccod.ads.
52. The effect of unchecked conversion. See 13.9(11).
|
Unchecked conversion between types of the same size
and results in an uninterpreted transmission of the bits from one type
to the other. If the types are of unequal sizes, then in the case of
discrete types, a shorter source is first zero or sign extended as
necessary, and a shorter target is simply truncated on the left.
For all non-discrete types, the source is first copied if necessary
to ensure that the alignment requirements of the target are met, then
a pointer is constructed to the source value, and the result is obtained
by dereferencing this pointer after converting it to be a pointer to the
target type.
53. The manner of choosing a storage pool for an access type
when Storage_Pool is not specified for the type. See 13.11(17).
|
There are 3 different standard pools used by the compiler when
Storage_Pool
is not specified depending whether the type is local
to a subprogram or defined at the library level and whether
Storage_Size
is specified or not. See documentation in the runtime
library units System.Pool_Global
, System.Pool_Size
and
System.Pool_Local
in files s-poosiz.ads,
s-pooglo.ads and s-pooloc.ads for full details on the
default pools used.
54. Whether or not the implementation provides user-accessible
names for the standard pool type(s). See 13.11(17).
|
See documentation in the sources of the run time mentioned in paragraph
53 . All these pools are accessible by means of with
'ing
these units.
55. The meaning of Storage_Size . See 13.11(18).
|
Storage_Size
is measured in storage units, and refers to the
total space available for an access type collection, or to the primary
stack space for a task.
56. Implementation-defined aspects of storage pools. See
13.11(22).
|
See documentation in the sources of the run time mentioned in paragraph
53 for details on GNAT-defined aspects of storage pools.
57. The set of restrictions allowed in a pragma
Restrictions . See 13.12(7).
|
All RM defined Restriction identifiers are implemented. The following
additional restriction identifiers are provided. There are two separate
lists of implementation dependent restriction identifiers. The first
set requires consistency throughout a partition (in other words, if the
restriction identifier is used for any compilation unit in the partition,
then all compilation units in the partition must obey the restriction.
Boolean_Entry_Barriers
- This restriction ensures at compile time that barriers in entry declarations
for protected types are restricted to references to simple boolean variables
defined in the private part of the protected type. No other form of entry
barriers is permitted. This is one of the restrictions of the Ravenscar
profile for limited tasking (see also pragma
Ravenscar
).
Max_Entry_Queue_Depth => Expr
- This restriction is a declaration that any protected entry compiled in
the scope of the restriction has at most the specified number of
tasks waiting on the entry
at any one time, and so no queue is required. This restriction is not
checked at compile time. A program execution is erroneous if an attempt
is made to queue more than the specified number of tasks on such an entry.
No_Calendar
- This restriction ensures at compile time that there is no implicit or
explicit dependence on the package
Ada.Calendar
.
No_Dynamic_Interrupts
- This restriction ensures at compile time that there is no attempt to
dynamically associate interrupts. Only static association is allowed.
No_Enumeration_Maps
- This restriction ensures at compile time that no operations requiring
enumeration maps are used (that is Image and Value attributes applied
to enumeration types).
No_Entry_Calls_In_Elaboration_Code
- This restriction ensures at compile time that no task or protected entry
calls are made during elaboration code. As a result of the use of this
restriction, the compiler can assume that no code past an accept statement
in a task can be executed at elaboration time.
No_Exception_Handlers
- This restriction ensures at compile time that there are no explicit
exception handlers.
No_Implicit_Conditionals
- This restriction ensures that the generated code does not contain any
implicit conditionals, either by modifying the generated code where possible,
or by rejecting any construct that would otherwise generate an implicit
conditional. The details and use of this restriction are described in
more detail in the High Integrity product documentation.
No_Implicit_Loops
- This restriction ensures that the generated code does not contain any
implicit
for
loops, either by modifying
the generated code where possible,
or by rejecting any construct that would otherwise generate an implicit
for
loop. The details and use of this restriction are described in
more detail in the High Integrity product documentation.
No_Local_Protected_Objects
- This restriction ensures at compile time that protected objects are
only declared at the library level.
No_Protected_Type_Allocators
- This restriction ensures at compile time that there are no allocator
expressions that attempt to allocate protected objects.
No_Secondary_Stack
- This restriction ensures at compile time that the generated code does not
contain any reference to the secondary stack. The secondary stack is used
to implement functions returning unconstrained objects (arrays or records)
on some targets.
The details and use of this restriction are described in
more detail in the High Integrity product documentation.
No_Select_Statements
- This restriction ensures at compile time no select statements of any kind
are permitted, that is the keyword
select
may not appear.
This is one of the restrictions of the Ravenscar
profile for limited tasking (see also pragma Ravenscar
).
No_Standard_Storage_Pools
- This restriction ensures at compile time that no access types
use the standard default storage pool. Any access type declared must
have an explicit Storage_Pool attribute defined specifying a
user-defined storage pool.
No_Streams
- This restriction ensures at compile time that there are no implicit or
explicit dependencies on the package
Ada.Streams
.
No_Task_Attributes
- This restriction ensures at compile time that there are no implicit or
explicit dependencies on the package
Ada.Task_Attributes
.
No_Task_Termination
- This restriction ensures at compile time that no terminate alternatives
appear in any task body.
No_Tasking
- This restriction prevents the declaration of tasks or task types throughout
the partition. It is similar in effect to the use of
Max_Tasks => 0
except that violations are caught at compile time and cause an error message
to be output either by the compiler or binder.
No_Wide_Characters
- This restriction ensures at compile time that no uses of the types
Wide_Character
or Wide_String
appear, and that no wide character literals
appear in the program (that is literals representing characters not in
type Character
.
Static_Priorities
- This restriction ensures at compile time that all priority expressions
are static, and that there are no dependencies on the package
Ada.Dynamic_Priorities
.
Static_Storage_Size
- This restriction ensures at compile time that any expression appearing
in a Storage_Size pragma or attribute definition clause is static.
The second set of implementation dependent restriction identifiers
does not require partition-wide consistency.
The restriction may be enforced for a single
compilation unit without any effect on any of the
other compilation units in the partition.
No_Elaboration_Code
- This restriction ensures at compile time that no elaboration code is
generated. Note that this is not the same condition as is enforced
by pragma
Preelaborate
. There are cases in which pragma Preelaborate
still permits code to be generated (e.g. code to initialize a large
array to all zeroes), and there are cases of units which do not meet
the requirements for pragma Preelaborate
, but for which no elaboration
code is generated. Generally, it is the case that preelaborable units
will meet the restrictions, with the exception of large aggregates
initialized with an others_clause, and exception declarations (which
generate calls to a run-time registry procedure). Note that this restriction
is enforced on a unit by unit basis, it need not be obeyed consistently
throughout a partition.
No_Entry_Queue
- This restriction is a declaration that any protected entry compiled in
the scope of the restriction has at most one task waiting on the entry
at any one time, and so no queue is required. This restriction is not
checked at compile time. A program execution is erroneous if an attempt
is made to queue a second task on such an entry.
No_Implementation_Attributes
- This restriction checks at compile time that no GNAT-defined attributes
are present. With this restriction, the only attributes that can be used
are those defined in the Ada 95 Reference Manual.
No_Implementation_Pragmas
- This restriction checks at compile time that no GNAT-defined pragmas
are present. With this restriction, the only pragmas that can be used
are those defined in the Ada 95 Reference Manual.
No_Implementation_Restrictions
- This restriction checks at compile time that no GNAT-defined restriction
identifiers (other than
No_Implementation_Restrictions
itself)
are present. With this restriction, the only other restriction identifiers
that can be used are those defined in the Ada 95 Reference Manual.
58. The consequences of violating limitations on
Restrictions pragmas. See 13.12(9).
|
Restrictions that can be checked at compile time result in illegalities
if violated. Currently there are no other consequences of violating
restrictions.
59. The representation used by the Read and
Write attributes of elementary types in terms of stream
elements. See 13.13.2(9).
|
The representation is the in-memory representation of the base type of
the type, using the number of bits corresponding to the
type'Size
value, and the natural ordering of the machine.
60. The names and characteristics of the numeric subtypes
declared in the visible part of package Standard . See A.1(3).
|
See items describing the integer and floating-point types supported.
61. The accuracy actually achieved by the elementary
functions. See A.5.1(1).
|
The elementary functions correspond to the functions available in the C
library. Only fast math mode is implemented.
62. The sign of a zero result from some of the operators or
functions in Numerics.Generic_Elementary_Functions , when
Float_Type'Signed_Zeros is True . See A.5.1(46).
|
The sign of zeroes follows the requirements of the IEEE 754 standard on
floating-point.
63. The value of
Numerics.Float_Random.Max_Image_Width . See A.5.2(27).
|
Maximum image width is 649, see library file a-numran.ads.
64. The value of
Numerics.Discrete_Random.Max_Image_Width . See A.5.2(27).
|
Maximum image width is 80, see library file a-nudira.ads.
65. The algorithms for random number generation. See
A.5.2(32).
|
The algorithm is documented in the source files a-numran.ads and
a-numran.adb.
66. The string representation of a random number generator's
state. See A.5.2(38).
|
See the documentation contained in the file a-numran.adb.
67. The minimum time interval between calls to the
time-dependent Reset procedure that are guaranteed to initiate different
random number sequences. See A.5.2(45).
|
The minimum period between reset calls to guarantee distinct series of
random numbers is one microsecond.
68. The values of the Model_Mantissa ,
Model_Emin , Model_Epsilon , Model ,
Safe_First , and Safe_Last attributes, if the Numerics
Annex is not supported. See A.5.3(72).
|
See the source file ttypef.ads for the values of all numeric
attributes.
69. Any implementation-defined characteristics of the
input-output packages. See A.7(14).
|
There are no special implementation defined characteristics for these
packages.
70. The value of Buffer_Size in Storage_IO . See
A.9(10).
|
All type representations are contiguous, and the Buffer_Size
is
the value of type'Size
rounded up to the next storage unit
boundary.
71. External files for standard input, standard output, and
standard error See A.10(5).
|
These files are mapped onto the files provided by the C streams
libraries. See source file i-cstrea.ads for further details.
72. The accuracy of the value produced by Put . See
A.10.9(36).
|
If more digits are requested in the output than are represented by the
precision of the value, zeroes are output in the corresponding least
significant digit positions.
73. The meaning of Argument_Count , Argument , and
Command_Name . See A.15(1).
|
These are mapped onto the argv
and argc
parameters of the
main program in the natural manner.
74. Implementation-defined convention names. See B.1(11).
|
The following convention names are supported
Ada
- Ada
Assembler
- Assembly language
Asm
- Synonym for Assembler
Assembly
- Synonym for Assembler
C
- C
C_Pass_By_Copy
- Allowed only for record types, like C, but also notes that record
is to be passed by copy rather than reference.
COBOL
- COBOL
CPP
- C++
Default
- Treated the same as C
External
- Treated the same as C
Fortran
- Fortran
Intrinsic
- For support of pragma
Import
with convention Intrinsic, see
separate section on Intrinsic Subprograms.
Stdcall
- Stdcall (used for Windows implementations only). This convention correspond
to the WINAPI (previously called Pascal convention) C/C++ convention under
Windows. A function with this convention cleans the stack before exit.
DLL
- Synonym for Stdcall
Win32
- Synonym for Stdcall
Stubbed
- Stubbed is a special convention used to indicate that the body of the
subprogram will be entirely ignored. Any call to the subprogram
is converted into a raise of the
Program_Error
exception. If a
pragma Import
specifies convention stubbed
then no body need
be present at all. This convention is useful during development for the
inclusion of subprograms whose body has not yet been written.
In addition, all otherwise unrecognized convention names are also
treated as being synonymous with convention C. In all implementations
except for VMS, use of such other names results in a warning. In VMS
implementations, these names are accepted silently.
75. The meaning of link names. See B.1(36).
|
Link names are the actual names used by the linker.
76. The manner of choosing link names when neither the link
name nor the address of an imported or exported entity is specified. See
B.1(36).
|
The default linker name is that which would be assigned by the relevant
external language, interpreting the Ada name as being in all lower case
letters.
77. The effect of pragma Linker_Options . See B.1(37).
|
The string passed to Linker_Options
is presented uninterpreted as
an argument to the link command, unless it contains Ascii.NUL characters.
NUL characters if they appear act as argument separators, so for example
pragma Linker_Options ("-labc" & ASCII.Nul & "-ldef");
causes two separate arguments -labc
and -ldef
to be passed to the
linker. The order of linker options is preserved for a given unit. The final
list of options passed to the linker is in reverse order of the elaboration
order. For example, linker options fo a body always appear before the options
from the corresponding package spec.
78. The contents of the visible part of package
Interfaces and its language-defined descendants. See B.2(1).
|
See files with prefix i- in the distributed library.
79. Implementation-defined children of package
Interfaces . The contents of the visible part of package
Interfaces . See B.2(11).
|
See files with prefix i- in the distributed library.
80. The types Floating , Long_Floating ,
Binary , Long_Binary , Decimal_ Element , and
COBOL_Character ; and the initialization of the variables
Ada_To_COBOL and COBOL_To_Ada , in
Interfaces.COBOL . See B.4(50).
|
Floating
- Float
Long_Floating
- (Floating) Long_Float
Binary
- Integer
Long_Binary
- Long_Long_Integer
Decimal_Element
- Character
COBOL_Character
- Character
For initialization, see the file i-cobol.ads in the distributed library.
81. Support for access to machine instructions. See C.1(1).
|
See documentation in file s-maccod.ads in the distributed library.
82. Implementation-defined aspects of access to machine
operations. See C.1(9).
|
See documentation in file s-maccod.ads in the distributed library.
83. Implementation-defined aspects of interrupts. See C.3(2).
|
Interrupts are mapped to signals or conditions as appropriate. See
definition of unit
Ada.Interrupt_Names
in source file a-intnam.ads for details
on the interrupts supported on a particular target.
84. Implementation-defined aspects of pre-elaboration. See
C.4(13).
|
GNAT does not permit a partition to be restarted without reloading,
except under control of the debugger.
85. The semantics of pragma Discard_Names . See C.5(7).
|
Pragma Discard_Names
causes names of enumeration literals to
be suppressed. In the presence of this pragma, the Image attribute
provides the image of the Pos of the literal, and Value accepts
Pos values.
86. The result of the Task_Identification.Image
attribute. See C.7.1(7).
|
The result of this attribute is an 8-digit hexadecimal string
representing the virtual address of the task control block.
87. The value of Current_Task when in a protected entry
or interrupt handler. See C.7.1(17).
|
Protected entries or interrupt handlers can be executed by any
convenient thread, so the value of Current_Task
is undefined.
88. The effect of calling Current_Task from an entry
body or interrupt handler. See C.7.1(19).
|
The effect of calling Current_Task
from an entry body or
interrupt handler is to return the identification of the task currently
executing the code.
89. Implementation-defined aspects of
Task_Attributes . See C.7.2(19).
|
There are no implementation-defined aspects of Task_Attributes
.
90. Values of all Metrics . See D(2).
|
The metrics information for GNAT depends on the performance of the
underlying operating system. The sources of the run-time for tasking
implementation, together with the output from -gnatG
can be
used to determine the exact sequence of operating systems calls made
to implement various tasking constructs. Together with appropriate
information on the performance of the underlying operating system,
on the exact target in use, this information can be used to determine
the required metrics.
91. The declarations of Any_Priority and
Priority . See D.1(11).
|
See declarations in file system.ads.
92. Implementation-defined execution resources. See D.1(15).
|
There are no implementation-defined execution resources.
93. Whether, on a multiprocessor, a task that is waiting for
access to a protected object keeps its processor busy. See D.2.1(3).
|
On a multi-processor, a task that is waiting for access to a protected
object does not keep its processor busy.
94. The affect of implementation defined execution resources
on task dispatching. See D.2.1(9).
|
Tasks map to threads in the threads package used by GNAT. Where possible
and appropriate, these threads correspond to native threads of the
underlying operating system.
95. Implementation-defined policy_identifiers allowed
in a pragma Task_Dispatching_Policy . See D.2.2(3).
|
There are no implementation-defined policy-identifiers allowed in this
pragma.
96. Implementation-defined aspects of priority inversion. See
D.2.2(16).
|
Execution of a task cannot be preempted by the implementation processing
of delay expirations for lower priority tasks.
97. Implementation defined task dispatching. See D.2.2(18).
|
The policy is the same as that of the underlying threads implementation.
98. Implementation-defined policy_identifiers allowed
in a pragma Locking_Policy . See D.3(4).
|
The only implementation defined policy permitted in GNAT is
Inheritance_Locking
. On targets that support this policy, locking
is implemented by inheritance, i.e. the task owning the lock operates
at a priority equal to the highest priority of any task currently
requesting the lock.
99. Default ceiling priorities. See D.3(10).
|
The ceiling priority of protected objects of the type
System.Interrupt_Priority'Last
as described in the Ada 95
Reference Manual D.3(10),
100. The ceiling of any protected object used internally by
the implementation. See D.3(16).
|
The ceiling priority of internal protected objects is
System.Priority'Last
.
101. Implementation-defined queuing policies. See D.4(1).
|
There are no implementation-defined queueing policies.
102. On a multiprocessor, any conditions that cause the
completion of an aborted construct to be delayed later than what is
specified for a single processor. See D.6(3).
|
The semantics for abort on a multi-processor is the same as on a single
processor, there are no further delays.
103. Any operations that implicitly require heap storage
allocation. See D.7(8).
|
The only operation that implicitly requires heap storage allocation is
task creation.
104. Implementation-defined aspects of pragma
Restrictions . See D.7(20).
|
There are no such implementation-defined aspects.
105. Implementation-defined aspects of package
Real_Time . See D.8(17).
|
There are no implementation defined aspects of package Real_Time
.
106. Implementation-defined aspects of
delay_statements . See D.9(8).
|
Any difference greater than one microsecond will cause the task to be
delayed (see D.9(7)).
107. The upper bound on the duration of interrupt blocking
caused by the implementation. See D.12(5).
|
The upper bound is determined by the underlying operating system. In
no cases is it more than 10 milliseconds.
108. The means for creating and executing distributed
programs. See E(5).
|
The GLADE package provides a utility GNATDIST for creating and executing
distributed programs. See the GLADE reference manual for further details.
109. Any events that can result in a partition becoming
inaccessible. See E.1(7).
|
See the GLADE reference manual for full details on such events.
110. The scheduling policies, treatment of priorities, and
management of shared resources between partitions in certain cases. See
E.1(11).
|
See the GLADE reference manual for full details on these aspects of
multi-partition execution.
111. Events that cause the version of a compilation unit to
change. See E.3(5).
|
Editing the source file of a compilation unit, or the source files of
any units on which it is dependent in a significant way cause the version
to change. No other actions cause the version number to change. All changes
are significant except those which affect only layout, capitalization or
comments.
112. Whether the execution of the remote subprogram is
immediately aborted as a result of cancellation. See E.4(13).
|
See the GLADE reference manual for details on the effect of abort in
a distributed application.
113. Implementation-defined aspects of the PCS. See E.5(25).
|
See the GLADE reference manual for a full description of all implementation
defined aspects of the PCS.
114. Implementation-defined interfaces in the PCS. See
E.5(26).
|
See the GLADE reference manual for a full description of all
implementation defined interfaces.
115. The values of named numbers in the package
Decimal . See F.2(7).
|
Max_Scale
- +18
Min_Scale
- -18
Min_Delta
- 1.0E-18
Max_Delta
- 1.0E+18
Max_Decimal_Digits
- 18
116. The value of Max_Picture_Length in the package
Text_IO.Editing . See F.3.3(16).
|
64
117. The value of Max_Picture_Length in the package
Wide_Text_IO.Editing . See F.3.4(5).
|
64
118. The accuracy actually achieved by the complex elementary
functions and by other complex arithmetic operations. See G.1(1).
|
Standard library functions are used for the complex arithmetic
operations. Only fast math mode is currently supported.
119. The sign of a zero result (or a component thereof) from
any operator or function in Numerics.Generic_Complex_Types , when
Real'Signed_Zeros is True. See G.1.1(53).
|
The signs of zero values are as recommended by the relevant
implementation advice.
120. The sign of a zero result (or a component thereof) from
any operator or function in
Numerics.Generic_Complex_Elementary_Functions , when
Real'Signed_Zeros is True . See G.1.2(45).
|
The signs of zero values are as recommended by the relevant
implementation advice.
121. Whether the strict mode or the relaxed mode is the
default. See G.2(2).
|
The strict mode is the default. There is no separate relaxed mode. GNAT
provides a highly efficient implementation of strict mode.
122. The result interval in certain cases of fixed-to-float
conversion. See G.2.1(10).
|
For cases where the result interval is implementation dependent, the
accuracy is that provided by performing all operations in 64-bit IEEE
floating-point format.
123. The result of a floating point arithmetic operation in
overflow situations, when the Machine_Overflows attribute of the
result type is False . See G.2.1(13).
|
Infinite and Nan values are produced as dictated by the IEEE
floating-point standard.
124. The result interval for division (or exponentiation by a
negative exponent), when the floating point hardware implements division
as multiplication by a reciprocal. See G.2.1(16).
|
Not relevant, division is IEEE exact.
125. The definition of close result set, which determines the
accuracy of certain fixed point multiplications and divisions. See
G.2.3(5).
|
Operations in the close result set are performed using IEEE long format
floating-point arithmetic. The input operands are converted to
floating-point, the operation is done in floating-point, and the result
is converted to the target type.
126. Conditions on a universal_real operand of a fixed
point multiplication or division for which the result shall be in the
perfect result set. See G.2.3(22).
|
The result is only defined to be in the perfect result set if the result
can be computed by a single scaling operation involving a scale factor
representable in 64-bits.
127. The result of a fixed point arithmetic operation in
overflow situations, when the Machine_Overflows attribute of the
result type is False . See G.2.3(27).
|
Not relevant, Machine_Overflows
is True
for fixed-point
types.
128. The result of an elementary function reference in
overflow situations, when the Machine_Overflows attribute of the
result type is False . See G.2.4(4).
|
IEEE infinite and Nan values are produced as appropriate.
129. The value of the angle threshold, within which certain
elementary functions, complex arithmetic operations, and complex
elementary functions yield results conforming to a maximum relative
error bound. See G.2.4(10).
|
Information on this subject is not yet available.
130. The accuracy of certain elementary functions for
parameters beyond the angle threshold. See G.2.4(10).
|
Information on this subject is not yet available.
131. The result of a complex arithmetic operation or complex
elementary function reference in overflow situations, when the
Machine_Overflows attribute of the corresponding real type is
False . See G.2.6(5).
|
IEEE infinite and Nan values are produced as appropriate.
132. The accuracy of certain complex arithmetic operations and
certain complex elementary functions for parameters (or components
thereof) beyond the angle threshold. See G.2.6(8).
|
Information on those subjects is not yet available.
133. Information regarding bounded errors and erroneous
execution. See H.2(1).
|
Information on this subject is not yet available.
134. Implementation-defined aspects of pragma
Inspection_Point . See H.3.2(8).
|
Pragma Inspection_Point
ensures that the variable is live and can
be examined by the debugger at the inspection point.
135. Implementation-defined aspects of pragma
Restrictions . See H.4(25).
|
There are no implementation-defined aspects of pragma Restrictions
. The
use of pragma Restrictions [No_Exceptions]
has no effect on the
generated code. Checks must suppressed by use of pragma Suppress
.
136. Any restrictions on pragma Restrictions . See
H.4(27).
|
There are no restrictions on pragma Restrictions
.