VHDL Issue Number: 0014 Classification: Language Definition Problem Language Version: VHDL-87 Summary: Can overloaded entities be individually attributed? Related Issues: 0012, 0017 Relevant LRM Sections: 2.3, 4.4, 5.1, 6.6, 10.3, 10.5 Key Words and Phrases: User-defined attributes, attribute names, overloading, subprograms Current Status: Analyzed 1076-1993 Disposition: Closed Disposition Rationale: Issue addressed in 93 LRM Superseded By: N/A ----------------------- Date Submitted: 1989/02/07 Author of Submission: Paul Menchini Author's Affiliation: CAD Language Systems, Inc. Author's Post Address: P.O. Box 13036 Research Triangle Park, NC 27709-3036 Author's Phone Number: (919) 361-1913 Author's Fax Number: Author's Net Address: mench@clsi.com ----------------------- Date Analyzed: 1991/01/17 Author of Analysis: Paul Menchini (mench@clsi.com) Revision Number: $Revision: 1.9 $ Date Last Revised: $Date: 1995/08/02 23:33:25 $ Description of Problem ---------------------- The LRM is unclear on the semantics of associating user-defined attributes with overloaded entities. This issue effects explicitly and implicitly declared subprograms, enumeration literals, and operators. I will illustrate the issue by using explicitly declared subprograms; the ramifications of this issue are identical for enumeration literals and implicitly declared subprograms. There is one additional ramification in the case of operators; this ramification is covered in issue number 0017. By way of illustration, consider the following examples: -- Example 1: function F return Integer; function F return Real; attribute User_Defined: Boolean; attribute User_Defined of F: function is True; Is this VHDL fragment legal? If it is, which F is attributed? Or are both Fs attributed? It seems clear that both Fs are attributed, but how then is the name "F'User_Defined" interpreted? Another part of the problem is illustrated by the next example: -- Example 2: function F return Integer; attribute User_Defined: Boolean; attribute User_Defined of F: function is True; function F return Real; Is this VHDL fragment legal? If it is, which F is attributed? Or are both Fs attributed? It is not clear that both Fs are attributed; if both Fs are not in fact attributed, how is the name "F'User_Defined" to be interpreted? Proposed Resolution ------------------- Consider the semantics of both examples if the line "attribute User_Defined of F: function is True;" in each were to be replaced with "attribute User_Defined of all: function is True;". It is clear that in Example 1 both functions are attributed; moreover, Example 2 clearly contains an error, since no declarations of a given entity class may follow an attribute specification containing the entity name list _all_ or _others_ for that entity class. If the entity name list for a given entity class contains an entity designator denoting an overloadable entity, consider the attribute specification containing the designator as attributing all entities having that designator as their simple name in the current declarative region. Moreover, no other entity having that entity designator may be subsequently declared in the current declarative region. VASG-ISAC Analysis & Rationale ------------------------------ The ISAC considered three short-term options: 1. State that the language does not define what happens when an attribute specification refers to an overloadable entity, whether or not it is in fact overloaded at the point of the specification. 2. Disallow all attribution of overloaded entities. If an overloadable entity is not overloaded at the point of the specification, the entity would be attributed. No declarations of other entities that are either homographs of the attributed entity or that have the same parameter and result type profile as the attribute entity would be subsequently allowed in the current declarative part. 3. Allow attribution of overloadable entities. The attribute specification would apply to all entities that match the specification in the current declarative part. Additional entities with the same simple name would be allowed to be subsequently declared in the same declarative part; however, the attribute specification would not apply to these new entities. (Of course, additional attribute specifications could be supplied.) The approach is to define a spectrum of attribute specifications that vary in their constraints. The constraints are threefold: (a) whether or not the specification applies to more than one entity, (b) whether or not any previous attribution is permitted, and (c) whether or not more entities with the same name may be declared subsequent to the specification. This spectrum may be illustrated as follows: Attribute overloadable non-over- Spec type: all others name loadable name constraint (a): yes yes yes no constraint (b): no yes yes no constraint (c): no no yes no If approach 3 is adopted, another issue is whether or not an attribute of an overloaded entity may be read from within a VHDL description. The difficulty arises because some entities denoted by a prefix may be attributed and others may not. Moreover, the value of the attribute needn't be the same for each instance. Therefore, a complex set of rules disambiguating the prefix may be needed if the attributes are to be read with VHDL. No consensus has currently been reached on the appropriate short-term approach. The ISAC also considered some additional long-term approaches: 1. Add syntax to attribute specifications and attribute names that allow disambiguation by parameter and result type profile. 2. If this were done, then a decision on whether to allow or disallow ambiguous cases must be made. VASG-ISAC Recommendation for IEEE Std 1076-1987 ----------------------------------------------- TBD VASG-ISAC Recommendation for Future Revisions --------------------------------------------- TBD