VHDL Issue Number: 0080 Classification: Language Definition Problem Language Version: VHDL-87 Summary: It is unclear when an aggregate is of a globally static subtype. Related Issues: 0022, 0094 Relevant LRM Sections: 7.3.2ff, 7.4 Key Words and Phrases: Aggregate, globally static subtype Current Status: VASG-Approved 1076-1993 Disposition: Closed Disposition Rationale: Section 7.4.2 Superseded By: N/A ----------------------- Date Submitted: 1989/02/10 Author of Submission: Doug Dunlop Author's Affiliation: Intermetrics, Inc. Author's Post Address: 4733 Bethesda Ave #415 Bethesda, MD 20814 Author's Phone Number: (301) 657-3775 Author's Fax Number: Author's Net Address: dunlop@inmet.inmet.com ----------------------- Date Analyzed: 1989/10/23 Author of Analysis: Paul Menchini (mench@clsi.com) Revision Number: $Revision: 1.9 $ Date Last Revised: $Date: 1995/06/10 00:42:38 $ Description of Problem ---------------------- An aggregate is allowed as a globally static expression provided several conditions are met concerning the aggregate. One of these conditions is that the aggregate be of a globally static subtype. The subtype of an aggregate is not defined in the LRM. It specifies the type for all aggregates, and, for array aggregates, the bounds and the direction(s) of the index subtype(s) of the aggregate. These do not imply an array subtype for the aggregate from which the criteria of LRM 7.4 can be applied. Another separate but related problem to this has to do with the evaluation time of record aggregates. No matter how the LRM defines their subtype, these can never be static expressions. This is because a globally static subtype must be either a scalar subtype or an array subtype (LRM 7.4). Proposed Resolution ------------------- We will for now ignore this issue of the subtype of an aggregate and base the evaluation time of an aggregate on the evaluation times of the expressions it contains. VASG-ISAC Analysis & Rationale ------------------------------ The LRM states that the type of an aggregate "must be determinable from context"; i.e., the declaration, statement, or expression in which the aggregate appears must supply enough information in order to determine whether the aggregate is an array aggregate or a record aggregate. Moreover, if the aggregate is an array aggregate, the analyzer must also be able to determine the element and index types of the aggregate. Otherwise, if the aggregate is a record aggregate, the analyzer must also be able to determine the element types. (See Sections 7.3.2ff for aggregates used in expressions, Sections 8.3, 8.4, and 9.5ff for aggregates used as assignment targets.) In contrast, the LRM does not state how to determine the subtype of an aggregate (which is interesting only for an array aggregate--we limit our discussion from here on to array aggregates). Instead, it states rules for determining the number of elements, and in some cases, the bounds and direction of the index subtype(s) of the aggregate. Such rules are sufficient for assignment and expression evaluation, because only the "matching element rule" of Section 7.2.1 applies--implicit subtype conversion occurs during assignment (see Sections 8.3, 8.4, and 9.5ff). Thus, Section 7.4, when defining under what circumstances an aggregate is a globally static primary, makes reference to an undefined concept. The issue author's solution to this problem is tempting. Since an aggregate is a collection of names (in the formal parts of the element associations making up the aggregate), ranges (also in the formal parts), expressions (in the formal and actual parts), and (sub-)aggregates (as actuals), why not define the permissible evaluation time of an aggregate in terms of the most restrictive evaluation time of its components? Then, the notion of the subtype of an aggregate could be entirely dispensed with, along with the requirement that this (mythical) subtype be globally static. This works well in the case of record aggregates; the number, names, and types of the record's elements are known to the analyzer, only the expressions in the actual part of the element associations must be computed. However, the solution may have problems for array aggregates. The requirement that a primary be of a locally or globally static subtype is used extensively in Section 7.4. In the case of a primary of a scalar type, this requirement seems to make little sense except for the purposes of range checks. If the value of a primary can be computed, then the only purpose behind the requirement that its subtype be static is so that this value can be determined to be part of the subtype. The requirement is of greater importance in the case of an array aggregate. In such a case, the subtype defines the bounds and direction(s) of the index range(s). The determination of the index subtype(s) is a necessary part of the evaluation of the aggregate. There are four cases that must be considered: 1. The aggregate's context implies a subtype, the aggregate does not. For example, "constant C: bit_vector (7 downto 0) := (others => '0');". 2. The aggregate provides subtype information, the context does not: "constant C: bit_vector := (7 downto 0 => '0'); 3. Both the aggregate and its context provide subtype information: "constant C: bit_vector (7 downto 0) := (7 downto 0 => '0'); 4. Neither the aggregate nor its context provide subtype information: "constant C: bit_vector := (others => '0'); Case 4 is illegal and need not be considered further. In Cases 1 and 2, the subtype must be globally static so that the number of elements of the aggregate can be determined. In Case 3, at least one of the subtypes must be static for the same reason. Both must be if one is to make subtype checks when the aggregate is evaluated. The author's solution can be applied in Cases 2 and 3. But what about Case 1? The keyword "others" is not an expression. Therefore, it seems not to figure in the determination of the aggregate's "staticness". Nevertheless, the number of elements in the aggregate must be determinable at the time of the computation of the aggregate's value. There is only one place where the number of elements within an aggregate may vary dynamically; in an object declared within a subprogram declarative part. Based on our short-term resolution of Issue 0022, we may evaluate all other expressions associated with statically elaborated objects. Therefore, we always can determine the number of elements in a statically elaborated object initialized with an aggregate. Therefore, the author's solution suffices. VASG-ISAC Recommendation for IEEE Std 1076-1987 ----------------------------------------------- Adopt the author's recommendations, with one minor extension. Specifically, read Item 5 of Paragraph 7 of Section 7.4 (on page 7-16) as: "5. an array aggregate, the expressions in the element associations of which are all globally static expressions and the ranges in the element associations of which are all globally static ranges. 5a. a record aggregate, the expressions in the element associations of which are all globally static expressions." (In other words, an aggregate is a globally static primary if two conditions hold: 1. For each expression in the aggregate, it must be a globally static expression. 2. For each range in the aggregate, it must be a globally static range. The first condition applies to all aggregates, while the second applies only to array aggregates.) VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Formalize this concept in the LRM as part of the overall cleanup of static expressions.