-------- Original Message -------- Subject: Re: Review this analysis Date: Thu, 07 Sep 2006 13:50:04 -0700 From: John Ries <johnr@model.com> To: Chuck Swart <cswart@model.com> References: <45007717.5000208@model.com> Hi Chuck, I agree with this in principle. I do have some comments. In Case 4, I think that the code is legal because of Case 1. In Case 1, the alias to the implicit operator "=" doesn't occur because the implicit operator "=" is already "visible". So the function "=" definition is only between the implicit function declaration of the type and itself. Since this is already legal, then Case 4 should be legal. The more interesting case is CASE 6: package p1 is type my_logic is ( '0', '1', 'X', 'Z'); end package use p1.all; package p2 is alias alt_logic is my_logic; function "="( a, b: my_logic) return boolean; end package. In this case the implicit alias to "="[my_logic, my_logic, return boolean] does occur so now we have two confliciting 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 use p1.all; package p2 is alias alt_logic is my_logic; end package; use p1.all; use p2.all; package p4 is constant C : atl_logic := 'X'; end package; 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 visiblity 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 use p1.all; package p2 is alias alt_logic is my_logic; end package; use p1.all; package p3 is alias other_logic is my_logic; end package; use p3.all; use p2.all; package p4 is constant C : atl_logic := 'X'; end package; I believe case 8 is illegal with both VHDL-200X and VHDL-2002 visiblity rules. Regards, John Chuck Swart wrote: > John, > would you please look this over and give me any comments you might have. > > Chuck > > > ------------------------------------------------------------------------ > > -------------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---------------- -- -- mailto: johnr@model.com phone: (503)685-0864 -- http://www.model.com fax: (503)685-0921 --Received on Thu Sep 7 20:14:27 2006
This archive was generated by hypermail 2.1.8 : Thu Sep 07 2006 - 20:14:28 PDT