IEEE 200X Fast Track Change Proposal ID: FT-01 Proposer: Jim Lewis (jim@synthworks.com) Analyzed by: Stephen Bailey (stephen@srbailey.com) and Jim Lewis (jim@synthworks.com) Status: Open Proposed: 1-Jan-2003 Analyzed: Date Resolved: Date Enhancement Summary: Allow explicit subprograms (ie: ">") overload implicit subprograms Related issues: Currently being worked by ISAC Relevant LRM section: 10.4, 10.3, 2.3 (further details below) Rev 2: Updated proposed wording of 10.4 a and b ---------------------- Note ---------------------- The intent of the following is that it applies to implicitly defined subprograms (functions, procedures, and operators). The analysis has been updated to reflect this, the enhancement detail has not. ---------------------- Enhancement Detail: ---------------------- The declaration of std_ulogic, std_logic, std_logic_vector and std_ulogic_vector in package std_logic_1164 results in the implicit declaration of various operators for those types. As part of the 1076.3 (Numeric_std, ...) effort, we would like to create a numeric overloading for std_logic_vector for numeric operators. Unfortunately with the current LRM rules, the overloading for comparison operators would create homographs and the operators would not be directly visible. This leaves 1076.3 with the following three options: 1) Don't overload the comparison operators. This means that if someone naively overloads the comparison operators, they use the implicit operators. If the arguments are different sized or contain a resistive strength value (H,L), then the answer is wrong. Impact: Users get the wrong answer. To me this is the wrong approach. My view of VHDL is, on a bad day, coding in VHDL I will get abused by the compiler. On a bad day driving Verilog, I can embed a bug in the code that I will not find for weeks and I better have a good testbench and lint tool. 2) Overload comparison operators in std_logic_1164. This will require that for comparisons, std_(u)logic_vector gets understood as a numeric and that the value is unsigned. Impact: This will break legacy code that uses std_logic_unsigned. Unless we can get Synopsys to simultaneously remove the comparison operators from Std_Logic_Unsigned, this is not a good solution. 3) Change the LRM to allow explicit operator implementations to always take precedence over implicit operator definitions. Currently vendors do this for the package std_logic_unsigned. This proposal seeks to always have explicitly overloaded operators take precedence over implicitly overloaded operators. ---------------------- Relevant LRM sections: ---------------------- 10.4 "In order to determine which declarations are made directly visible at a given place by use clauses,consider the set of declarations identified by all use clauses whose scopes enclose this place. Any declaration in this set is a potentially visible declaration. A potentially visible declaration is actually made directly visible except in the following two cases: a) A potentially visible declaration is not made directly visible if the place considered is within the immediate scope of a homograph of the declaration. b) Potentially visible declarations that have the same designator are not made directly visible unless each of them is either an enumeration literal speci .cation or the declaration of a subprogram (either by a subprogram declaration or by an implicit declaration)." Homograph is defined in 10.3: "A declaration is said to be hidden within (part of) an inner declarative region if the inner egion contains a homograph of this declaration; the outer declaration is then hidden within the immediate scope of the inner homograph. Each of two declarations is said to be a homograph of the other if both declarations have the same identifier, operator symbol, or character literal, and if overloading is allowed for at most one of the two. If overloading is allowed for both declarations, then each of the two is a homograph of the other if they have the same identifier, operator symbol, or character literal, as well as the same parameter and result type profile (see 3.1.1)." Furthermore, clause 10.3 also states: "Two declarations that occur immediately within the same declarative region must not be homographs, unless exactly one of them is the implicit declaration of a predefined operation. In such cases, a predefined operation is always hidden by the other homograph. Where hidden in this manner, an implicit declaration is hidden within the entire scope of the other declaration (regardless of which declaration occurs first); the implicit declaration is visible neither by selection nor directly." NOTE: This clause states that if the overloading of the operations contained in the related packages were located directly within std_logic_1164, there would be no issue as no homograph would occur. Clause 3 specifies which operations are implicitly defined: "A type is characterized by a set of values and a set of operations. The set of operations of a type includes the explicitly declared subprograms that have a parameter or result of the type. The remaining operations of a type are the basic operations and the predefined operators (see 7.2). These operations are each implicitly declared for a given type declaration immediately after the type declaration and before the next explicit declaration, if any." Clause 2.3 on Subprogram overloading also applies: "Two formal parameter lists are said to have the same parameter type profile if and only if they have the same number of parameters, and if at each parameter position the corresponding parameters have the same base type. Two subprograms are said to have the same parameter and result type profile if and only if both have the same parameter type profile, and if either both are functions with the same result base type or neither of the two is a function." NOTE: The key point here is that the base type determines operator overloading and overload resolution and not the subtype. In the related packages, a subtype of the std_logic_1164 types is defined and the operators are defined in terms of those subtypes. However, they overload the implicit operators from 1164 as they are the same base type. --------- Analysis: --------- Extend the semantics in clause 10.4 to allow a package to overload an implicit operator that results from another package. "In order to determine which declarations are made directly visible at a given place by use clauses, consider the set of declarations identifed by all use clauses whose scopes enclose this place. Any declaration in this set is a potentially visible declaration. A potentially visible declaration is actually made directly visible except in the following three cases: a) A potentially visible implicit declaration of a predefined subprogram is not made directly visible if the place considered is within the scope of an explicitly declared homograph of that implicit declaration. b) A potentially visible explicit declaration is not made directly visible if the place considered is within the immediate scope of an explicitly declared homograph of that declaration. c) Potentially visible declarations that have the same designator are not made directly visible unless each of them is either an enumeration literal specification or the declaration of a subprogram (either by a subprogram declaration or by an implicit declaration). Also, we could add a 3rd note: 3 -- These rules ensure that potentially explicit declarations have visibility priority over implicit declarations that create a homograph of the declaration. ----------------------- Recommendations ----------------------- That this issue be resolved by adoption of the above proposed resolution. This resolution does not have any potential impact on existing VHDL code. Existing code that attempted to use the operator either depended on the non-standard interpretation of the language (which this proposal makes valid) or the operator was not visible and hence the code never compiled. Resolution: [To be performed]