VHDL Issue Number: 1094 Classification: Language Definition Problem Language Version: VHDL-93 Summary: Bad wording for individual association for subprograms. Related Issues: Relevant LRM Sections: 1.1.1, 2.1.1, 3.2.1.1, 4.3.2.2, 7.3, 8.4 Key Words and Phrases: independent subelement association, individual association, Current Status: Submitted 1076-1993 Disposition: N/A Disposition Rationale: N/A Superseded By: N/A ----------------------- Date Submitted: 1994/08/19 Author of Submission: Daniel S. Barclay Author's Affiliation: COMPASS Design Automation, Inc. Author's Post Address: 5457 Twin Knolls Rd. Suite 100 Columbia, MD 21045 USA Author's Phone Number: 410-992-5700 Author's Fax Number: 410-992-3536 Author's Net Address: daniel@compass-da.com ----------------------- Date Analyzed: TBD Author of Analysis: TBD Revision Number: $Revision: 1.7 $ Date Last Revised: $Date: 1995/05/15 20:07:17 $ Description of Problem ---------------------- The LRM wording does not consistently allow individual association (independent subelement association) for subprogram calls. [LRM quotes are from the almost-final 1994/06/24 version. The notation {\i word} indicates that the word (or words) is italicized; {\b word} indicates that the word (or words) is in boldface type.] In several places, the LRM does seem to allow individual association for subprograms: * Section 4.3.2.2 says: A formal may be either an explicitly declared interface object or a slice or subelement (or slice thereof) of such an interface object. .... In the latter cases, ... the subelements of such a formal are said to be {\i associated individually}. Furthermore, every scalar subelement of the explicitly declared interface object must be associated exactly once with an actual (or subelement thereof) in the same association list ... . Each association element that associates a slice or subelement (or slice thereof) of an interface object must .... The use of "interface object" instead of "port" and "generic" implies that subprogram parameters are included. * Section 3.2.1.1 says * For a formal parameter of a subprogram that is of an unconstrained array type and whose subelements are associated individually (see 4.3.2.2), the index ranges are obtained as follows: Clearly, this new paragraph was written assuming that individual association applies to subprogram calls. Other places in the LRM don't allow for individual association. A few clearly do not reflect the intent; many subtly don't allow for it. * Section 7.3.3 says: For each formal parameter of a function, a function call must specify exactly one corresponding actual parameter. This actual parameter is specified either explicitly, by an association element (other than the actual part {\b open}) in the association list, or in the absence of such an association element, by a default expression (see 4.3.2). Neither sentence allows for individual association. * Section 8.4 is virtually identical: For each formal parameter of a procedure, a procedure call must specify exactly one corresponding actual parameter. This actual parameter is specified either explicitly, by an association element (other than the actual {\b open}) in the association list or, in the absence of such an association element, by a default expression (see 4.3.2). * Section 2.3 says: A call to an overloaded subprogram is ambiguous (and therefore is an error) if the name of the subprogram, the number of parameter associations, the types and order of the actual parameters, the names of the formal parameters (if named associations are used), and the result type (for functions) are not sufficient to identify exactly one (overloaded) subprogram specification. The wording "the number of parameter associations" does not allow for individual association. (It should refer somehow to the number of distinct names of formals appearing in the association elements.) * Section 1.1.1.2 says: To communicate with other blocks, the ports of a block can be associated with signals in the environment in which the block is used. Moreover, the ports of a block may be associated with an expression in order to provide these ports with constant driving values; such ports must be of mode {\b in}. A port is itself a signal (see 4.3.1.2); thus, a formal port of a block may be associated as an actual with a formal port of an inner block. The port, signal, or expression associated with a given formal port is called the {\i actual} corresponding to the formal port (see 4.3.2.2). The actual, if a port or signal, must be denoted by a static name (see 6.1). The actual, if an expression, must be a globally static expression (see 7.4). The first sentence is at least misleading. The wording "the ports of a block can be associated with signals" can be read as "for the ports of a block, each port can be associated with a signal", and that "_a_ signal" does not allow for individual association. If only whole declared ports can have expressions associated with them, then the second sentence is fine. (If expressions can be associated with individual association, the second sentence needs work.) The third sentence is similar to the first. (Though at the moment I don't know how to avoid implying a restriction without cluttering up the wording a lot.) The fourth sentence does not allow for individual association. The term "formal port" is not formally defined, but it is effectively defined by the sentence Each interface element in the port interface list declares a formal port. in section 1.1.1.2. Therefore, the wording "_the_ port, signal, or expression asscoiated with a given formal port" does not cover individual association. (Also, the term "actual" should not be defined one way here and used differently in section 4.3.2.2 and in section 5.2.1.2 .) The remaining sentences appear to be fine. * Section 1.1.1.1 says: The value of a generic constant may be specified by the corresponding actual in a generic association list. If no such actual is specified for a given formal generic (either because the formal generic is unassociated or because the actual is {\b open}), and if a default expression is specified for that generic, the value of this expression is the value of the generic. It is an error if no actual is specified for a given formal generic and no default expression is present in the corresponding interface element. It is an error if some of the subelements of a composite formal generic are connected and others are either unconnected or unassociated. The paragraph has similar problems to those of the paragraph from section 1.1.1.2. In the first sentence, the wording "the corresponding actual" does not seem to allow for individual association. The second sentence is fine, since "open" cannot be associated individually. (Sectino 4.3.2.2 says "It is an error if an actual of {\b open} is associated with a formal that is associated individually.") The third sentence appears to be fine. (The last sentence has different problem: The term "connected" is defined for ports but it not defined for generic constants. The LRM should only use terms as they are defined to apply.) * Section 2.1.1 says: In a subprogram call, the actual designator (see 4.3.2.2) associated with a formal parameter of class {\b signal} must be a signal. The actual designator associated with a formal of class {\b variable} must be a variable. The actual designator associated with a formal of class {\b constant} must be an expression. The actual designator associated with a formal of class {\b file} must be a file. All four sentences neglect to allow for individual association. (The pattern could be "Each actual designator associated with a formal parameter_,_or_ member_thereof,_ of class {\b signal} must _denote_ a signal. Unless "actual designator" can refer to the implicitly-associated value of a constant parameters, the third sentence does not allow for unassociated constant parameters. * Section 2.1.1.1 says: For parameters of class {\b constant} or {\b variable}, only the values of the actual or formal are transferred into or out of the subprogram call. The manner of such transfers, and the accompanying access privileges that are granted for constant and variable parameters, are described in this subclause. The wording "the actual" may be misleading or wrong. * Section 2.1.1.1 says: For a nonforeign subprogram having a parameter whose type is an array or record, an implementation may pass parameter values by copy, as for scalar types. If a parameter of mode {\b out} is passed by copy, then the range of each index position of the actual parameter is copied in, and likewise for its subelements or slices. Alternatively, an implementation may achieve these effects by reference; that is, by arranging that every use of the formal parameter (to read or update its value) be treated as a use of the associated actual parameter throughout the execution of the subprogram call. ... The first sentence implicitly neglects individual association, because it refers to the preceding paragraph which refers to "the actual parameter" (which was correct for scalar and access types in the preceding pargraph). The second and third sentence both refer to "the actual parameter", not allowing for individual association. * Section 2.1.1.1 also says: For a formal parameter of a constrained array subtype of mode {\b in} or {\b inout}, it is an error if the value of the associated actual parameter (after application of any conversion function or type conversion present in the actual part) does not contain a matching element for each element of the formal. For a formal parameter whose declaration contains a subtype indication denoting an unconstrained array type, the subtype of the formal in any call to the subprogram is taken from the actual associated with that formal in the call to the subprogram. It is also an error if, in either case, the value of each element of the actual array (after applying any conversion function or type conversion present in the actual part) does not belong to the element subtype of the formal. If the formal parameter is of mode {\b out} or {\b inout}, it is also an error if, at the end of the subprogram call, the value of each element of the formal (after applying any conversion function or type conversion present in the formal part) does not belong to the element subtype of the actual. The first and second sentence refers the "the associated actual parameter"; this does not allow for individual association. (And the second sentence therefore seems to contradict the descriptions in section 3.2.1.1.) The third sentence refers to "the actual array". It is not clear whether this wording is a problem. The fourth sentence refers to "the formal" and "the actual"; this is a problem if "formal" refers to the (whole) explicitly declared interface object. * Section 2.1.1.1 also says: 1- For parameters of array and record types, the parameter passing rules imply that if no actual parameter of such a type is accessible by more than one path, then the effect of a subprogram call is the same whether or not the implementation uses copying for parameter passing. If, however, there are multiple access paths to such a parameter (for example, if another formal parameter is associated with the same actual parameter), then the value of the formal is undefined after updating the actual other than by updating the formal. A description using such an undefined value is erroneous. 2- As a consequence of the parameter passing conventions for variables, if a procedure is called with a shared variable (see 4.3.1.3) as an actual to a formal variable parameter of modes {\b inout} or {\b out}, the shared variable may not be updated until the procedure completes its execution. Furthermore, a formal variable parameter with modes {\b in} or {\b inout} may not reflect updates made to a shared variable associated with it as an actual during the execution of the subprogram, including updates made to the actual during the execution of a wait statement within a procedure. It is not clear whether the references here are a problem. * Section 2.1.1.2 appears to neglect individual association in its references to actual and formal signal parameters. * (Section 2.1.1.3 is not a problem since individual association is not possible for files.) * Section 4.3.2.2 begins with: Each association element in an association list associates one actual designator with the corresponding interface element in the interface list of a subprogram declaration, component declaration, entity declaration, or block statement. The corresponding interface element is determined either by position or by name. Is there any problem with saying "interface element" instead of "interface object" (and then adding "or member thereof")? Also, the meaning of "actual" and "formal" defined for section 4.3.2.2 may not be followed consistently elsewhere (referring to the actual and formal designators, not to denoted interface objects or actual objects or expression. * Section 4.3.2.2 says: The formal part of a named element association may be in the form of a function call, where the single argument of the function is the formal designator itself, if and only if the mode of the formal is {\b out}, {\b inout}, {\b buffer}, or {\b linkage}, and if the actual is not {\b open}. Given that "formal" means "formal designator", what is the mode of the formal designator? The formal designator may be a name that denotes a interface object. The interface object has a mode, the formal designator does not. If the formal designator denotes only a member of an interface object, then is the mode of a member of an interface object defined? Proposed Resolution ------------------- Make the wording accurate, consistent, and clear: * Allow for individual association. Probably use phrases such as "the set of actuals for a (whole) formal", "formal parameter or member thereof", etc., or define appropriate terms to avoid cluttering up the wording. * Don't have different definitions of "actual" in different sections. * Given that "formal port" is referred to all over the LRM, define it. Make it clear whether a member of a formal port is a formal port. If it is not, adjust wording appropriately. Similarly review parameters and generic constants. Check all references to "actual", "formal", association elements, etc. for additional occurrences of these problems. VASG-ISAC Analysis & Rationale ------------------------------ TBD VASG-ISAC Recommendation for IEEE Std 1076-1993 ----------------------------------------------- TBD VASG-ISAC Recommendation for Future Revisions --------------------------------------------- TBD