VHDL Issue Number: 0099 Classification: Language Definition Problem Language Version: VHDL-87 Summary: When are the bounds of array subaggregates known? Related Issues: None. Relevant LRM Sections: 7.3.2.2, 7.3.1 Key Words and Phrases: Others, bounds, index subtype, arrays, subaggregates, aggregates, records, multi-dimensional aggregate Current Status: Closed (Andy Tsay) 1076-1993 Disposition: Closed (All Issues Completely Addressed) Disposition Rationale: LRM was updated. Superseded By: N/A ----------------------- Date Submitted: 1991/02/11 Author of Submission: Paul Menchini Author's Affiliation: CAD Language Systems, Inc. Author's Post Address: P.O. Box 13036 Research Triangle Park, NC 27709-3036 Author's Phone Number: (919) 361-1913 Author's Fax Number: Author's Net Address: mench@clsi.com ----------------------- Date Analyzed: 1994/03/26 Author of Analysis: Andy Tsay (Fintronic USA) Revision Number: $Revision: 1.10 $ Date Last Revised: $Date: 1995/08/03 18:13:40 $ Description of Problem ---------------------- When may 'others' be used as the choice in an array subaggregate? To illustrate, consider the following package: package P is type A1 is array (0 to 0, 31 downto 0) of Bit; constant A1_1: A1 := (0 => X"00000000"); constant A1_2: A1 := (others => X"00000000"); constant A1_3: A1 := (0 => (others => '0')); constant A1_4: A1 := (others => (others => '0')); type A2 is array (0 to 0) of Bit_Vector (31 downto 0); constant A2_1: A2 := (0 => X"00000000"); constant A2_2: A2 := (others => X"00000000"); constant A2_3: A2 := (0 => (others => '0')); constant A2_4: A2 := (others => (others => '0')); type R is record F: Bit_Vector (31 downto 0); end record; constant R1: R := (F => X"00000000"); constant R2: R := (others => X"00000000"); constant R3: R := (F => (others => '0')); constant R4: R := (others => (others => '0')); end P; Which of the twelve constants are legal? The applicable LRM language is found in Paragraph 3 of Section 7.3.2.2, on pages 7-10 and -11: The subtype of an array aggregate that has an others choice must be determinable from the context. That is, an array aggregate with an others choice may only appear: ... 9. As a subaggregate of a multi-dimensional aggregate, where that aggregate itself appears in one of these contexts. This statement hinges on the definition of the term "multi-dimensional aggregate." Unfortunately, the LRM does not define this term, but uses it twice. The other occurrence is in the last sentence of Paragraph 1 of Section 7.3.2.2: A string or bit string literal is allowed in a multi-dimensional aggregate at the place of a one-dimensional array of a character type. This first occurrence immediately follows the following statement: An aggregate of an n-dimensional array type, where n is greater than 1, is written as a one-dimensional aggregate in which the index subtype of the aggregate is given by the first index position of the array type, and the expression specified for each element association is an (n-1)-dimensional array or array aggregate. which is apparently intended to be the definition of a "multi-dimensional aggregate." (Note that Section 7.3.3.2 is adopted, with few changes from Ada. The analogous section of the Ada Reference Manual, Section 4.3.2, is the subject of considerable annotation in the Annotated Ada Reference Manual, indicating that the Ada implementors and maintainers have had similar difficulty with array aggregates in Ada.) However, there are problems if this statement is taken as the definition of the term "multi-dimensional aggregate." Consider the types A2 and R in the example above. They clearly are not multi-dimensional arrays. Nevertheless, values of these types may be expressed as aggregates; moreover, as the element type of A2 and the type of the (single) field of R are themselves one-dimensional arrays (whose values may be aggregates), values of the types A2 and R may contain nested aggregates. Should not these nested aggregates also be considered "multi-dimensional aggregates"? Clearly, these nested subaggregates satisfy the criterion of Paragraph 3 that "their subtype ... be determinable from context." Finally, the phrase "multi-dimensional aggregate" seems misleading. Nested aggregates may be used as values of the following types: 1. Multi-dimensional array types. 2. One-dimensional array types whose element type is an array type. 3. Record types having one or more fields whose types are array types. 4. Record types having one or more fields whose types are record types. Therefore, the use of "dimension" in this context seems misleading, since records do not have dimension. Moreover, "multi" is also misleading in this context, since these values may be of a one-dimensional array type. Proposed Resolution ------------------- Discard the term "multi-dimensional aggregate." Instead, refer only to nested (sub) aggregates in Section 7.3.2.2. Specifically, in Paragraph 1, replace the last sentence with: A string or bit string literal is allowed in place of any aggregate of a one-dimensional array of a character type. (This change covers the base case in addition to the recursive case of nested aggregates. Alternatively, the sentence could be discarded, since the case is covered in Paragraph 4 of Section 7.3.1, on page 7-9.) Also change Item 9 of Paragraph 3 to read: 9. As a subaggregate nested within an aggregate, where the outermost aggregate itself appears in one of these contexts. Finally, adopt any other relevant changes from the Annotated Ada Reference Manual. VASG-ISAC Analysis & Rationale ------------------------------ TBD VASG-ISAC Recommendation for IEEE Std 1076-1987 ----------------------------------------------- TBD VASG-ISAC Recommendation for Future Revisions --------------------------------------------- LRM revised in IEEE Std 1076-1993 as recommended. Issue closed.