Please review this for Thursday's ISAC meeting. It's been copied to the ISAC website. Chuck Swart -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -------------BEGINNING OF IR---------------- VHDL Issue Number: 2099 Language_Version VHDL-2002 Classification Language Definition Problem Summary Alias declarations introduce homographs Relevant_LRM_Sections 4.3.3.2 Nonobject aliases 10.3 Visibility Related_Issues Key_Words_and_Phrases nonobject aliases, homographs Authors_Name Peter Ashenden Authors_Phone_Number +61 414 709 106 Authors_Fax_Number Authors_Email_Address peter@ashenden.com.au Authors_Affiliation Ashenden Designs Authors_Address1 Authors_Address2 Authors_Address3 Current Status: Analyzed Superseded By: ------------------------ Date Submitted: 14 June 2006 Date Analyzed: 26 September 2006 Author of Analysis: Chuck Swart Revision Number: 5 Date Last Revised: 02 January 2007 Description of Problem ---------------------- This issue was originally raised by John Ries in the Accellera VHDL-TC review of P1076-2006/D2.11 and entered as Bugzilla bug #44: Description: [reply] Opened: 2006-06-07 06:03 On page 114 in nonobject alias it states : c) If the name denotes an enumeration type or a subtype of an enumeration type, then one implicit alias declaration for each of the literals of the base type immediately follows the alias declaration for the enumeration type; each such implicit declaration has, as its alias designator, the simple name or character literal of the literal and has, as its name, a name constructed by taking the name of the alias for the enumeration type or subtype and substituting the simple name or character literal being aliased for the simple name of the type or subtype. Each implicit alias has a signature that matches the parameter and result type profile of the literal being aliased. d) Alternatively, if the name denotes a subtype of a physical type, then one implicit alias declaration for each of the units of the base type immediately follows the alias declaration for the physical type; each such implicit declaration has, as its alias designator, the simple name of the unit and has, as its name, a name constructed by taking the name of the alias for the subtype of the physical type and substituting the simple name of the unit being aliased for the simple name of the subtype. e) Finally, if the name denotes a type or a subtype, then implicit alias declarations for each predefined operator operation for the type immediately follow the explicit alias declaration for the type or subtype and, if present, any implicit alias declarations for literals or units of the type. Each implicit alias has a signature that matches the parameter and result type profile of the implicit operation being aliased. What happens if there is a homograph already declared or aliased? For example type my_logic is ( '0', '1', 'X', 'Z'); function "="( a, b: my_logic) return boolean; alias alt_logic is my_logic; -- the following alias are implicit alias '0' is '0' [ return my_logic]; alias '1' is '1' [ return my_logic]; alias 'X' is 'X' [ return my_logic]; alias 'Z' is 'Z' [ return my_logic]; alias "/=" is "/=" [ my_logic, my_logic, return boolean]; alias "=" is "=" [ my_logic, my_logic, return boolean]; -- note implicit "=" not explicit one. It seams to me that all the alias are homographs. In all cases except the "=" these aliases denote the exact same objects so is this an error?. In the case of "=" these are different functions the alias is to the predefined "=" and there is an explicit "=" already declared. Is this an error? What happens if the explicit "=" is declared after the alias? This also raises the question, after I declare an alias to a type is it legal to define an explicit version of a predefined operator on the aliased type? For example library ieee; package mycompare is alias std_logic is ieee.std_logic_1164.std_logic; -- there is an implicit alias alias "=" is ieee.std_logic_1164."="[ieee.std_logic_1164.std_ulogic, ieee.std_logic_1164.std_ulogic, return ieee.std_logic_1164.std_ulogic]; -- Is this legal?? function "=" ( a, b : std_logic) return boolean; .... Does clause 10.3 statement Two declarations that occur immediately within the same declarative region, other than the declarative region of a block implied by a component instantiation or the declarative region of a generic-mapped package or subprogram equivalent to a package instance or a subprogram instance,28 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. Apply here? ------- Additional Comment #1 From Peter Ashenden 2006-06-11 23:31 [reply] ------- It would appear that the rules for nonobject aliases were written under the assumption that the name being aliased is declared in a different declarative region. The example in the LRM illustrates that, with the name BIT being declared in STD.STANDARD. Aliasing a name declared in the same declarative region introduces the issue you raise. I would say that the rule of 10.3 that you quote covers (serendipitously) the case of the explicit declaration of an operation hiding the implicit declaration introduced by the alias declaration. However, it doesn't address the fact that the implicit declaration introduced by the alias declaration is a homograph of the implicit declaration introduced by the type declaration. This is not a new problem; it was latent in the previous revision of the LRM. It might be best to address this through ISAC. ------- Additional Comment #2 From John Ries 2006-06-13 07:57 [reply] ------- This needs to be resolved because the numeric_std package defines two aliases to types. They are alias U_UNSIGNED is UNRESOLVED_UNSIGNED; and alias U_SIGNED is UNRESOLVED_SIGNED; Since the meaning of this is unclear, the LRM needs to either remove the aliases from the package or define the behavior ------- Additional Comment #3 From Peter Ashenden 2006-06-14 18:31 [reply] ------- In the LRM-SC telecon of 13-Jun-2006, we agreed that issues relating to aspects of VHDL-2002 would continue to be addressed by the IEEE ISAC, and issues relating to changes added for VHDL-2006 would be addressed by the LRM-SC. Since this issue is inherent in VHDL-2002, I'll raise an ISAC IR on it, and mark this bug as resolved/later. That will remind us to revisit it in a subsequent round, possibly by means of an ISAC recommendation. Proposed Resolution ------------------- VASG-ISAC Analysis & Rationale ------------------------------ There are genuine issues in this area. There are several cases which were inadvertently missed in the LRM. Here are some of the cases which need to be covered (using the submitter's examples as a starting point): case 1: package p_test is type my_logic is ( '0', '1', 'X', 'Z'); alias alt_logic is my_logic; end package p_test; case 1b: (From Peter Ashenden) package p_test is type my_logic is ( a, b, c, d); alias alt_logic is my_logic; end package p_test; This is case1 with the enumeration literals changed to avoid clouding the issue with bit and character literals. This declares, among other things: "="[my_logic, my_logic return boolean] and "="[alt_logic, alt_logic return boolean] The question is whether an expression like a = b is now ambiguous. I think the fact that a and b are both of the same type and that both "=" operators have the same profile and denote the same function should mean that the expression is not ambiguous. case 2: package p_test is alias std_logic1 is ieee.std_logic_1164.std_logic; alias std_logic2 is ieee.std_logic_1164.std_logic; end package p_test; case 3: package p_test is type my_logic is ( '0', '1', 'X', 'Z'); function "="( a, b: my_logic) return boolean; alias alt_logic is my_logic; end package p_test; case 4a: package p_test is type my_logic is ( '0', '1', 'X', 'Z'); alias alt_logic is my_logic; function "="( a, b: my_logic) return boolean; end package p_test; case 4b: package p_test is type my_logic is ( '0', '1', 'X', 'Z'); alias alt_logic is my_logic; function "="( a, b: alt_logic) return boolean; end package p_test; case 5: package p1 is function "=" (a,b: ieee.std_logic_1164.std_logic ) return boolean; ... end package p1; package p_test is use work.p1.all; ... alias std_logic is ieee.std_logic_1164.std_logic; end package p_test; CASE 6: package p1 is type my_logic is ( '0', '1', 'X', 'Z'); end package p1; package p2 is use p1.all; alias alt_logic is my_logic; function "="( a, b: my_logic) return boolean; end package p2 [ John Ries: In this case the implicit alias to "="[my_logic, my_logic, return boolean] does occur so now we have two conflicting declarations. I think that case 6 should be legal. It seems to me that the rule should be If an implicit alias is a homograph of an object declared within the same scope, then the implicit alias isn't done or hidden. This rule is suppose to be similar the the implicit/explicit operator declarations. One last thing to consider that isn't in the bugzilla report is] CASE 7: package p1 is type my_logic is ( '0', '1', 'X', 'Z'); end package p1; package p2 is use p1.all; alias alt_logic is my_logic; end package p2; package p4 is use p1.all; use p2.all; constant C : alt_logic := 'X'; end package p4; [John Ries: Is this legal or illegal. With the current visibility rules in VHDL-2002 it should be illegal because Neither the declaration of p1.'X' or p2.'X' is directly visible because they are homographs. In VHDL-200X it may be legal because of the change to visibility to allow for explicit declarations to "hide" implicit declaration when made visible through a use clause (the signed/unsigned package problem)] CASE 8: package p1 is type my_logic is ( '0', '1', 'X', 'Z'); end package p1; package p2 is use p1.all; alias alt_logic is my_logic; end package p2; package p3 is use p1.all; alias other_logic is my_logic; end package p3; package p4 is use p3.all; use p2.all; constant C : alt_logic := 'X'; end package p4; [John Ries: I believe case 8 is illegal with both VHDL-200X and VHDL-2002 visibility rules.] Analysis: Clearly, it is highly desirable that several of the cases be legal. The ISAC considered two possible approaches to resolving this issue. The first approach is to add additional cases to Clause 10.4 to cover various implicit/explicit combinations introduced by implicit aliases. The second is to reword the LRM so that two principles hold: Principle 1: An alias of a declaration is not a homograph of that declaration and, in addition, two alias declarations of the same designator that denote the same named entity are not homographs. The two declarations are viewed as if they were multiple references to the same named entity. So nonobject aliases have more of a flavor of USE clauses than of object declarations. Principle 2: An alias of an implicitly predefined operation is itself considered to be an implicitly predefined operation, so that explicitly declared overloaded operators will take precedence in use clauses. This principle holds whether or not the alias itself is implicitly declared. The second approach appears to be the most intuitive and offers the greatest flexibility to the language user. This interpretation provides the following analysis of the various cases: For case 1, the implicit declarations of aliases of the enumeration values are not homographs of the original declaration. Therefore, case 1 is legal. For case 1b, the case is legal, and the expression a = b is not ambiguous. Since both "=" declarations denote the same function. For case 2, the implicit declarations associated with each alias are not homographs. Therefore, case 2 is legal. Case 3. Principle 2 implies that the explicitly declared "=" function hides the alias of the implicit function "=" associated implicitly with the alias alt_logic This implicit "=" function is a homograph of the explicitly declared "=" function. Case 3 is legal, and the explicitly declared "=" is visible. Case 4a. It is legal to overload the implicitly declared "=" operator associated with the alias alt_logic. Case 4a is legal, and the explicitly declared "=" is visible after its declaration. Case 4b. Since alt_logic is an alias for my_logic, Case 4b is the same as case 4a. Case 5. (D3.0 interpretation) Clause 10.4 Implies that a potentially visible explicit declaration overrides a visible implicit declaration. Therefore, by Principle 2, Case 5 is legal and the overloaded "=" operation from package p1 is visible in package p_test. Case 6. The explicit "=" operation overrides the implicit one from package p1. Case 6 is legal and the explicitly declared "=" from package p2 is visible. Case 7. Each package provides a potentially visible alias of 'X', but since both aliases refer to the same declaration, they are not homographs. Case 7 is legal. Case 8 The implicit aliases in all packages refer to the same declaration of 'X'. Case 8 is legal. VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- The resolution of the various cases is not clear for VHDL-2002, and may conceivably vary between implementations. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Make the following changes to D3.0: Clause 4.5.2 Nonobject aliases Add just before the examples: "Two nonobject alias declarations are said to be "alias-equivalent" if the alias designators are the same and if the denoted names are the same. Similarly, an alias declaration and a subprogram declaration are said to be "alias_equivalent" if the alias designator is the same as the simple name, character literal, or operator symbol of the alias denoted name and if the alias denoted name refers to the same named entity as the subprogram designator (see 10.3,10.4)." Clause 10.3 Visibility Change: "-- The visibility rules determine more than one possible meaning, In such a case, the occurrence of the identifier is legal at this point if and only if exactly one visible declaration is acceptable for the overloading rules in the given context." To: "-- The visibility rules determine more than one possible meaning, In such a case, the occurrence of the identifier is legal at this point if and only if either exactly one visible declaration is acceptable for the overloading rules in the given context or all visible declarations are alias-equivalent." Add to: "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)" ",except that alias-equivalent declarations are not homographs. (Each such declaration is considered to be a reference to the denoted declaration.)" Replace: "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." with "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 or is an alias of such an implicit declaration." Clause 10.4 Use clauses Replace "a) A potentially visible implicit declaration of a predefined operation is not mode directly visible if the place considered is within the scope of an explicitly declared homograph of that implicit declaration." with "a) A potentially visible implicit declaration of a predefined operation or an alias of such a declaration is not made directly visible if the place considered is within the scope of an explicitly declared homograph of that implicit declaration or the alias." -------------END OF IR----------------Received on Tue Jan 2 14:04:09 2007
This archive was generated by hypermail 2.1.8 : Tue Jan 02 2007 - 14:04:11 PST