It would be good if you all could review this before tonight's meeting. I have tried to capture the intent of the LRM change, but I haven't been able to come up with proper wording yet. Chuck Swart -------------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: 07 September 2006 Author of Analysis: Chuck Swart Revision Number: 1 Date Last Revised: 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 non-object 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 non-object 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 mean 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: type my_logic is ( '0', '1', 'X', 'Z'); alias alt_logic is my_logic; case 2: alias std_logic1 is ieee.std_logic_1164.std_logic; alias std_logic2 is ieee.std_logic_1164.std_logic; case 3: type my_logic is ( '0', '1', 'X', 'Z'); function "="( a, b: my_logic) return boolean; alias alt_logic is my_logic; case 4: type my_logic is ( '0', '1', 'X', 'Z'); alias alt_logic is my_logic; function "="( a, b: my_logic) return boolean; case 5: package p1 is function "=" (a,b: ieee.std_logic_1164.std_logic ) return boolean; ... end package p1; use work.p1.all; ... alias std_logic is ieee.std_logic_1164.std_logic; The reason for the implicit declarations is so that if you alias a type you also get automatic access to the associated operators. It is reasonable that if these operators are already visible, then the implicit declarations are unnecessary and problematic. The LRM wording should reflect this principle. For case 1, since the predefined operators are already visible there is no need for the implicit declarations for the alias. For case 2, since the alias of std_logic1 makes the implicit operators visible, there is no need for the implicit declarations for the second alias, std_logic2. Another general principle is that implicit operators can be overloaded by explicit operators. This principle should also apply to implicit declarations associated with aliases. For case 3, since an overloaded "=" operator already is visible, there is no need for an implicit declaration of the "=" operator associated with the alias alt_logic. For case 4, it should be legal to overload the implicitly declared "=" operator associated with the alias alt_logic. A final applicable principle is that visibility via USE clauses is subordinate to other declarations. For case 5, the "=" operator in the package should not be visible following the alias declaration. The new wording of the LRM must reflect these three principles. I can come up with wording that captures the first two, but I don't immediately see how to get wording that supports the third principle and case 5. VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- TBD VASG-ISAC Recommendation for Future Revisions --------------------------------------------- TBD -------------END OF IR----------------Received on Thu Sep 7 12:48:43 2006
This archive was generated by hypermail 2.1.8 : Thu Sep 07 2006 - 12:48:45 PDT