Hi, The attached is the ISAC response to the 2 June 2006 VASG IR ballots. Best Regards, Jim -------- Original Message -------- Subject: IEEE: response to 2 June 2006 VASG IR ballot Date: Thu, 24 Aug 2006 13:34:42 -0700 From: Chuck Swart <cswart@model.com> To: Jim Lewis <Jim@synthworks.com> Jim, Here is our response document to VASG ballot. Note that all of these IRs have already been incorporated into the D3.0 Accellera LRM. However, you might want to forward this document to those who voted on these IRs. Chuck Swart chair, ISAC -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis Director of Training mailto:Jim@SynthWorks.com SynthWorks Design Inc. http://www.SynthWorks.com 1-503-590-4787 Expert VHDL Training for Hardware Design and Verification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This is the response to the ballots for ISAC-Approved Issue Reports which closed on 02 June 2006 The following IRs were submitted for ballot: 2038 Minor semantic errors 2062 Range staticness 2074 Problem with direct/select visibility in formal part 2082 Elaboration of unconstrained interface objects 2085 What happens when a parameter of mode out is not assigned in a procedure? 2086 Incorrect description of type mark in disconnection specification 2091 Translation between std_logic_vector based types and std_ulogic_vector 2092 Type conversions don't allow for null arrays 2093 Static type conversions and qualified expressions 2094 Attribute specifications of overloaded subprograms is limited 2095 What is the entity class of an enumeration literal? All IRs were approved. There was only one negative vote, discussed below. IRs approved without comments: 2038 2062 2074 2086 2092 2094 2095 IRs which received comments but no negative votes (analysis supplied primarily by Peter Ashenden): 2082 A reviewer suggests that "If we are going to have OUT variable parameter always initialized to a value we should allow OUT variable parameters to have explicit default values." ISAC response: While there is value in the suggestion of allowing explicit default value expressions for out mode variable parameters, that is a language extension that should be proposed to the requirements committee, rather than being addressed by ISAC. 2091: Two reviewers pointed out that (only one reviewer quoted) "the reason for the conversion functions in std_logic_1164 is that the package was initially written for the 87 version of the spec and the changes to allow array types to be closely related is a 93 addition." These remarks demonstrate the value of preserving the history of the language's evolution. 2093: A reviewer remarked: "Minor misstatement in the rationale and analysis, but I agree with the change." ISAC response: We are not sure what the misstatement is. the reviewer will be contacted and asked to clarify. However, since this is "minor" the IR stands approved. One IR received a negative vote: 2085 The negative voter states (quoted in full): "The rationale given is not compelling to me. Unless the parameter is read, it need not be initialized. That may be considered an optimization issue. The optimization is reasonable to enable, if the out mod parameter is not written back unless written to. It has intuitive behavior with respect to other optimizations like inlining, which may be done manually by the user. I don't object to defining its initial value, where there is reason to require it. I do object to requiring unconditional write back. Perhaps there is further rationale to justify that which I am unaware of." ISAC analysis: The IR specifies the semantics of parameter passing for out-mode variable parameters, but does not preclude optimizations in implementations, provided the semantics are adhered to. The IR clarifies semantics that were previously ambiguous. The newly specified semantics are consistent with other aspects of parameter passing and adhere to the principle of correspondence in language design. The unconditional write-back referred to by the balloter is an existing aspect of the semantics of out-mode variable parameters. Changing that aspect is out of scope for the IR. What was not clear was initialization of such a parameter. This aspect was exposed by implementation-dependent results for the final value of the associated actual parameter when the formal was unassigned. With the change to allow out-mode parameters to be read, it will become significant when the parameter is read in the procedure before being assigned. The recommended change makes out-mode variable parameters consistent with other objects, being implicitly initialized to the left-most value of the subtype. ISAC conclusion: This was a difficult decision. There is considerable merit in not initializing out-mode parameters which are passed by reference: a) performance may be improved and b) this most closely matches in-line semantics. Arguments in favor of requiring initialization are: a) for parameters which are not passed by reference, the LRM currently requires that all such values be initialized and b) since implementations decides whether to pass by reference or by copy-in copy-out semantics, any change which distinguishes between the two methods would potentially produce non-portable code. Since 1) there was only one negative vote and 2) the proposed solution is more consistent with existing VHDL semantics, the IR is VASG Approved. In conclusion, all IRs have been VASG Approved. (In fact, they have already been incorporated into the D3.0 version of the Accellera LRM.)Received on Fri Sep 8 07:31:04 2006
This archive was generated by hypermail 2.1.8 : Fri Sep 08 2006 - 07:32:12 PDT