-------------BEGINNING OF IR---------------- VHDL Issue Number: 2048 Language_Version: VHDL-2002 Classification: Language Definition Problem Summary: Miscellaneous errors Relevant_LRM_Sections: various Related_Issues: Key_Words_and_Phrases: Authors_Name: Tristan Gingold (by Peter Ashenden on behalf of submitter) Authors_Phone_Number: Authors_Fax_Number: Authors_Email_Address: tgingold@free.fr Authors_Affiliation: Authors_Address1: Authors_Address2: Authors_Address3: Current Status: VASG-Approved Superseded By: ------------------------ Date Submitted: 29 November 2004 Date Analyzed: 10 December 2004 Author of Analysis: Chuck Swart Revision Number: 7 Date Last Revised: 09 May 2005 Description of Problem ---------------------- 1) The return type of a function can be a file type. However, it is of course not possible to write a correct body for such a declaration. Proposition: The return type of a function must denote neither a file type nor a protected type. VASG-ISAC Analysis & Rationale: Functions return values.Since neither files nor objects of protected types have defined values, it doesn't make sense to allow them. The submitter's proposed solution is accepted. VASG-ISAC Recommendation for IEEE Std 1076-2002 No change. VASG-ISAC Recommendation for Future Revisions Add to section 2.1 the statement: "It is an error if the return type of a function denotes either an file type or a protected type." In section 3.5.1, change the sentence which reads: "Additionally, in the case of a function subprogram, the return type of the function must not be of an access type or file type;" to: "Additionally, in the case of a function subprogram, the return type of the function must not be of an access type;" Change part of the note at the end of section 3.5.1 which reads: "Such subprograms may have parameters and (in the case of functions) return types that are or contain access and file types." to: "Such subprograms may have parameters that are or contain access or file types and (in the case of functions) return types that are or contain access types." 2) An alias of a physical type is not possible, although described in the LRM. Indeed, a physical type is always an anonymous type. Only physical subtypes can be aliased. Proposition: Are non-object aliases really used ? Non-object aliases were added to be able to re-export declarations, but they cannot be used for this purpose. VASG-ISAC Analysis & Rationale: This issue has already been identified in IR 2038 "Minor semantic errors". VASG-ISAC Recommendation for IEEE Std 1076-2002 Superseded by IR 2038. VASG-ISAC Recommendation for Future Revisions Superseded by IR 2038. 3) Character literal can be decorated through an attribute specification, but the 'decoration' cannot be referenced (because the prefix of an attribute cannot be a character). VASG-ISAC Analysis & Rationale: It is true that attributes on literals cannot be referenced from within VHDL, but these attributes can be used by other tools, which is one of the reasons for using attributes. VASG-ISAC Recommendation for IEEE Std 1076-2002 No change. VASG-ISAC Recommendation for Future Revisions If there is sufficient benefit, consider allowing attributes on literals to be referenced. However, note that this might make language parsing much more difficult. 4) It is possible to write pure functions that do not return the same value: type string_acc is access string; pure function alloc (str : string) return string_acc is begin return new string'(str); end alloc; Proposition: forbid allocators in pure functions (directly or indirectly) as well as calls to the implicit deallocate procedures. VASG-ISAC Analysis & Rationale: There is an issue here, and the submitter's proposal makes sense. The question was raised whether the restrictions should be added to impure functions. It was noted that pure functions cannot reference a file object or a shared variable.(see section 2.2). The least restrictive rule which preserves the intent of purity is to forbid access types as return values from functions. VASG-ISAC Recommendation for IEEE Std 1076-2002 Interpret the LRM as if the Recommendation for Future Revisions had been adopted. VASG-ISAC Recommendation for Future Revisions In section 2.1, following the text recommended for item 1) add: "Moreover, it is an error if the return type of a pure function denotes an access type or a subtype that has a subelement of an access type." 5) Some trivial expressions are not valid: constant c : integer := -3; The expression is ambiguous, since the "-" can either that of the integer type or that of the universal integer type. For sure, in this example the result is the same, but what about: function "-" (v : integer) return integer is begin return 0; end; constant c : integer := -3; Proposition: Do like Ada: preference for universal operators. VASG-ISAC Analysis & Rationale: The submitter is mistaken. The expression constant c : integer := -3; is not ambiguous. Section 7.3.5 states: "An implicit conversion of an operand of type universal-integer to another integer type, or of an operand of type universal_real to another floating point type, can only be applied if the operand is either a numeric literal or an attribute, or if the operand is an expression consisting of the division of a value of a physical type by a value of the same type." So the only valid interpretation of -3 is that 3 is converted to type INTEGER and the - operator is that of type INTEGER. There are some very subtle ambiguity problems with universal types, but they are very esoteric and don't occur in real designs. See IR 0088 "Overloaded convertible operands make type analysis very difficult". VASG-ISAC Recommendation for IEEE Std 1076-2002 No change. VASG-ISAC Recommendation for Future Revisions No change. 6) Does a generate statement have a declarative part ? No, according to grammar from 9.7, but some of the block_declarative_item are specifications which are valid only inside declarative part... Proposition: Replace "{ block_declarative_item }" with "block_declarative_part". VASG-ISAC Analysis & Rationale: The submitter is correct and his proposal is accepted. VASG-ISAC Recommendation for IEEE Std 1076-2002 View the LRM as if it read as the proposer suggests. VASG-ISAC Recommendation for Future Revisions Rewrite the LRM as proposed. 7) What is the meaning of: type t is array (boolean) of bit; signal s : t; ... wait on s (time < 10 ns); Suppose the wait statement starts to execute at 9 ns, and there is an event at 11 ns on s (true). Does the wait statement finish ? This bug is due to the fact that globally static expression are not static. Proposition: why the time function is pure ? VASG-ISAC Analysis & Rationale: It appears that the submitter means "NOW" where he uses "time". If so, then this issue has been addressed in IR 2032: Function "NOW" is not pure VASG-ISAC Recommendation for IEEE Std 1076-2002 Superseded by IR 2032. VASG-ISAC Recommendation for Future Revisions Superseded by IR 2032. 8) What is the meaning of 'signature' in 'INSTANCE_NAME and 'PATH_NAME ? What is the signature of function f return natural ? [return natural] or [return integer]. At least, the use of these attributes is nonportable. VASG-ISAC Analysis & Rationale: There is a genuine issue here. Probably, the best solution is to generate the profile using the same type marks as the corresponding subprogram declaration. It was also noted that the LRM does not give any meaning to a signature in an instance or path name (although there is an obvious intent.) VASG-ISAC Recommendation for IEEE Std 1076-2002 Interpret the LRM as of the Recommendation for Future Revisions had been adopted. VASG-ISAC Recommendation for Future Revisions Add to Clause 14.1 E'INSTANCE_NAME: For E'INSTANCE_NAME and E'PATH_NAME, a signature occurring after a subprogram designator matches the parameter and result type profile of the subprogram. Each type mark in the signature is the type mark of the subtype indication of the corresponding formal parameter, or the return type mark, as appropriate, in the subprogram declaration. 9) The default entity aspect is ambiguous, because rules a) and c) or b) and c) of 5.2.2 can results in two visible entity declaration. Proposition: Remove rules a) and b), that are neither intuitive nor understandable. VASG-ISAC Analysis & Rationale: Rules a), b) and c) in section 5.2.2 are supposed to be applied in order, although the LRM isn't clear about this. The submitter's proposal to drop rules a) and b) would not be backward compatible. VASG-ISAC Recommendation for IEEE Std 1076-2002 Treat rules a), b) and c) of section 5.2.2 as if there were an implied ordering. VASG-ISAC Recommendation for Future Revisions Rewrite section 5.2.2 to reflect the intended ordering. 10) Constant parameter of access types are implicitly allowed: type line is access string; seems to implicitly define: function "=" (constant : line; constant : line) return boolean; These functions (if they really exist) are of course not overloadable. The restriction (constant parameter cannot be of access type) was not well considered (remember the endline function of std.textio). Although this is not explained, I suppose the reason why this restriction exists is because it prevents from defining pure function that returns different values when called with the same parameters. Proposition: 1) allow constant parameter of access types for procedures and impure functions. 2) Allow constant parameter of access types for pure functions but forbid to dereference such parameters in pure functions. VASG-ISAC Analysis & Rationale: This is issue IR 2057 VASG-ISAC Recommendation for IEEE Std 1076-2002 Superseded by IR 2057 VASG-ISAC Recommendation for Future Revisions Superseded by IR 2057 Extra bugs: 11a) There is a missing ';' in example of E'PATH_NAME after the generic clause of component BComp declared inside architecture top of top. VASG-ISAC Analysis & Rationale: Yes, the ';' is missing. VASG-ISAC Recommendation for IEEE Std 1076-2002 Interpret the example as if the ';' were present. VASG-ISAC Recommendation for Future Revisions Add the missing ';' to the example. 11b) There is a missing ':' before gbottom'path_name. VASG-ISAC Analysis & Rationale: Yes, the ':' is missing. VASG-ISAC Recommendation for IEEE Std 1076-2002 Interpret the example as if the ':' were present. VASG-ISAC Recommendation for Future Revisions Interpret the example as if the ':' were present. 12) Names of protected type examples in 3.5.1 and 3.5.2 do not match: VariableSizedBitArray vs VariableSizeBitArray. VASG-ISAC Analysis & Rationale: This is item 18. of IR 2039 "Minor typos" VASG-ISAC Recommendation for IEEE Std 1076-2002 Superseded by IR 2039. VASG-ISAC Recommendation for Future Revisions Superseded by IR 2039. Proposed Resolution ------------------- As above VASG-ISAC Analysis & Rationale ------------------------------ As above VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- As above VASG-ISAC Recommendation for Future Revisions --------------------------------------------- As above -------------END OF IR----------------