1 .. _Implementation_Defined_Characteristics:
3 **************************************
4 Implementation Defined Characteristics
5 **************************************
7 In addition to the implementation dependent pragmas and attributes, and the
8 implementation advice, there are a number of other Ada features that are
9 potentially implementation dependent and are designated as
10 implementation-defined. These are mentioned throughout the Ada Reference
11 Manual, and are summarized in Annex M.
13 A requirement for conforming Ada compilers is that they provide
14 documentation describing how the implementation deals with each of these
15 issues. In this chapter you will find each point in Annex M listed,
16 followed by a description of how GNAT handles the implementation dependence.
18 You can use this chapter as a guide to minimizing implementation
19 dependent features in your programs if portability to other compilers
20 and other operating systems is an important consideration. The numbers
21 in each entry below correspond to the paragraph numbers in the Ada
25 "Whether or not each recommendation given in Implementation
26 Advice is followed. See 1.1.2(37)."
28 See :ref:`Implementation_Advice`.
31 "Capacity limitations of the implementation. See 1.1.3(3)."
33 The complexity of programs that can be processed is limited only by the
34 total amount of available virtual memory, and disk space for the
35 generated object files.
38 "Variations from the standard that are impractical to avoid
39 given the implementation's execution environment. See 1.1.3(6)."
41 There are no variations from the standard.
44 "Which code_statements cause external
45 interactions. See 1.1.3(10)."
47 Any *code_statement* can potentially cause external interactions.
50 "The coded representation for the text of an Ada
53 See separate section on source representation.
56 "The control functions allowed in comments. See 2.1(14)."
58 See separate section on source representation.
61 "The representation for an end of line. See 2.2(2)."
63 See separate section on source representation.
66 "Maximum supported line length and lexical element
69 The maximum line length is 255 characters and the maximum length of
70 a lexical element is also 255 characters. This is the default setting
71 if not overridden by the use of compiler switch *-gnaty* (which
72 sets the maximum to 79) or *-gnatyMnn* which allows the maximum
73 line length to be specified to be any value up to 32767. The maximum
74 length of a lexical element is the same as the maximum line length.
77 "Implementation defined pragmas. See 2.8(14)."
79 See :ref:`Implementation_Defined_Pragmas`.
82 "Effect of pragma ``Optimize``. See 2.8(27)."
84 Pragma ``Optimize``, if given with a ``Time`` or ``Space``
85 parameter, checks that the optimization flag is set, and aborts if it is
89 "The sequence of characters of the value returned by
90 ``S'Image`` when some of the graphic characters of
91 ``S'Wide_Image`` are not defined in ``Character``. See
94 The sequence of characters is as defined by the wide character encoding
95 method used for the source. See section on source representation for
99 "The predefined integer types declared in
100 ``Standard``. See 3.5.4(25)."
102 ========================= =======================================
104 ========================= =======================================
105 *Short_Short_Integer* 8-bit signed
106 *Short_Integer* 16-bit signed
107 *Integer* 32-bit signed
108 *Long_Integer* 64-bit signed (on most 64-bit targets,
109 depending on the C definition of long)
110 32-bit signed (on all other targets)
111 *Long_Long_Integer* 64-bit signed
112 *Long_Long_Long_Integer* 128-bit signed (on 64-bit targets)
113 64-bit signed (on 32-bit targets)
114 ========================= =======================================
117 "Any nonstandard integer types and the operators defined
118 for them. See 3.5.4(26)."
120 There are no nonstandard integer types.
123 "Any nonstandard real types and the operators defined for
126 There are no nonstandard real types.
129 "What combinations of requested decimal precision and range
130 are supported for floating point types. See 3.5.7(7)."
132 The precision and range is as defined by the IEEE standard.
135 "The predefined floating point types declared in
136 ``Standard``. See 3.5.7(16)."
138 ====================== ====================================================
140 ====================== ====================================================
141 *Short_Float* 32 bit IEEE short
142 *Float* (Short) 32 bit IEEE short
143 *Long_Float* 64 bit IEEE long
144 *Long_Long_Float* 64 bit IEEE long (80 bit IEEE long on x86 processors)
145 ====================== ====================================================
148 "The small of an ordinary fixed point type. See 3.5.9(8)."
150 The small is the largest power of two that does not exceed the delta.
153 "What combinations of small, range, and digits are
154 supported for fixed point types. See 3.5.9(10)."
156 For an ordinary fixed point type, on 32-bit platforms, the small must lie in
157 2.0**(-80) .. 2.0**80 and the range in -9.0E+36 .. 9.0E+36; any combination
158 is permitted that does not result in a mantissa larger than 63 bits.
160 On 64-bit platforms, the small must lie in 2.0**(-127) .. 2.0**127 and the
161 range in -1.0E+76 .. 1.0E+76; any combination is permitted that does not
162 result in a mantissa larger than 63 bits, and any combination is permitted
163 that results in a mantissa between 64 and 127 bits if the small is either
164 an integer or the reciprocal of an integer.
166 If the small is either an integer or the reciprocal of an integer, which
167 is the case if no ``small`` clause is provided, then the operations of the
168 fixed point type are entirely implemented by means of integer instructions.
169 In the other cases, some operations, in particular input and output, may be
170 implemented by means of floating-point instructions and may be affected by
171 accuracy issues on architectures other than x86.
173 For a decimal fixed point type, on 32-bit platforms, the small must lie in
174 1.0E-18 .. 1.0E+18 and the digits in 1 .. 18. On 64-bit platforms, the
175 small must lie in 1.0E-38 .. 1.0E+38 and the digits in 1 .. 38.
178 "The result of ``Tags.Expanded_Name`` for types declared
179 within an unnamed *block_statement*. See 3.9(10)."
181 Block numbers of the form :samp:`B{nnn}`, where *nnn* is a
182 decimal integer are allocated.
185 "Implementation-defined attributes. See 4.1.4(12)."
187 See :ref:`Implementation_Defined_Attributes`.
190 "Any implementation-defined time types. See 9.6(6)."
192 There are no implementation-defined time types.
195 "The time base associated with relative delays."
197 See 9.6(20). The time base used is that provided by the C library
198 function ``gettimeofday``.
201 "The time base of the type ``Calendar.Time``. See
204 The time base used is that provided by the C library function
208 "The time zone used for package ``Calendar``
209 operations. See 9.6(24)."
211 The time zone used by package ``Calendar`` is the current system time zone
212 setting for local time, as accessed by the C library function
216 "Any limit on *delay_until_statements* of
217 *select_statements*. See 9.6(29)."
219 There are no such limits.
222 "Whether or not two non-overlapping parts of a composite
223 object are independently addressable, in the case where packing, record
224 layout, or ``Component_Size`` is specified for the object. See
227 Separate components are independently addressable if they do not share
228 overlapping storage units.
231 "The representation for a compilation. See 10.1(2)."
233 A compilation is represented by a sequence of files presented to the
234 compiler in a single invocation of the *gcc* command.
237 "Any restrictions on compilations that contain multiple
238 compilation_units. See 10.1(4)."
240 No single file can contain more than one compilation unit, but any
241 sequence of files can be presented to the compiler as a single
245 "The mechanisms for creating an environment and for adding
246 and replacing compilation units. See 10.1.4(3)."
248 See separate section on compilation model.
251 "The manner of explicitly assigning library units to a
252 partition. See 10.2(2)."
254 If a unit contains an Ada main program, then the Ada units for the partition
255 are determined by recursive application of the rules in the Ada Reference
256 Manual section 10.2(2-6). In other words, the Ada units will be those that
257 are needed by the main program, and then this definition of need is applied
258 recursively to those units, and the partition contains the transitive
259 closure determined by this relationship. In short, all the necessary units
260 are included, with no need to explicitly specify the list. If additional
261 units are required, e.g., by foreign language units, then all units must be
262 mentioned in the context clause of one of the needed Ada units.
264 If the partition contains no main program, or if the main program is in
265 a language other than Ada, then GNAT
266 provides the binder options *-z* and *-n* respectively, and in
267 this case a list of units can be explicitly supplied to the binder for
268 inclusion in the partition (all units needed by these units will also
269 be included automatically). For full details on the use of these
270 options, refer to *GNAT Make Program gnatmake* in the
271 :title:`GNAT User's Guide`.
274 "The implementation-defined means, if any, of specifying
275 which compilation units are needed by a given compilation unit. See
278 The units needed by a given compilation unit are as defined in
279 the Ada Reference Manual section 10.2(2-6). There are no
280 implementation-defined pragmas or other implementation-defined
281 means for specifying needed units.
284 "The manner of designating the main subprogram of a
285 partition. See 10.2(7)."
287 The main program is designated by providing the name of the
288 corresponding :file:`ALI` file as the input parameter to the binder.
291 "The order of elaboration of *library_items*. See
294 The first constraint on ordering is that it meets the requirements of
295 Chapter 10 of the Ada Reference Manual. This still leaves some
296 implementation dependent choices, which are resolved by first
297 elaborating bodies as early as possible (i.e., in preference to specs
298 where there is a choice), and second by evaluating the immediate with
299 clauses of a unit to determine the probably best choice, and
300 third by elaborating in alphabetical order of unit names
301 where a choice still remains.
304 "Parameter passing and function return for the main
305 subprogram. See 10.2(21)."
307 The main program has no parameters. It may be a procedure, or a function
308 returning an integer type. In the latter case, the returned integer
309 value is the return code of the program (overriding any value that
310 may have been set by a call to ``Ada.Command_Line.Set_Exit_Status``).
313 "The mechanisms for building and running partitions. See
316 GNAT itself supports programs with only a single partition. The GNATDIST
317 tool provided with the GLADE package (which also includes an implementation
318 of the PCS) provides a completely flexible method for building and running
319 programs consisting of multiple partitions. See the separate GLADE manual
323 "The details of program execution, including program
324 termination. See 10.2(25)."
326 See separate section on compilation model.
329 "The semantics of any non-active partitions supported by the
330 implementation. See 10.2(28)."
332 Passive partitions are supported on targets where shared memory is
333 provided by the operating system. See the GLADE reference manual for
337 "The information returned by ``Exception_Message``. See
340 Exception message returns the null string unless a specific message has
341 been passed by the program.
344 "The result of ``Exceptions.Exception_Name`` for types
345 declared within an unnamed *block_statement*. See 11.4.1(12)."
347 Blocks have implementation defined names of the form :samp:`B{nnn}`
348 where *nnn* is an integer.
351 "The information returned by
352 ``Exception_Information``. See 11.4.1(13)."
354 ``Exception_Information`` returns a string in the following format::
356 *Exception_Name:* nnnnn
359 *Load address:* 0xhhhh
360 *Call stack traceback locations:*
361 0xhhhh 0xhhhh 0xhhhh ... 0xhhh
365 * ``nnnn`` is the fully qualified name of the exception in all upper
366 case letters. This line is always present.
368 * ``mmmm`` is the message (this line present only if message is non-null)
370 * ``ppp`` is the Process Id value as a decimal integer (this line is
371 present only if the Process Id is nonzero). Currently we are
372 not making use of this field.
374 * The Load address line, the Call stack traceback locations line and the
375 following values are present only if at least one traceback location was
376 recorded. The Load address indicates the address at which the main executable
377 was loaded; this line may not be present if operating system hasn't relocated
378 the main executable. The values are given in C style format, with lower case
379 letters for a-f, and only as many digits present as are necessary.
380 The line terminator sequence at the end of each line, including
381 the last line is a single ``LF`` character (``16#0A#``).
384 "Implementation-defined check names. See 11.5(27)."
386 The implementation defined check names include Alignment_Check,
387 Atomic_Synchronization, Duplicated_Tag_Check, Container_Checks,
388 Tampering_Check, Predicate_Check, and Validity_Check. In addition, a user
389 program can add implementation-defined check names by means of the pragma
390 Check_Name. See the description of pragma ``Suppress`` for full details.
393 "The interpretation of each aspect of representation. See
396 See separate section on data representations.
399 "Any restrictions placed upon representation items. See
402 See separate section on data representations.
405 "The meaning of ``Size`` for indefinite subtypes. See
408 Size for an indefinite subtype is the maximum possible size, except that
409 for the case of a subprogram parameter, the size of the parameter object
413 "The default external representation for a type tag. See
416 The default external representation for a type tag is the fully expanded
417 name of the type in upper case letters.
420 "What determines whether a compilation unit is the same in
421 two different partitions. See 13.3(76)."
423 A compilation unit is the same in two different partitions if and only
424 if it derives from the same source file.
427 "Implementation-defined components. See 13.5.1(15)."
429 The only implementation defined component is the tag for a tagged type,
430 which contains a pointer to the dispatching table.
433 "If ``Word_Size`` = ``Storage_Unit``, the default bit
434 ordering. See 13.5.3(5)."
436 ``Word_Size`` (32) is not the same as ``Storage_Unit`` (8) for this
437 implementation, so no non-default bit ordering is supported. The default
438 bit ordering corresponds to the natural endianness of the target architecture.
441 "The contents of the visible part of package ``System``
442 and its language-defined children. See 13.7(2)."
444 See the definition of these packages in files :file:`system.ads` and
445 :file:`s-stoele.ads`. Note that two declarations are added to package
450 Max_Priority : constant Positive := Priority'Last;
451 Max_Interrupt_Priority : constant Positive := Interrupt_Priority'Last;
454 "The contents of the visible part of package
455 ``System.Machine_Code``, and the meaning of
456 *code_statements*. See 13.8(7)."
458 See the definition and documentation in file :file:`s-maccod.ads`.
461 "The effect of unchecked conversion. See 13.9(11)."
463 Unchecked conversion between types of the same size
464 results in an uninterpreted transmission of the bits from one type
465 to the other. If the types are of unequal sizes, then in the case of
466 discrete types, a shorter source is first zero or sign extended as
467 necessary, and a shorter target is simply truncated on the left.
468 For all non-discrete types, the source is first copied if necessary
469 to ensure that the alignment requirements of the target are met, then
470 a pointer is constructed to the source value, and the result is obtained
471 by dereferencing this pointer after converting it to be a pointer to the
472 target type. Unchecked conversions where the target subtype is an
473 unconstrained array are not permitted. If the target alignment is
474 greater than the source alignment, then a copy of the result is
475 made with appropriate alignment
478 "The semantics of operations on invalid representations.
481 For assignments and other operations where the use of invalid values cannot
482 result in erroneous behavior, the compiler ignores the possibility of invalid
483 values. An exception is raised at the point where an invalid value would
484 result in erroneous behavior. For example executing:
488 procedure invalidvals is
490 Y : Natural range 1 .. 10;
491 for Y'Address use X'Address;
492 Z : Natural range 1 .. 10;
493 A : array (Natural range 1 .. 10) of Integer;
495 Z := Y; -- no exception
496 A (Z) := 3; -- exception raised;
499 As indicated, an exception is raised on the array assignment, but not
500 on the simple assignment of the invalid negative value from Y to Z.
503 "The manner of choosing a storage pool for an access type
504 when ``Storage_Pool`` is not specified for the type. See 13.11(17)."
506 There are 3 different standard pools used by the compiler when
507 ``Storage_Pool`` is not specified depending whether the type is local
508 to a subprogram or defined at the library level and whether
509 ``Storage_Size``is specified or not. See documentation in the runtime
510 library units ``System.Pool_Global``, ``System.Pool_Size`` and
511 ``System.Pool_Local`` in files :file:`s-poosiz.ads`,
512 :file:`s-pooglo.ads` and :file:`s-pooloc.ads` for full details on the
516 "Whether or not the implementation provides user-accessible
517 names for the standard pool type(s). See 13.11(17)."
519 See documentation in the sources of the run time mentioned in the previous
520 paragraph. All these pools are accessible by means of `with`\ ing
524 "The meaning of ``Storage_Size``. See 13.11(18)."
526 ``Storage_Size`` is measured in storage units, and refers to the
527 total space available for an access type collection, or to the primary
528 stack space for a task.
531 "Implementation-defined aspects of storage pools. See
534 See documentation in the sources of the run time mentioned in the
535 paragraph about standard storage pools above
536 for details on GNAT-defined aspects of storage pools.
539 "The set of restrictions allowed in a pragma
540 ``Restrictions``. See 13.12(7)."
542 See :ref:`Standard_and_Implementation_Defined_Restrictions`.
545 "The consequences of violating limitations on
546 ``Restrictions`` pragmas. See 13.12(9)."
548 Restrictions that can be checked at compile time result in illegalities
549 if violated. Currently there are no other consequences of violating
553 "The representation used by the ``Read`` and
554 ``Write`` attributes of elementary types in terms of stream
555 elements. See 13.13.2(9)."
557 The representation is the in-memory representation of the base type of
558 the type, using the number of bits corresponding to the
559 ``type'Size`` value, and the natural ordering of the machine.
562 "The names and characteristics of the numeric subtypes
563 declared in the visible part of package ``Standard``. See A.1(3)."
565 See items describing the integer and floating-point types supported.
568 "The string returned by ``Character_Set_Version``.
571 ``Ada.Wide_Characters.Handling.Character_Set_Version`` returns
572 the string "Unicode 4.0", referring to version 4.0 of the
573 Unicode specification.
576 "The accuracy actually achieved by the elementary
577 functions. See A.5.1(1)."
579 The elementary functions correspond to the functions available in the C
580 library. Only fast math mode is implemented.
583 "The sign of a zero result from some of the operators or
584 functions in ``Numerics.Generic_Elementary_Functions``, when
585 ``Float_Type'Signed_Zeros`` is ``True``. See A.5.1(46)."
587 The sign of zeroes follows the requirements of the IEEE 754 standard on
592 ``Numerics.Float_Random.Max_Image_Width``. See A.5.2(27)."
594 Maximum image width is 6864, see library file :file:`s-rannum.ads`.
598 ``Numerics.Discrete_Random.Max_Image_Width``. See A.5.2(27)."
600 Maximum image width is 6864, see library file :file:`s-rannum.ads`.
603 "The algorithms for random number generation. See
606 The algorithm is the Mersenne Twister, as documented in the source file
607 :file:`s-rannum.adb`. This version of the algorithm has a period of
611 "The string representation of a random number generator's
612 state. See A.5.2(38)."
614 The value returned by the Image function is the concatenation of
615 the fixed-width decimal representations of the 624 32-bit integers
619 "The minimum time interval between calls to the
620 time-dependent Reset procedure that are guaranteed to initiate different
621 random number sequences. See A.5.2(45)."
623 The minimum period between reset calls to guarantee distinct series of
624 random numbers is one microsecond.
627 "The values of the ``Model_Mantissa``,
628 ``Model_Emin``, ``Model_Epsilon``, ``Model``,
629 ``Safe_First``, and ``Safe_Last`` attributes, if the Numerics
630 Annex is not supported. See A.5.3(72)."
632 Run the compiler with *-gnatS* to produce a listing of package
633 ``Standard``, has the values of all numeric attributes.
636 "Any implementation-defined characteristics of the
637 input-output packages. See A.7(14)."
639 There are no special implementation defined characteristics for these
643 "The value of ``Buffer_Size`` in ``Storage_IO``. See
646 All type representations are contiguous, and the ``Buffer_Size`` is
647 the value of ``type'Size`` rounded up to the next storage unit
651 "External files for standard input, standard output, and
652 standard error See A.10(5)."
654 These files are mapped onto the files provided by the C streams
655 libraries. See source file :file:`i-cstrea.ads` for further details.
658 "The accuracy of the value produced by ``Put``. See
661 If more digits are requested in the output than are represented by the
662 precision of the value, zeroes are output in the corresponding least
663 significant digit positions.
666 "The meaning of ``Argument_Count``, ``Argument``, and
667 ``Command_Name``. See A.15(1)."
669 These are mapped onto the ``argv`` and ``argc`` parameters of the
670 main program in the natural manner.
673 "The interpretation of the ``Form`` parameter in procedure
674 ``Create_Directory``. See A.16(56)."
676 The ``Form`` parameter is not used.
679 "The interpretation of the ``Form`` parameter in procedure
680 ``Create_Path``. See A.16(60)."
682 The ``Form`` parameter is not used.
685 "The interpretation of the ``Form`` parameter in procedure
686 ``Copy_File``. See A.16(68)."
688 The ``Form`` parameter is case-insensitive.
689 Two fields are recognized in the ``Form`` parameter::
694 <value> starts immediately after the character '=' and ends with the
695 character immediately preceding the next comma (',') or with the last
696 character of the parameter.
698 The only possible values for preserve= are:
700 ================== ===================================================================
702 ================== ===================================================================
703 *no_attributes* Do not try to preserve any file attributes. This is the
704 default if no preserve= is found in Form.
705 *all_attributes* Try to preserve all file attributes (timestamps, access rights).
706 *timestamps* Preserve the timestamp of the copied file, but not the other
708 ================== ===================================================================
710 The only possible values for mode= are:
712 ============== ===============================================================================
714 ============== ===============================================================================
715 *copy* Only do the copy if the destination file does not already exist.
716 If it already exists, Copy_File fails.
717 *overwrite* Copy the file in all cases. Overwrite an already existing destination file.
718 *append* Append the original file to the destination file. If the destination file
719 does not exist, the destination file is a copy of the source file.
720 When mode=append, the field preserve=, if it exists, is not taken into account.
721 ============== ===============================================================================
723 If the Form parameter includes one or both of the fields and the value or
724 values are incorrect, Copy_file fails with Use_Error.
726 Examples of correct Forms::
728 Form => "preserve=no_attributes,mode=overwrite" (the default)
729 Form => "mode=append"
730 Form => "mode=copy, preserve=all_attributes"
732 Examples of incorrect Forms::
734 Form => "preserve=junk"
735 Form => "mode=internal, preserve=timestamps"
738 "The interpretation of the ``Pattern`` parameter, when not the null string,
739 in the ``Start_Search`` and ``Search`` procedures.
740 See A.16(104) and A.16(112)."
742 When the ``Pattern`` parameter is not the null string, it is interpreted
743 according to the syntax of regular expressions as defined in the
744 ``GNAT.Regexp`` package.
746 See :ref:`GNAT.Regexp_(g-regexp.ads)`.
749 "Implementation-defined convention names. See B.1(11)."
751 The following convention names are supported
753 ======================= ==============================================================================
754 Convention Name Interpretation
755 ======================= ==============================================================================
757 *Ada_Pass_By_Copy* Allowed for any types except by-reference types such as limited
758 records. Compatible with convention Ada, but causes any parameters
759 with this convention to be passed by copy.
760 *Ada_Pass_By_Reference* Allowed for any types except by-copy types such as scalars.
761 Compatible with convention Ada, but causes any parameters
762 with this convention to be passed by reference.
763 *Assembler* Assembly language
764 *Asm* Synonym for Assembler
765 *Assembly* Synonym for Assembler
767 *C_Pass_By_Copy* Allowed only for record types, like C, but also notes that record
768 is to be passed by copy rather than reference.
770 *C_Plus_Plus (or CPP)* C++
771 *Default* Treated the same as C
772 *External* Treated the same as C
774 *Intrinsic* For support of pragma ``Import`` with convention Intrinsic, see
775 separate section on Intrinsic Subprograms.
776 *Stdcall* Stdcall (used for Windows implementations only). This convention correspond
777 to the WINAPI (previously called Pascal convention) C/C++ convention under
778 Windows. A routine with this convention cleans the stack before
779 exit. This pragma cannot be applied to a dispatching call.
780 *DLL* Synonym for Stdcall
781 *Win32* Synonym for Stdcall
782 *Stubbed* Stubbed is a special convention used to indicate that the body of the
783 subprogram will be entirely ignored. Any call to the subprogram
784 is converted into a raise of the ``Program_Error`` exception. If a
785 pragma ``Import`` specifies convention ``stubbed`` then no body need
786 be present at all. This convention is useful during development for the
787 inclusion of subprograms whose body has not yet been written.
788 In addition, all otherwise unrecognized convention names are also
789 treated as being synonymous with convention C. In all implementations,
790 use of such other names results in a warning.
791 ======================= ==============================================================================
794 "The meaning of link names. See B.1(36)."
796 Link names are the actual names used by the linker.
799 "The manner of choosing link names when neither the link
800 name nor the address of an imported or exported entity is specified. See
803 The default linker name is that which would be assigned by the relevant
804 external language, interpreting the Ada name as being in all lower case
808 "The effect of pragma ``Linker_Options``. See B.1(37)."
810 The string passed to ``Linker_Options`` is presented uninterpreted as
811 an argument to the link command, unless it contains ASCII.NUL characters.
812 NUL characters if they appear act as argument separators, so for example
816 pragma Linker_Options ("-labc" & ASCII.NUL & "-ldef");
818 causes two separate arguments ``-labc`` and ``-ldef`` to be passed to the
819 linker. The order of linker options is preserved for a given unit. The final
820 list of options passed to the linker is in reverse order of the elaboration
821 order. For example, linker options for a body always appear before the options
822 from the corresponding package spec.
825 "The contents of the visible part of package
826 ``Interfaces`` and its language-defined descendants. See B.2(1)."
828 See files with prefix :file:`i-` in the distributed library.
831 "Implementation-defined children of package
832 ``Interfaces``. The contents of the visible part of package
833 ``Interfaces``. See B.2(11)."
835 See files with prefix :file:`i-` in the distributed library.
838 "The types ``Floating``, ``Long_Floating``,
839 ``Binary``, ``Long_Binary``, ``Decimal_ Element``, and
840 ``COBOL_Character``; and the initialization of the variables
841 ``Ada_To_COBOL`` and ``COBOL_To_Ada``, in
842 ``Interfaces.COBOL``. See B.4(50)."
844 ===================== ====================================
846 ===================== ====================================
848 *Long_Floating* (Floating) Long_Float
850 *Long_Binary* Long_Long_Integer
851 *Decimal_Element* Character
852 *COBOL_Character* Character
853 ===================== ====================================
855 For initialization, see the file :file:`i-cobol.ads` in the distributed library.
858 "Support for access to machine instructions. See C.1(1)."
860 See documentation in file :file:`s-maccod.ads` in the distributed library.
863 "Implementation-defined aspects of access to machine
864 operations. See C.1(9)."
866 See documentation in file :file:`s-maccod.ads` in the distributed library.
869 "Implementation-defined aspects of interrupts. See C.3(2)."
871 Interrupts are mapped to signals or conditions as appropriate. See
873 ``Ada.Interrupt_Names`` in source file :file:`a-intnam.ads` for details
874 on the interrupts supported on a particular target.
877 "Implementation-defined aspects of pre-elaboration. See
880 GNAT does not permit a partition to be restarted without reloading,
881 except under control of the debugger.
884 "The semantics of pragma ``Discard_Names``. See C.5(7)."
886 Pragma ``Discard_Names`` causes names of enumeration literals to
887 be suppressed. In the presence of this pragma, the Image attribute
888 provides the image of the Pos of the literal, and Value accepts
891 For tagged types, when pragmas ``Discard_Names`` and ``No_Tagged_Streams``
892 simultaneously apply, their Expanded_Name and External_Tag are initialized
893 with empty strings. This is useful to avoid exposing entity names at binary
897 "The result of the ``Task_Identification.Image``
898 attribute. See C.7.1(7)."
900 The result of this attribute is a string that identifies
901 the object or component that denotes a given task. If a variable ``Var``
902 has a task type, the image for this task will have the form :samp:`Var_{XXXXXXXX}`,
903 where the suffix *XXXXXXXX*
904 is the hexadecimal representation of the virtual address of the corresponding
905 task control block. If the variable is an array of tasks, the image of each
906 task will have the form of an indexed component indicating the position of a
907 given task in the array, e.g., :samp:`Group(5)_{XXXXXXX}`. If the task is a
908 component of a record, the image of the task will have the form of a selected
909 component. These rules are fully recursive, so that the image of a task that
910 is a subcomponent of a composite object corresponds to the expression that
911 designates this task.
913 If a task is created by an allocator, its image depends on the context. If the
914 allocator is part of an object declaration, the rules described above are used
915 to construct its image, and this image is not affected by subsequent
916 assignments. If the allocator appears within an expression, the image
917 includes only the name of the task type.
919 If the configuration pragma Discard_Names is present, or if the restriction
920 No_Implicit_Heap_Allocation is in effect, the image reduces to
921 the numeric suffix, that is to say the hexadecimal representation of the
922 virtual address of the control block of the task.
925 "The value of ``Current_Task`` when in a protected entry
926 or interrupt handler. See C.7.1(17)."
928 Protected entries or interrupt handlers can be executed by any
929 convenient thread, so the value of ``Current_Task`` is undefined.
932 "The effect of calling ``Current_Task`` from an entry
933 body or interrupt handler. See C.7.1(19)."
935 When GNAT can determine statically that ``Current_Task`` is called directly in
936 the body of an entry (or barrier) then a warning is emitted and ``Program_Error``
937 is raised at run time. Otherwise, the effect of calling ``Current_Task`` from an
938 entry body or interrupt handler is to return the identification of the task
939 currently executing the code.
942 "Implementation-defined aspects of
943 ``Task_Attributes``. See C.7.2(19)."
945 There are no implementation-defined aspects of ``Task_Attributes``.
948 "Values of all ``Metrics``. See D(2)."
950 The metrics information for GNAT depends on the performance of the
951 underlying operating system. The sources of the run-time for tasking
952 implementation, together with the output from *-gnatG* can be
953 used to determine the exact sequence of operating systems calls made
954 to implement various tasking constructs. Together with appropriate
955 information on the performance of the underlying operating system,
956 on the exact target in use, this information can be used to determine
957 the required metrics.
960 "The declarations of ``Any_Priority`` and
961 ``Priority``. See D.1(11)."
963 See declarations in file :file:`system.ads`.
966 "Implementation-defined execution resources. See D.1(15)."
968 There are no implementation-defined execution resources.
971 "Whether, on a multiprocessor, a task that is waiting for
972 access to a protected object keeps its processor busy. See D.2.1(3)."
974 On a multi-processor, a task that is waiting for access to a protected
975 object does not keep its processor busy.
978 "The affect of implementation defined execution resources
979 on task dispatching. See D.2.1(9)."
981 Tasks map to threads in the threads package used by GNAT. Where possible
982 and appropriate, these threads correspond to native threads of the
983 underlying operating system.
986 "Implementation-defined *policy_identifiers* allowed
987 in a pragma ``Task_Dispatching_Policy``. See D.2.2(3)."
989 There are no implementation-defined policy-identifiers allowed in this
993 "Implementation-defined aspects of priority inversion. See
996 Execution of a task cannot be preempted by the implementation processing
997 of delay expirations for lower priority tasks.
1000 "Implementation-defined task dispatching. See D.2.2(18)."
1002 The policy is the same as that of the underlying threads implementation.
1005 "Implementation-defined *policy_identifiers* allowed
1006 in a pragma ``Locking_Policy``. See D.3(4)."
1008 The two implementation defined policies permitted in GNAT are
1009 ``Inheritance_Locking`` and ``Concurrent_Readers_Locking``. On
1010 targets that support the ``Inheritance_Locking`` policy, locking is
1011 implemented by inheritance, i.e., the task owning the lock operates
1012 at a priority equal to the highest priority of any task currently
1013 requesting the lock. On targets that support the
1014 ``Concurrent_Readers_Locking`` policy, locking is implemented with a
1015 read/write lock allowing multiple protected object functions to enter
1019 "Default ceiling priorities. See D.3(10)."
1021 The ceiling priority of protected objects of the type
1022 ``System.Interrupt_Priority'Last`` as described in the Ada
1023 Reference Manual D.3(10),
1026 "The ceiling of any protected object used internally by
1027 the implementation. See D.3(16)."
1029 The ceiling priority of internal protected objects is
1030 ``System.Priority'Last``.
1033 "Implementation-defined queuing policies. See D.4(1)."
1035 There are no implementation-defined queuing policies.
1038 "On a multiprocessor, any conditions that cause the
1039 completion of an aborted construct to be delayed later than what is
1040 specified for a single processor. See D.6(3)."
1042 The semantics for abort on a multi-processor is the same as on a single
1043 processor, there are no further delays.
1046 "Any operations that implicitly require heap storage
1047 allocation. See D.7(8)."
1049 The only operation that implicitly requires heap storage allocation is
1053 "What happens when a task terminates in the presence of
1054 pragma ``No_Task_Termination``. See D.7(15)."
1056 Execution is erroneous in that case.
1059 "Implementation-defined aspects of pragma
1060 ``Restrictions``. See D.7(20)."
1062 There are no such implementation-defined aspects.
1065 "Implementation-defined aspects of package
1066 ``Real_Time``. See D.8(17)."
1068 There are no implementation defined aspects of package ``Real_Time``.
1071 "Implementation-defined aspects of
1072 *delay_statements*. See D.9(8)."
1074 Any difference greater than one microsecond will cause the task to be
1075 delayed (see D.9(7)).
1078 "The upper bound on the duration of interrupt blocking
1079 caused by the implementation. See D.12(5)."
1081 The upper bound is determined by the underlying operating system. In
1082 no cases is it more than 10 milliseconds.
1085 "The means for creating and executing distributed
1086 programs. See E(5)."
1088 The GLADE package provides a utility GNATDIST for creating and executing
1089 distributed programs. See the GLADE reference manual for further details.
1092 "Any events that can result in a partition becoming
1093 inaccessible. See E.1(7)."
1095 See the GLADE reference manual for full details on such events.
1098 "The scheduling policies, treatment of priorities, and
1099 management of shared resources between partitions in certain cases. See
1102 See the GLADE reference manual for full details on these aspects of
1103 multi-partition execution.
1106 "Events that cause the version of a compilation unit to
1107 change. See E.3(5)."
1109 Editing the source file of a compilation unit, or the source files of
1110 any units on which it is dependent in a significant way cause the version
1111 to change. No other actions cause the version number to change. All changes
1112 are significant except those which affect only layout, capitalization or
1116 "Whether the execution of the remote subprogram is
1117 immediately aborted as a result of cancellation. See E.4(13)."
1119 See the GLADE reference manual for details on the effect of abort in
1120 a distributed application.
1123 "Implementation-defined aspects of the PCS. See E.5(25)."
1125 See the GLADE reference manual for a full description of all implementation
1126 defined aspects of the PCS.
1129 "Implementation-defined interfaces in the PCS. See
1132 See the GLADE reference manual for a full description of all
1133 implementation defined interfaces.
1136 "The values of named numbers in the package
1137 ``Decimal``. See F.2(7)."
1139 ==================== ==========
1141 ==================== ==========
1146 *Max_Decimal_Digits* 18
1147 ==================== ==========
1150 "The value of ``Max_Picture_Length`` in the package
1151 ``Text_IO.Editing``. See F.3.3(16)."
1156 "The value of ``Max_Picture_Length`` in the package
1157 ``Wide_Text_IO.Editing``. See F.3.4(5)."
1162 "The accuracy actually achieved by the complex elementary
1163 functions and by other complex arithmetic operations. See G.1(1)."
1165 Standard library functions are used for the complex arithmetic
1166 operations. Only fast math mode is currently supported.
1169 "The sign of a zero result (or a component thereof) from
1170 any operator or function in ``Numerics.Generic_Complex_Types``, when
1171 ``Real'Signed_Zeros`` is True. See G.1.1(53)."
1173 The signs of zero values are as recommended by the relevant
1174 implementation advice.
1177 "The sign of a zero result (or a component thereof) from
1178 any operator or function in
1179 ``Numerics.Generic_Complex_Elementary_Functions``, when
1180 ``Real'Signed_Zeros`` is ``True``. See G.1.2(45)."
1182 The signs of zero values are as recommended by the relevant
1183 implementation advice.
1186 "Whether the strict mode or the relaxed mode is the
1187 default. See G.2(2)."
1189 The strict mode is the default. There is no separate relaxed mode. GNAT
1190 provides a highly efficient implementation of strict mode.
1193 "The result interval in certain cases of fixed-to-float
1194 conversion. See G.2.1(10)."
1196 For cases where the result interval is implementation dependent, the
1197 accuracy is that provided by performing all operations in 64-bit IEEE
1198 floating-point format.
1201 "The result of a floating point arithmetic operation in
1202 overflow situations, when the ``Machine_Overflows`` attribute of the
1203 result type is ``False``. See G.2.1(13)."
1205 Infinite and NaN values are produced as dictated by the IEEE
1206 floating-point standard.
1207 Note that on machines that are not fully compliant with the IEEE
1208 floating-point standard, such as Alpha, the *-mieee* compiler flag
1209 must be used for achieving IEEE conforming behavior (although at the cost
1210 of a significant performance penalty), so infinite and NaN values are
1214 "The result interval for division (or exponentiation by a
1215 negative exponent), when the floating point hardware implements division
1216 as multiplication by a reciprocal. See G.2.1(16)."
1218 Not relevant, division is IEEE exact.
1221 "The definition of close result set, which determines the
1222 accuracy of certain fixed point multiplications and divisions. See
1225 Operations in the close result set are performed using IEEE long format
1226 floating-point arithmetic. The input operands are converted to
1227 floating-point, the operation is done in floating-point, and the result
1228 is converted to the target type.
1231 "Conditions on a *universal_real* operand of a fixed
1232 point multiplication or division for which the result shall be in the
1233 perfect result set. See G.2.3(22)."
1235 The result is only defined to be in the perfect result set if the result
1236 can be computed by a single scaling operation involving a scale factor
1237 representable in 64 bits.
1240 "The result of a fixed point arithmetic operation in
1241 overflow situations, when the ``Machine_Overflows`` attribute of the
1242 result type is ``False``. See G.2.3(27)."
1244 Not relevant, ``Machine_Overflows`` is ``True`` for fixed-point
1248 "The result of an elementary function reference in
1249 overflow situations, when the ``Machine_Overflows`` attribute of the
1250 result type is ``False``. See G.2.4(4)."
1252 IEEE infinite and Nan values are produced as appropriate.
1255 "The value of the angle threshold, within which certain
1256 elementary functions, complex arithmetic operations, and complex
1257 elementary functions yield results conforming to a maximum relative
1258 error bound. See G.2.4(10)."
1260 Information on this subject is not yet available.
1263 "The accuracy of certain elementary functions for
1264 parameters beyond the angle threshold. See G.2.4(10)."
1266 Information on this subject is not yet available.
1269 "The result of a complex arithmetic operation or complex
1270 elementary function reference in overflow situations, when the
1271 ``Machine_Overflows`` attribute of the corresponding real type is
1272 ``False``. See G.2.6(5)."
1274 IEEE infinite and Nan values are produced as appropriate.
1277 "The accuracy of certain complex arithmetic operations and
1278 certain complex elementary functions for parameters (or components
1279 thereof) beyond the angle threshold. See G.2.6(8)."
1281 Information on those subjects is not yet available.
1284 "Information regarding bounded errors and erroneous
1285 execution. See H.2(1)."
1287 Information on this subject is not yet available.
1290 "Implementation-defined aspects of pragma
1291 ``Inspection_Point``. See H.3.2(8)."
1293 Pragma ``Inspection_Point`` ensures that the variable is live and can
1294 be examined by the debugger at the inspection point.
1297 "Implementation-defined aspects of pragma
1298 ``Restrictions``. See H.4(25)."
1300 There are no implementation-defined aspects of pragma ``Restrictions``. The
1301 use of pragma ``Restrictions [No_Exceptions]`` has no effect on the
1302 generated code. Checks must suppressed by use of pragma ``Suppress``.
1305 "Any restrictions on pragma ``Restrictions``. See
1308 There are no restrictions on pragma ``Restrictions``.