home *** CD-ROM | disk | FTP | other *** search
/ DP Tool Club 3 / CDASC03.ISO / sorties / 118 / lrm_13 < prev    next >
Text File  |  1993-04-01  |  47KB  |  1,007 lines
  1.  
  2. Copyright 1980, 1982, 1983, owned by the United States Government as 
  3. represented by the Under Secretary of Defense, Research and Engineering.  All 
  4. rights resrved.  Provided that notice of copyright is included on the first 
  5. page, this document may be copied in its entirety without alteration or as 
  6. altered by (1) adding text that is clearly marked as an insertion; (2) shading 
  7. or alteration or highlighting existing text; (3) deleting examples.  
  8. Permission to publish other excerpts should be obtained from the Ada Joint 
  9. Program Office, OUSDRE(R&AT), The Pentagon, Washington, D.C. 20301, U.S.A.
  10.  
  11. ------------------------------------------------------------------------------
  12. ------------------------------------------------------------------------------       
  13.  
  14.  
  15.    13.1 Representation Clauses and Implementation-Dependent Features
  16.  
  17. This chapter describes representation clauses, certain implementation-
  18. dependent features, and other features that are used in system 
  19. programming.
  20.  
  21. 13.1 Representation Clauses
  22.  
  23. Representation clauses specify how the types of the language are to be 
  24. mapped onto the underlying machine.  They can be provided to give more 
  25. efficient representation or to interface with features that are outside 
  26. the domain of the language (for example, peripheral hardware).
  27.  
  28.         representation_clause ::=
  29.               type_representation_clause | address_clause
  30.  
  31.         type_representation_clause ::= length_clause
  32.               | enumeration_representation_clause 
  33.               |record_representation_clause
  34.  
  35. A type representation clause applies either to a type or to a first 
  36. named subtype (that is, to a subtype declared by a type declaration, 
  37. the base type being therefore anonymous).  Such a representation 
  38. clause applies to  all objects that have this type or this first named 
  39. subtype.  At most one enumeration or record representation clause is 
  40. allowed for a given type: an enumeration representation clause is only 
  41. allowed for an enumeration type; a record representation clause, only 
  42. for a record type.  (On the other hand, more than one length clause 
  43. can be provided for a given type; moreover, both a length clause and 
  44. an enumeration or record representation clause can be provided.)  A 
  45. length clause is the only form of representation clause allowed for a 
  46. type derived from a parent type that has (user-defined) derivable 
  47. subprograms.
  48.  
  49. An address clause applies either to an object; to a subprogram, 
  50. package, or task unit; or to an entry.  At most one address clause is 
  51. allowed for any of these entities.
  52.  
  53. A representation clause and declaration of the entity to which the 
  54. clause applies must both occur immediately within the same declarative 
  55. part, package specification, or task specification; the declaration 
  56. must occur before the clause.  In the absence of a representation 
  57. clause for a given declaration, a default representation of this 
  58. declaration is determined by the implementation.  Such a default 
  59. determination occurs no later than the end of the immediately 
  60. enclosing declarative part, package specification, or task 
  61. specification.  For a declaration given in a declarative part, this 
  62. default determination occurs before any enclosed body.
  63.  
  64. In the case of a type, certain occurrences of its name imply that the 
  65. representation of the type must already have been determined.  
  66. Consequently these occurrences force the default determination of any 
  67. aspect of the representation not already determined by a prior type 
  68. representation clause.  This default determination is also forced by 
  69. similar occurrences of the name of a subtype of the type, or of the 
  70. name of any type or subtype that has subcomponents of the type.  A
  71. forcing occurence is any occurrence other than in a type or subtype 
  72. declaration, a subprogram specification, an entry declaration, a deferred 
  73. constant declaration, a pragma, or a representation clause for the type 
  74. itself. In any case, an occurrence within an expression is always forcing.
  75. 
  76.  
  77. A representation clause for a given entity must not appear after an 
  78. occurrence of the name of the entity if this occurrence forces a 
  79. default determination of representation for the entity.
  80.  
  81. Similar restrictions exist for address clauses. For an object, any 
  82. occurrence of its name (after the object declaration) is a forcing 
  83. occurrence.  For a subprogram, package, task unit, or entry, any 
  84. occurrence of a representation attribute of such an entity is a 
  85. forcing occurrence.
  86.  
  87. The effect of the elaboration of a representation clause is to define 
  88. the corresponding aspects of the representation. 
  89.  
  90. The interpretation of some of the expressions that appear in 
  91. representation clauses is implementation_dependent, for example, 
  92. expressions specifying addresses.  An implementation may limit its 
  93. acceptance of representation clauses to those that can be handled 
  94. simply by the underlying hardware.  If a representation clause is 
  95. accepted by an implementation, the compiler must guarantee that the 
  96. net effect of the program is not changed by the presence of the clause, except 
  97. for address clauses and for parts of the program that interrogate
  98. representation attributes. If a program contains a representation clause 
  99. that is not accepted, the program is illegal.  For each implementation, 
  100. the allowed representation clauses, and the conventions used for implementation-
  101. dependent expressions, must be documented in Appendix F of the 
  102. reference manual.
  103.  
  104. Whereas a representation clause is used to impose certain 
  105. characteristics of the mapping of an entity onto the underlying 
  106. machine, pragmas can be used to provide an implementation, with 
  107. criteria for its selection of such a mapping.  The pragma PACK 
  108. specifies that storage minimization should be the main criterion when 
  109. selecting the representation of a record or array type.  Its form is 
  110. as follows:
  111.  
  112.         pragma PACK (type_simple_name);
  113.  
  114. Packing means that gaps between the storage areas allocated to 
  115. consecutive components should be minimized.  It need not, however, 
  116. affect the mapping of each component onto storage.  This mapping can 
  117. itself be influenced by a pragma (or controlled by a representation 
  118. clause) for the component or component type.  The position of a PACK 
  119. pragma, and the restrictions on the named type, are governed by the 
  120. same rules as for a representation clause; in particular, the pragma 
  121. must appear before any use of a representation attribute of the packed 
  122. entity.
  123.  
  124. The pragma PACK is the only language-defied representation pragma. 
  125. Additional representation pragmas may be provided by an 
  126. implementation; these must be documented in Appendix F. (in contrast 
  127. to representation clauses, a pragma that is not accepted by the 
  128. implementation is ignored).
  129.  
  130. Note:
  131.  
  132. No representation clause is allowed for a generic formal type. 
  133.  
  134. References: address clause 13.5, allow 1.6, body 3.9, component 3.3, 
  135. declaration 3.1, declarative part 3.9, default expression 3.2.1, 
  136. deferred constant declaration 7.4, derivable subprogram 3.4, derived 
  137. type 3.4, entity 3.1, entry 9.5, enumeration representation clause 
  138. 13.3, expression 4.4, generic formal type 12.1.2, illegal 1.6, length 
  139. clause 13.2, must 1.6, name 4.1, object 3.2, occur immediately within 
  140. 8.1, package 7, package specification 7.1, parent type 3.4, pragma 
  141. 2.8, record representation clause 13.4, representation attribute 
  142. 13.7.2, 13.7.3, subcomponent 3.3, subprogram 6, subtype 3.3, subtype 
  143. declaration 3.3.2, task specification 9.1, task unit 9, type 3.3, type 
  144. declaration 3.3.1
  145.  
  146.  
  147. 13.2 Length Clauses
  148.  
  149. A length clause specifies an amount of storage associated with a type.
  150.  
  151. length_clause ::= for attribute use simple_expression;
  152.  
  153. The expression must be of some numeric type and is evaluated during the 
  154. elaboration of the length clause (unless it is a static expression).  The 
  155. prefix of the attribute must denote either a type or a first named subtype.  
  156. The prefix is called T in what follows.  The only allowed attribute 
  157. designators in a length clause are SIZE, STORAGE_SIZE, and SMALL.  The effect 
  158. of the length clause depends on the attribute designator:
  159.  
  160. (a)  Size specification: T'SIZE
  161.  
  162.      The expression must be a static expression of some integer type.  The
  163.      value of the expression specifies an upper bound for the number of bits 
  164.      to be allocated to objects of the type or first named subtype T.  The
  165.      size specification must allow for enough storage space to accommodate
  166.      every allowable value of these objects.  A size specification for a 
  167.      composite type may affect the size of the gaps between the storage areas 
  168.      allocated to consecutive components. On the other hand, it need not 
  169.      affect the size of the storage area allocated to each component.
  170.  
  171.      The size specification is only allowed if the constraints on T and on its 
  172.      subcomponents (if any) are static.  In the case of an unconstrained 
  173.      array type, the index subtypes must also be static.  
  174.  
  175. (b)  Specification of collection size: T'STORAGE_SIZE
  176.  
  177.      The prefix T must denote an access type. The expression must be of some 
  178.      integer type (but need not be static); its value specifies the number of 
  179.      storage units to be reserved for the collection, that is, the storage 
  180.      space needed to contain all objects designated by values of the access 
  181.      type and by values of other types derived form the access type, directly 
  182.      or indirectly.  This form of length clause is not allowed for a type 
  183.      derived from an access type.
  184.  
  185. (c)  Specification of storage for a task activation: T'STORAGE _SIZE
  186.  
  187.      The prefix T must denote a task type.  The expression must be of some 
  188.      integer type (but need not be static); its value specifies the number of 
  189.      storage units to be reserved for an activation (not the code) of a task 
  190.      of the type.
  191.  
  192. (d)  Specification of small for a fixed point type: T'SMALL
  193.  
  194.      The prefix T must denote the first named subtype of a fixed point type.  
  195.      The expression must be a static expression of some real type; its value 
  196.      must be greater than the delta of the first named subtype.  The effect of 
  197.      the length clause is to use this value of small for the representation of 
  198.      values of the fixed point base type.  (The length clause thereby also 
  199.      affects the amount of storage for objects that have this type).
  200.  
  201.  
  202. Notes:
  203.  
  204. A size specification is allowed for an access, task, or fixed point type, 
  205. whether or not another form of length clause is also given for the type.  
  206.  
  207. What is considered to be part of the storage reserved for a collection or 
  208. for an activation of a task is implementation-dependent.  The control 
  209. afforded by length clauses is therefore relative to the implementation
  210. conventions.  For example, the language does not define whether the storage 
  211. reserved for an activation of a task includes any storage needed for the 
  212. collection associated with an access type declared within the task body.  
  213. Neither does it define the method of allocation for objects denoted by 
  214. values of an access type.  For example, the space allocated could be on a 
  215. stack; alternatively, a general dynamic aliocation scheme or fixed storage 
  216. could be used.  
  217.  
  218. The objects allocated in a collection need not have the same size if the 
  219. designated type is an unconstrained array type or an unconstrained type with 
  220. discriminants.  Note also that the allocator itself may require some space 
  221. for internal tables and links.  Hence a length clause for the collection of 
  222. an access type does not always give precise control over the maximum number 
  223. of allocated objects.
  224.  
  225. Examples:
  226.  
  227.       --assumed declarations:
  228.  
  229.       type MEDIUM is range 0 .. 65000;
  230.       type SHORT  is delta 0.01 range -100.0 .. 100.0;
  231.       type DEGREE is delta 0.1  range -360.0 .. 360.0;
  232.  
  233.       BYTE  : constant := 8;
  234.       PAGE  : constant := 2000;
  235.  
  236.       --length clauses:
  237.  
  238.       for COLOR'SIZE  use 1*BYTE; -- see 3.5.1
  239.       for MEDIUM'SIZE use 2*BYTE;
  240.       for SHORT'SIZE  use 15;
  241.  
  242.       for CAR_NAME'STORAGE_SIZE use -- approximately 2000 cars
  243.               2000*((CAR'SIZE/SYSTEM.STORAGE_UNIT) +1);
  244.  
  245.       for KEYBOARD_DRIVERS'STORAGE_SIZE use 1*PAGE;
  246.  
  247. for DEGREE'SMALL use 360.0/2**(SYSTEM.STORAGE_UNIT -1);
  248.  
  249. Notes on the examples:
  250.  
  251. In the length clause for SHORT, fifteen bits is the minimum necessary, 
  252. since the type definition requires SHORT'SMALL=2**(-7) and SHORT'MANTISSA = 
  253. 14.  The length clause for DEGREE forces the model numbers to exactly span 
  254. the range of the type.
  255.  
  256. References: access type 3.8, allocator 4.8, allow 1.6, array type 3.6, 
  257. attribute 4.1.4, collection 3.8, composite type 3.3, constraint 3.3, delta 
  258. of a fixed point  type 3.5.9, derived type 3.4, designate 3.8, elaboration 
  259. 3.9, entity 3.1, evaluation 4.5, expression 4.4, first named subtype 13.1, 
  260. fixed point type 3.5.9, index subtype 3.6, integer type 3.5.4, must 1.6, 
  261. numeric type 3.5, object 3.2, real type 3.5.6, record type 3.7, small of a 
  262. fixed point type 3.5.10, static constraint 4.9, static expression 4.9, 
  263. static subtype 4.9, storage unit 13.7, subcomponent 3.3, system package 
  264. 13.7, task 9, task activation 9.3, task specification 9.1, task type 9.2, 
  265. type 3.3, unconstrained array type 3.6           
  266.  
  267. 13.3 Enumeration Representation Clauses
  268.  
  269. An enumeration representation clause specifies the internal codes for the 
  270. literals of the enumeration type that is named in the clause.
  271.  
  272.       enumeration_representation_clause ::= for type_simple_name use 
  273.                aggregate;
  274.  
  275. The aggregate used to specify this mapping is written as a one-dimensional 
  276. aggregate, for which the index subtype is the enumeration type and the 
  277. component type is universal_integer.
  278.  
  279. All literals of the enumeration type must be provided with distinct integer 
  280. codes, and all choices and component values given in the aggregate must be 
  281. static.  The integer codes specified for the enumeration type must satisfy 
  282. the predefined ordering relation of the type.
  283.  
  284. Example:
  285.  
  286.       type MIX_CODE is (ADD, SUB, MUL, LDA, STA, STZ);
  287.  
  288.       for MIX_CODE use
  289.          (ADD => 1, SUB =.2, MUL => 3, LDA => 8, STA => 24, STZ =>33);
  290.  
  291. Notes:
  292.  
  293. The attributes SUCC, PRED, and POS are defined even for enumeration types 
  294. with a noncontiguous representation; their definition corresponds to the 
  295. (logical) type declaration and is not affected by the enumeration 
  296. representation clause.  In the example, because of the need to avoid the 
  297. omitted values, these functions are likely to be less efficiently 
  298. implemented than they could be in the absence of a representation clause.  
  299. Similar considerations apply when such types are used for indexing.
  300.  
  301. References: aggregate 4.3, array aggregate 4.3.2, array type 3.6, attribute 
  302. of an enumeration type 3.5.5, choice 3.7.3, component 3.3, enumeration 
  303. literal 3.5.1, enumeration type 3.5.1, function 6.5, index 3.6, index 
  304. subtype 3.6, literal 4.2, ordering relation of an enumeration type 3.5.1, 
  305. representation clause 13.1, simple name 4.1, static expression 4.9, type 
  306. 3.3, type declaration 3.3.1, universal_integer type 3.5.4
  307.  
  308. 13.4 Record Representation Clauses
  309.  
  310. A record representation clause specifies the storage representation of 
  311. records, that is, the order, position, and size of record components 
  312. (including discriminants, if any).
  313.  
  314.       record_representation_clause ::=
  315.         for type_simple_name use
  316.           record [alignment_clause]
  317.             {component clause}
  318.           end record;
  319.  
  320.       alignment_clause ::= at mod static_simple_expression;
  321.  
  322.       component_clause ::=
  323.         component_name at static_simple_expression range static_range;
  324. 
  325.  
  326. The simple expression given after the reserved words at mod in an alignment 
  327. clause, or after the reserved word at in a component clause, must be a 
  328. static expression of some integer type.  If the bounds of the range of a 
  329. component clause are defined by simple expressions, then each bound of the
  330. range must be defined by a static expression of some integer type, but the 
  331. two bounds need not have the same integer type.
  332.  
  333. An alignment clause forces each record of the given type to be allocated at 
  334. a starting address that is a multiple of the value of the given expression 
  335. (that is, the address modulo the expression must be zero). An 
  336. implementation may place restrictions on the allowable alignments. 
  337.  
  338. A component clause specifies the storage place of a component, relative to 
  339. the start of the record.  The integer defined by the static expression of a 
  340. component clause is a relative address expressed in storage units.  The 
  341. range defines the bit positions of the storage place, relative to the 
  342. storage unit.  The first storage unit of a record is numbered zero.The 
  343. first bit of a storage unit is numbered zero.  The ordering of bits in a 
  344. storage unit is machine_dependent and may extend to adjacent storage units 
  345. (For a specific machine, the size in bits of a storage unit is given by the 
  346. configuration-dependent named number SYSTEM.STORAGE_UNIT.)  Whether a 
  347. component is allowed to overlap a storage boundary, and if so, how, is 
  348. implementation-defined.
  349.  
  350. At most one component clause is allowed for each component of the record 
  351. type, including for each discriminant (component clauses may be given for 
  352. some, all, or none of the components).  If no component clause is given for 
  353. a component, then the choice of the storage place for the component is left 
  354. to the compiler. If component clauses are given for all components, the 
  355. record representation clause completely specifies the representation of the 
  356. record type and must be obeyed exactly by the compiler.
  357.  
  358. Storage places within a record variant must not overlap, but overlap of the 
  359. storage for distinct variants is allowed.  Each component clause must allow 
  360. for enough storage space to accommodate  every allowable value of the 
  361. component.  A component clause is only allowed for a component if any 
  362. constraint on this component or on any of its subcomponents is static.
  363.  
  364. An implementation may generate names that denote implementation-dependent 
  365. components (for example, one containing the offset of another component).  
  366. Such implementation-dependent names can be used in record representation 
  367. clauses (these names need not be simple names; for example, they could be 
  368. implementation-dependent attributes).
  369.  
  370. Example:
  371.  
  372.       WORD : constant := 4;  --  storage unit is byte, 4 bytes per word
  373.  
  374. type STATE         is (A,M,W,P);
  375. type MODE          is (FIX, DEC, EXP, SIGNIF);
  376.  
  377. type BYTE_MASK     is array (0.. 7) of BOOLEAN;
  378. type STATE_MASK    is array (STATE) of BOOLEAN;
  379. type MODE_MASK     is array (MODE)  of BOOLEAN;
  380.  
  381. type PROGRAM_STATUS_WORD is
  382.   record
  383.       SYSTEM_MASK        : BYTE_MASK;
  384.       PROTECTION_KEY     : INTEGER range 0 .. 3;
  385.       MACHINE_STATE      : STATE_MASK;
  386.       INTERRUPT_CAUSE    : INTERRUPTION_CODE;
  387.       ILC                : INTEGER range 0 .. 3;
  388.       CC                 : INTEGER range 0 .. 3;
  389.       PROGRAM_MASK       : MODE_MASK;
  390.       INST_ADDRESS       : ADDRESS;
  391. end record;
  392. 
  393.  
  394.   for PROGRAM_STATUS_WORD use
  395.     record at mod 8;
  396.         SYSTEM_MASK      at 0*WORD range 0  .. 7;  
  397.         PROTECTION_KEY   at 0*WORD range 10 .. 11; -- bits 8,9 unused
  398.         MACHINE_STATE    at 0*WORD range 12 .. 15;
  399.         INTERRUPT_CAUSE  at 0*WORD range 16 .. 31;
  400.         ILC              at 1*WORD range 0  .. 1;  -- second word
  401.         CC               at 1*WORD range 2  .. 3;
  402.         PROGRAM_MASK     at 1*WORD range 4  .. 7;
  403.         INST_ADDRESS     at 1*WORD range 8  .. 31;
  404.     end record;
  405.  
  406.   for PROGRAM_STATUS_WORD'SIZE use 8*SYSTEM.STORAGE_UNIT;
  407.  
  408. Note on the example:
  409.  
  410. The record representation clause defines the record layout.  The length 
  411. clause guarantees that exactly eight storage units are used.
  412.  
  413. References: allow 1.6, attribute 4.1.4, constant 3.2.1, constraint 3.3, 
  414. discriminant 3.7.1, integer type 3.5.4, must 1.6, named number 3.2, range 
  415. 3.5, record component 3.7, record type 3.7, simple expression 4.4, simple 
  416. name 4.1, static constraint 4.9, static expression 4.9, storage unit 13.7, 
  417. subcomponent 3.3, system package 13.7, variant 3.7.3
  418.  
  419. 13.5 Address Clauses
  420.  
  421. An address clause specifies a required address in storage for an entity.
  422.  
  423.       address_clause ::= for simple_name use at simple_expression;
  424.  
  425. The expression given after the reserved word at must be of the type ADDRESS 
  426. defined in the package SYSTEM (see 13.7); this package must be named by a 
  427. with clause that applies to the compilation unit in which the address 
  428. clause occurs.  The conventions that define the interpretation of a value 
  429. of the type ADDRESS as an address, as an interrupt level, or whatever it 
  430. may be, are implementation-dependent.  The allowed nature of the simple 
  431. name and the meaning of the corresponding address are as follows:
  432.  
  433. (a) Name of an object: the address is that required for the object 
  434.     (variable or constant).
  435.  
  436. (b) Name of a subprogram, package, or task unit: the address is that
  437.     required for the machine code associated with the body of the program 
  438.     unit.
  439.  
  440. (c) Name of a single entry: the address specifies a hardware interrupt to 
  441.     which the single entry is to be linked.
  442.  
  443. If the simple name is that of a single task, the address clause is 
  444. understood to refer to the task unit and not to the task object.  In all 
  445. cases, the address clause is only legal if exactly one declaration with 
  446. this identifier occurs earlier, immediately within the same declarative 
  447. part, package specification, or task specification.  A name declared by a 
  448. renaming declaration is not allowed as the simple name.  
  449.  
  450. Address clauses should not be used to achieve overlays of objects or 
  451. overlays of program units. Nor should a given interrupt be linked to more 
  452. than one entry. Any program using address clauses to achieve such effects 
  453. is erroneous.
  454. 
  455.  
  456. Example:
  457.  
  458.     for CONTROL use at 16#0020#; -- assuming that SYSTEM.ADDRESS is an integer 
  459.     type
  460.  
  461. Notes:
  462.  
  463. The above rules imply that if two subprograms overload each other and are 
  464. visible at a given point, an address clause for any of them is not legal at 
  465. this point.  Similarly if a task specification declares entries that 
  466. overload each other, they cannot be interrupt entries.  The syntax does not 
  467. allow an address clause for a library unit.  An implementation may provide 
  468. pragmas for the specification of program overlays. 
  469.  
  470. References: address predefined type 13.7, apply 10.1.1, compilation unit 
  471. 10.1, constant 3.2.1, entity 3.1, entry 9.5, erroneous 1.6, expression 
  472. 4.4, library unit 10.1, name 4.1, object 3.2, package 7, pragma 2.8, 
  473. program unit 6, reserved word 2.9, simple expression 4.4, simple name 4.1, 
  474. subprogram 6, subprogram body 6.3, system package 13.7, task body 9.1, task 
  475. object 9.2, task unit 9, type 3.3, variable 3.2.1, with clause 10.1.1
  476.  
  477. 13.5.1 Interrupts 
  478.  
  479. An address clause given for an entry associates the entry with some device 
  480. that may cause an interrupt; such an entry is referred to in this section 
  481. as an interrupt entry.  If control information is supplied upon an 
  482. interrupt, it is passed to an associated interrupt entry as one or more 
  483. parameters of mode in; only parameters of this mode are allowed.
  484.  
  485. An interrupt acts as an entry call issued by a hardware task whose priority 
  486. is higher than the priority of the main program, and also higher than the 
  487. priority of any user-defined task (that is, any task whose type is declared 
  488. by a task unit in the program).  The entry call may be an ordinary entry 
  489. call, a timed entry call, or a conditional entry call, depending on the 
  490. kind of interrupt and on the implementation.  
  491.  
  492. If a select statement contains both a terminate alternative and an accept 
  493. alternative for an interrupt entry, then an implementation may impose 
  494. further requirements for the selection of the terminate alternative in 
  495. addition to those given in section 9.4.
  496.  
  497. Example:
  498.  
  499.       task INTERRUPT_HANDLER is
  500.         entry DONE;
  501.         for DONE use at 16#40#; assuming that SYSTEM.ADDRESS is an integer 
  502.           type
  503.         end INTERRUPT_HANDLER;
  504.  
  505. Notes: 
  506.  
  507. Interrupt entry calls need only have the semantics described above; they 
  508. may be implemented by having the hardware directly execute the appropriate 
  509. accept statements. 
  510.  
  511. Queued interrupts correspond to ordinary entry calls. Interrupts that are 
  512. lost if not immediately processed correspond to conditional entry calls. It 
  513. is a consequence of the priority rules that an accept statement executed in 
  514. response to an interrupt takes precedence over ordinary, user-defined 
  515. tasks, and can be executed without first invoking a scheduling action.
  516. 
  517. One of the possible effects of an address clause for an interrupt entry is 
  518. to specify the priority of the interrupt (directly or indirectly).  Direct 
  519. calls to an interrupt entry are allowed. 
  520.  
  521. References: accept alternative 9.7.1, accept statement 9.5, address 
  522. predefined type 13.7, allow 1.6, conditional entry call 9.7.2, entry 9.5, 
  523. mode 6.1, parameter of a subprogram 6.2, priority of a task 9.8, select 
  524. alternative 9.7.1, select statement 9.7, system package 13.7, task 9, 
  525. terminate alternative 9.7.1, timed entry call 9.7.3
  526.  
  527. 13.6  Change of Representation
  528.  
  529. At most one representation clause is allowed for a given type and a given 
  530. aspect of its representation. Hence, if an alternative representation is 
  531. needed, it is necessary to declare a second type, derived from the first, 
  532. and to specify a different representation for the second type.
  533.  
  534. Example:
  535.  
  536.   -- PACKED_DESCRIPTOR and DESCRIPTOR are two different types
  537.   -- with identical characteristics, apart from their representation
  538.  
  539.   type DESCRIPTOR is
  540.       record
  541.         -- components of a descriptor
  542.       end record;
  543.  
  544.   type PACKED_DESCRIPTOR is new DESCRIPTOR;
  545.  
  546.   for PACKED_DESCRIPTOR use
  547.       record
  548.         -- component clauses for some or for all components
  549.       end record;
  550.  
  551. Change of representation can now be accomplished by assignment with explicit 
  552. type conversions:
  553.  
  554.       D : DESCRIPTOR;
  555.       P : PACKED_DESCRIPTOR;
  556.  
  557.       P := PACKED_DESCRIPTOR (D); -- pack D
  558.       D := DESCRIPTOR(P);         -- unpack P
  559.  
  560. References: assignment 5.2, derived type 3.4, type 3.3, type conversion 
  561. 4.6, type declaration 3.1, representation clause 13.1
  562.  
  563. 13.7 The Package System
  564.  
  565. For each implementation there is a predefined library package called SYSTEM
  566. which includes the definitions of certain configuration-dependent 
  567. characteristics.  The specification of the package SYSTEM is 
  568. implementation-dependent and must be given in Appendix F.  The visible part 
  569. of this package must contain at least the following declarations.
  570.  
  571.  
  572. package SYSTEM is 
  573.       type ADDRESS  is implementation_defined;
  574.       type NAME     is implementation_defined_enumeration_type;
  575.  
  576.       SYSTEM_NAME    : constant NAME  := implementation_defined;
  577.  
  578.       STORAGE_UNIT   : constant := implementation_defined;
  579.       MEMORY_SIZE    : constant := implementation_defined;
  580.  
  581.       --System-Dependent Named Numbers:
  582.  
  583.       MIN_INT        : constant := implementation_defined;
  584.       MAX_INT        : constant := implementation_defined;
  585.       MAX_DIGITS     : constant := implementation_defined;
  586.       MAX_MANTISSA   : constant := implementation_defined;
  587.       FINE_DELTA     : constant := implementation_defined;
  588.       TICK           : constant := implementation_defined;
  589.  
  590.       --Other System_Dependent Declarations
  591.  
  592.       subtype PRIORITY is INTEGER range implementation_defined;
  593.  
  594.       ...
  595.   end SYSTEM;
  596.  
  597. The type ADDRESS is the type of the addresses provided in address clauses; 
  598. it is also the type of the result delivered by the attribute ADDRESS. 
  599. Values of the enumeration type NAME are the names of alternative machine 
  600. configurations handled by the implementation; one of these is the constant 
  601. SYSTEM_NAME.  The named number STORAGE_UNIT is the number of bits per 
  602. storage unit; the named number MEMORY_SIZE is the number of available 
  603. storage units in the configuration; these named numbers are of the type 
  604. universal_integer. 
  605.  
  606. An alternative form of the package SYSTEM, with given values for any of 
  607. SYSTEM_NAME, STORAGE_UNIT, and MEMORY_SIZE, can be obtained by means of the 
  608. corresponding pragmas.  These pragmas are only allowed at the start of a 
  609. compilation, before the first compilation unit (if any) of the compilation.
  610.  
  611.       pragma SYSTEM_NAME (enumeration_literal);
  612.  
  613. The effect of the above pragma is to use the enumeration literal with the 
  614. specified identifier for the definition of the constant SYSTEM_NAME. This
  615. pragma is only allowed if the specified identifier corresponds to one of 
  616. the literals of the type NAME.
  617.  
  618.       pragma STORAGE_UNIT (numeric_literal);
  619.  
  620. The effect of the above pragma is to use the value of the specified numeric 
  621. literal for the definition of the named number STORAGE_UNIT.
  622.  
  623.       pragma MEMORY_SIZE (numeric_literal);
  624.  
  625. The effect of the above pragma is to use the value of the specified numeric 
  626. literal for the definition of the named number MEMORY_SIZE.   
  627.  
  628. The compilation of any of these pragmas causes an implicit recompilation of 
  629. the package SYSTEM.  Consequently any compilation unit that names SYSTEM in 
  630. its context clause becomes obsolete after this implicit recompilation. An 
  631. implementation may impose further limitations on the use of these pragmas. 
  632. For example, an implementation may allow them only at the start of the 
  633. first compilation, when creating a new program library.
  634.  
  635. Note: 
  636.  
  637. It is a consequence of the visibility rules that a declaration given in the 
  638. package SYSTEM is not visible in a compilation unit unless this package is 
  639. mentioned by a with clause that applies (directly or indirectly) to the 
  640. compilation unit.
  641.  
  642. References: address clause 13.5, apply 10.1.1, attribute 4.1.4, compilation 
  643. unit 10.1, must 1.6, named number 3.2, number declaration 3.2.2, numeric 
  644. literal 2.4, package 7, package specification 7.1, pragma 2.8, program 
  645. library 10.1, type 3.3, visibility 8.3, visible part 7.2, with clause 
  646. 10.1.1
  647.  
  648. 13.7.1 System-dependent Named Numbers
  649.  
  650. Within the package SYSTEM, the following named numbers are declared.  The 
  651. numbers FINE_DELTA and TICK are of the type universal_real; the others are 
  652. of the type universal_integer.
  653.  
  654. MIN_INT      The smallest (most negative) value of all predefined integer 
  655.              types.
  656.  
  657. MAX_INT      The largest (most positive) value of all predefined integer 
  658.              types.
  659.  
  660. MAX_DIGITS   The largest value allowed for the number of significant 
  661.              decimal digits in a floating point constraint.
  662.  
  663. MAX_MANTISSA The largest possible number of binary digits in the mantissa 
  664.              of model numbers of a fixed point subtype.
  665.  
  666. FINE_DELTA   The smallest delta allowed in a fixed point constraint that 
  667.              has the range constraint -1.0 .. 1.0.
  668.  
  669. TICK         The basic clock period, in seconds.
  670.  
  671. References: allow 1.6, delta of a fixed point constraint 3.5.9, fixed point 
  672. constraint 3.5.9, floating point constraint 3.5.7, integer type 3.5.4, 
  673. model number 3.5.6, named number 3.2, package 7, range constraint 3.5, 
  674. system package 13.7, type 3.3, universal_integer type 3.5.4, universal_real 
  675. type 3.5.6   
  676.  
  677. 13.7.2 Representation Attributes
  678.  
  679. The values of certain implementation-dependent characteristics can be 
  680. obtatined by interrogating appropriate representation attributes.  These 
  681. attributes are described below.
  682.  
  683. For any object, program unit, label, or entry X:
  684.  
  685. X'ADDRESS      Yields the address of the first of the storage units 
  686.                allocated to X.  For a subprogram, package, task unit or 
  687.                label, this value refers to the machine code associated with 
  688.                the corresponding body or statement.  For an entry for which 
  689.                an address clause has been given, the value refers to the 
  690.                corresponding hardware interrupt. The value of this 
  691.                attribute is of the type ADDRESS defined in the package 
  692.                SYSTEM.
  693.  
  694. For any type or subtype X or for any object X:
  695.  
  696. X'SIZE         Applied to an object, yields the number of bits allocated to 
  697.                hold the object.  Applied to a type or subtype, yields the 
  698.                minimum number of bits that is needed by the implementation 
  699.                to hold any possible object of this type or subtype. The 
  700.                value of this attribute is of the type universal_integer. 
  701.  
  702. For the above two representation attributes, if the prefix is the name of a 
  703. function, the attribute is understood to be an attribute of the function 
  704. (not of the result of calling the function).  Similarly, if the type of the 
  705. prefix is an access type, the attribute is understood to be an attribute of 
  706. the prefix (not of the designated object: attributes of the latter can be 
  707. written with a prefix ending with the reserved word all).
  708.  
  709. For any component C of a record object R:
  710.  
  711. R.C'POSITION   Yields the offset, from the start of the first storage unit 
  712.                occupied by the record, of the first of the storage units 
  713.                occupied by C.  This offset is measured in storage units.  
  714.                The value of this attribute is of the type 
  715.                universal_integer.
  716.  
  717. R.C'FIRST_BIT  Yields the offset, from the start of the first of the 
  718.                storage units occupied by C, of the last bit occupied by C.  
  719.                This offset is measured in bits.  The value of this 
  720.                attribute is of the type universal_integer.
  721.  
  722. R.C'LAST_BIT   Yields the offset, from the start of the first of the 
  723.                storage units occupied by C, of the last bit occupied by C.  
  724.                This offset is measured in bits. The value of this attribute 
  725.                is of the type universal_integer.
  726.  
  727. For any access type or subtype T: 
  728.  
  729. T'STORAGE_SIZE Yields the total number of storage units reserved for the 
  730.                collection associated with the base type of T.  The value of 
  731.                this attribute is of the type universal_integer.
  732.  
  733. For any task type or task object T:
  734.  
  735. T'STORAGE_SIZE Yields the number of storage units reserved for each 
  736.                activation of a task of the type T or for the activation of 
  737.                the task object T.  The value of this attribute is of the 
  738.                type universal_integer. 
  739.  
  740. Notes: 
  741.  
  742. For a task object X, the attribute X'SIZE gives the number of bits used to 
  743. hold the object X, whereas X'STORAGE_SIZE gives the number of storage units 
  744. allocated for the activation of the task designated by X.  For a formal 
  745. parameter X, if parameter passing is achieved by copy, then the attribute 
  746. X'ADDRESS yields the address of the local copy; if parameter passing is by 
  747. reference, then the address is that of the actual parameter.
  748.  
  749. References: access subtype 3.8, access type 3.8, activation 9.3, actual 
  750. parameter 6.2, address clause 13.5, address predefined type 13.7, attribute 
  751. 4.1.4, base type 3.3, collection 3.8, component 3.3, entry 9.5, formal 
  752. parameter 6.1 6.2, label 5.1, object 3.2, package 7, package body 7.1, 
  753. parameter passing 6.2, program unit 6, record object 3.7, statement 5, 
  754. storage unit 13.7, subprogram 6, subprogram body 6.3, subtype 3.3, system 
  755. predefined package 13.7, task 9, task body 9.1, task object 9.2, task type 
  756. 9.2, task unit 9, type 3.3, universal_integer type 3.5.4
  757.  
  758. 13.7.3 Representation Attributes of Real Types
  759.  
  760. For every real type or subtype T, the following machine-dependent 
  761. attributes are defined, which are not related to the model numbers.  
  762. Programs using these attributes may thereby exploit properties that go 
  763. beyond the minimal properties associated with the numeric type (see section 
  764. 4.5.7 for the rules defining the accuracy of operations with real 
  765. operands). Precautions must therefore be taken when using these machine-
  766. dependent attributes if portability is to be ensured.
  767.  
  768. For both floating point and fixed point types:
  769.  
  770. T'MACHINE_ROUNDS    Yields the value TRUE if every predefined arithmetic 
  771.                     operation on values of the base type of T either returns 
  772.                     an exact result or performs rounding; yields the value 
  773.                     FALSE otherwise.  The value of this attribute is of the 
  774.                     predefined type BOOLEAN.
  775.  
  776. T'MACHINE_OVERFLOWS Yields the value TRUE if every predefined operation on 
  777.                     values of the base type of T either provides a correct 
  778.                     result, or raises the exception NUMERIC_ERROR in 
  779.                     overflow situations (see 4.5.7); yields the value FALSE 
  780.                     otherwise. The value of this attribute is of the 
  781.                     predefined type BOOLEAN.
  782.  
  783. For floating point types, the following attributes provide characteristics 
  784. of the underlying machine representation, in terms of the canonical form 
  785. defined in section 3.5.7:
  786.  
  787. T'MACHINE_RADIX     Yields the value of the radix used by the machine 
  788.                     representation of the base type of T (the digits are 
  789.                     extended digits in the range 0 to T'MACHINE_RADIX -1). 
  790.                     The value of this attribute is of the type 
  791.                     universal_integer.
  792.  
  793. T'MACHINE_EMAX      Yields the largest value of exponent for the machine 
  794.                     representation of the base type of T.  The value of 
  795.                     this attribute is of the type universal_integer.
  796.  
  797. T'MACHINE_EMIN      Yields the smallest (most negative) value of exponent 
  798.                     for the machine representation of the base type of T.  
  799.                     The value of this attribute is of the type 
  800.                     universal_integer.   
  801.  
  802. Note: For many machines the largest machine representable number of type F 
  803. is almost 
  804.       (F'MACHINE_RADIX)**(F'MACHINE_EMAX),
  805.  
  806. and the smallest positive representable number is 
  807.  
  808.       F'MACHINE_RADIX ** (F'MACHINE_EMIN -1)
  809.  
  810. References:arithmetic operator 4.5, attribute 4.1.4, base type 3.3, boolean 
  811. predefined type 3.5.3, false boolean value 3.5.3, fixed point type 3.5.9, 
  812. floating point type 3.5.7, model number 3.5.6, numeric type 3.5, 
  813. numeric_error exception 11.1, predefined operation 3.3.3, radix 3.5.7, real 
  814. type 3.5.6, subtype 3.3, true boolean value 3.5.3,  type 3.3, 
  815. universal_integer type 3.5.4
  816.  
  817. 13.8 Machine Code Insertions
  818.  
  819. A machine code insertion can be achieved by a call to a procedure whose 
  820. sequence of statements contains code statements.
  821.  
  822.       code_statement ::= type_mark'record_aggregate;
  823.  
  824. A code statement is only allowed in the sequence of statements of a 
  825. procedure body.  If a procedure body contains code statements, then within 
  826. this procedure body the only allowed form of statement is a code statement 
  827. (labeled or not), the only allowed declarative items are use clauses, and 
  828. no exception handler is allowed (comments and pragmas are allowed as 
  829. usual).  
  830.  
  831. Each machine instruction appears as a record aggregate of a record type 
  832. that defines the corresponding instruction.  The base type of the type mark 
  833. of a code statement must be declared within the predefined library package 
  834. called MACHINE_CODE; this package must be named by a with clause that 
  835. applies to the compilation unit in which the code statement occurs.  An
  836. implementation is not required to provide such a package.
  837.  
  838. An implementation is allowed to impose further restrictions on the record 
  839. aggregates allowed in code statements.  For example, it may require that 
  840. expressions contained in such aggregates be static expressions.  
  841.  
  842. An implementation may provide machine-dependent pragmas specifying register 
  843. conventions and calling conventions.  Such pragmas must be documented in 
  844. Appendix F
  845.  
  846. Example:
  847.  
  848.       M : MASK
  849.       procedure SET_MASK; pragma INLINE(SET_MASK);
  850.  
  851.       procedure SET_MASK is 
  852.         use MACHINE_CODE;
  853.       begin
  854.         SI_FORMAT'(CODE => SSM, B => M'BASE_REG, D => M'DISP);
  855.         --  M'BASE_REG and M'DISP are implementation-specific predefined 
  856.             attributes
  857.       end;  
  858.  
  859. References: allow 1.6, apply 10.1.1, comment 2.7, compilation unit 10.1, 
  860. declarative item 3.9, exception handler 11.2, inline pragma 6.3.2, labeled 
  861. statement 5.1, library unit 10.1, package 7, pragma 2.8, procedure 6 6.1, 
  862. procedure body 6.3, record aggregate 4.3.1, record type 3.7, sequence of 
  863. statements 5.1, statement 5, static expression 4.9, use clause 5.4, with 
  864. clause 10.1.1
  865.  
  866. 13.9 Interface to Other Languages
  867.  
  868. A subprogram written in another language can be called from an Ada program 
  869. provided that all communication is achieved via parameters and function 
  870. results. A pragma of the form
  871.  
  872.       pragma INTERFACE (language_name, subprogram_name);
  873.  
  874. must be given for each such subprogram; a subprogram name is allowed to 
  875. stand for several overloaded subprograms.  This pragma is allowed at the 
  876. place of a declarative item, and must apply in this case to a subprogram 
  877. declared by an earlier declarative item of the same declarative part or 
  878. package specification.  The pragma is also allowed for a library unit; in 
  879. this case the pragma must appear after the subprogram declaration, and 
  880. before any subsequent compilation unit.  The pragma specifies the other 
  881. language (and therby the calling conventions ) and informs the compiler 
  882. that an object module will be supplied for the corresponding subprogram.  A 
  883. body is not allowed for such a subprogram (not even in the form of a body 
  884. stub) since the instructions of the subprogram are written in another 
  885. language.  
  886.  
  887. This capability need not be provided by all implementations.  An 
  888. implementation may place restrictions on the allowable forms and places of 
  889. parameters and calls.
  890.  
  891. Example:
  892.  
  893.       package FORT_LIB is 
  894.         function SQRT (X : FLOAT) return FLOAT;
  895.         function EXP  (X : FLOAT) return FLOAT;
  896.       private 
  897.         pragma INTERFACE(FORTRAN, SQRT);
  898.         pragma INTERFACE(FORTRAN, EXP);
  899.       end FORT_LIB;
  900.  
  901. Notes:
  902.  
  903. The conventions used by other language processors that call Ada programs 
  904. are not part of the Ada language definition.  Such conventions must be 
  905. defined by these other language processors. 
  906.  
  907. The pragma INTERFACE is not defined for generic subprograms.
  908.  
  909. References: allow 1.6, body stub 10.2, compilation unit 10.1, declaration 
  910. 3.1, declarative item 3.9, declarative part 3.9, function result 6.5, 
  911. library unit 10.1, must 1.6, name 4.1, overloaded subprogram 6.6, package 
  912. specification 7.1, parameter of a subprogram 6.2, pragma 2.8, subprogram 6, 
  913. subprogram body 6.3, subprogram call 6.4, subprogram declaration 6.1
  914.  
  915. 13.10 Unchecked Programming
  916.  
  917. The predefined generic library subprograms UNCHECKED_DEALLOCATION and 
  918. UNCHECKED_CONVERSION are used for unchecked storage deallocation and for 
  919. unchecked type conversions.
  920.  
  921.       generic
  922.          type OBJECT is limited private;
  923.          type NAME   is access  OBJECT;
  924.       procedure UNCHECKED_DEALLOCATION(X: in out NAME);
  925.  
  926.       generic
  927.          type SOURCE is limited private;
  928.          type TARGET is limited private;
  929.       function UNCHECKED_CONVERSION(S : SOURCE) return TARGET;
  930.  
  931. References: generic subprogram 12.1, library unit 10.1, type 3.3
  932.  
  933. 13.10.1 Unchecked Storage Deallocation
  934.  
  935. Unchecked storage deallocation of an object designated by a value of an 
  936. access type is achieved by a call of a procedure that is obtained by 
  937. instantiation of the generic procedure UNCHECKED_DEALLOCATION.  For 
  938. example:
  939.  
  940.       procedure FREE is new UNCHECKED_DEALLOCATION(object_type_name,
  941.              access_type_name);
  942.  
  943. Such a FREE procedure has the following effect:
  944.  
  945. (a)  after executing FREE(X), the value of X is null;
  946.  
  947. (b) FREE(X), when X is already equal to null, has no effect;
  948.  
  949. (c) FREE(X), when X is not equal to null, is an indication that the object 
  950.     designated by X is no longer required, and that the storage it occupies 
  951.     is to be reclaimed.
  952.  
  953. If X and Y designate the same object, then accessing this object through Y 
  954. is erroneous if this access is performed (or attempted) after the call 
  955. FREE(X); the efeect of each such access is not defined by the language.
  956.  
  957. Notes:
  958.  
  959. It is a consequence of the visibility rules that the generic procedure 
  960. UNCHECKED_DEALLOCATION is not visible in a compilation unit unless this 
  961. generic procedure is mentioned by a with clause that applies to the 
  962. compilation unit.
  963.  
  964. If X designates a task object, the call FREE(X); has no effect on the task 
  965. designated by the value of this task object.  The same holds for any 
  966. subcomponent of the object designated by X, if this subcomponent is a task 
  967. object.
  968.  
  969. References: access type 3.8, apply 10.1.1, compilation unit 10.1, designate 
  970. 3.8 9.1, erroneous 1.6, generic instantiation 12.3, generic procedure 12.1, 
  971. generic unit 12, library unit 10.1, null access value 3.8, object 3.2, 
  972. procedure 6, procedure call 6.4, subcomponent 3.3, task 9, task object 9.2,
  973. visibility 8.3, with clause 10.1.1
  974.  
  975. 13.10.2 Unchecked Type Conversions
  976.  
  977. An unchecked type conversion can be achieved by a call of a function that 
  978. is obtained by instantiation of the generic function UNCHECKED_CONVERSION.
  979.  
  980. The effect of an unchecked conversion is to return the (uninterpreted) 
  981. parameter value as a value of the target type, that is, the bit pattern 
  982. defining the source value is returned unchanged as the bit pattern defining 
  983. a value of the target type.  An implementation may place restrictions on 
  984. unchecked conversions, for example, restrictions dependeing on the 
  985. respective sizes of objects of the source and target type. Such 
  986. restrictions must be documented in appendix F.
  987.  
  988. Whenever unchecked conversions are used, it is the programmer's 
  989. responsibility to ensure that these conversions maintain the properties 
  990. that are guaranteed by the language for objects of the target type.  
  991. Programs that violate these properties by means of unchecked conversions 
  992. are erroneous.
  993.  
  994. Note:
  995.  
  996. It is a consequence of the visibility rules that the generic function 
  997. UNCHECKED_CONVERSION is not visible in a compilation unit unless this 
  998. generic function is mentioned by a with clause that applies to the 
  999. compilation unit. 
  1000.  
  1001. References: apply 10.1.1, compilation unit 10.1, erroneous 1.6, generic 
  1002. function 12.1, instantiation 12.3, parameter of a subprogram 6.2, type 3.3, 
  1003. with clause 10.1.1
  1004.  
  1005.  
  1006.  
  1007.