-------------BEGINNING OF IR---------------- VHDL Issue Number: 2100 Language_Version VHDL-2002 Classification Language Definition Problem Summary Operator overloading for protected type methods Relevant_LRM_Sections 2.3.1 Operator overloading Related_Issues Key_Words_and_Phrases operator overloading, protected type methods Authors_Name Peter Ashenden Authors_Phone_Number +61 Authors_Fax_Number Authors_Email_Address peter@ashenden.com.au Authors_Affiliation Ashenden Designs Authors_Address1 Authors_Address2 Authors_Address3 Current Status: Forwarded Superseded By: ------------------------ Date Submitted: 14 June 2006 Date Analyzed: 08 September 2006 Author of Analysis: Chuck Swart Revision Number: 1 Date Last Revised: 08 September 2006 Description of Problem ---------------------- This was originally raised by Chuck Swart in the Accellera VHDL-TC review of P1076-2006/D2.11: Description: [reply] Opened: 2006-06-14 13:48 page 39, 2.4.1 Contains the following paragraph (unchanged from VHDL 2002): "The subprogram specification of a unary operator must have a single parameter, unless the subprogram specification is a method of a protected type. In this latter case, the subprogram specification must have no parameters. The subprogram specification of a binary operator must have two parameters; unless the subprogram specification is a method of a protected type, in which case, the subprogram specification must have a single parameter..." This is not correct. The pre-VHDL 2000 wording is correct: "The subprogram specification of a unary operator must have a single parameter. The subprogram specification of a binary operator must have two parameters..." ------- Additional Comment #1 From Peter Ashenden 2006-06-14 21:06 [reply] ------- My recollection of the rationale for the change (which was made in P1076a) is that, for a protected type method, the prefix object is implicitly an operand. Thus, we might define a protected type type T is protected impure function "abs" return real; impure function "*" (R : real) return real; end protected T; To use the operators, you'd currently have to invoke them in function-call form, eg: shared variable V : T; ... X <: V."abs"; Y <= V."*"(2.0); I don't recall why we didn't go further to specify rules for interpreting use of operator methods in operator form. For example, we could conceivably rewrite the above as: X <= abs V; Y <= V * 2.0; This would need rules saying that a unary method application is equivalent to a function call with the operand as the prefix, and a binary method application is equivalent to a function call with the left operand as a prefix. How you'd define an operator that can have the variable as the right operand would be an issue to consider. Given our discussion in the LRM-SC telecon on 13-Jun-2006, this would be an issue for the ISAC to address, since it relates to VHDL-2002. Hence, I'll submit an ISAC IR. In the longer term, we'll also need to revisit this if we use protected types as the starting point for OO class types. Hence, I'll mark this bug as resolved/later. Proposed Resolution ------------------- VASG-ISAC Analysis & Rationale ------------------------------ This issue needs to be addressed in the broader context of extending the language to allow class types. In the VHDL-2000 revision work, there were discussions of related issues, such as the problems of passing protected objects as function parameters: function parameters must be of mode IN, but protected parameters must be of mode INOUT. A reference to this discussion is: http://www.eda.org/isac/hm/0316.html. VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- The issue is unresolved for VHDL-2002 VASG-ISAC Recommendation for Future Revisions --------------------------------------------- This issue is a requirement for future language revisions. -------------END OF IR----------------