Our plate for next meeting is very full!
See (via telecom) all of you in January
Chuck Swart
VHDL Issue Number: 2038
Language_Version: VHDL-2002
Classification: LRM Terminology, Grammar and Typographical Errors
Summary: Minor semantic errors
Relevant_LRM_Sections:
Related_Issues:
Key_Words_and_Phrases:
Authors_Name: Chuck Swart
Authors_Phone_Number: 503.685.0846
Authors_Fax_Number: 503.685.0921
Authors_Email_Address: cswart@model.com
Authors_Affiliation: Model Technology
Authors_Address1: - 8005 SW Boeckman Rd
Authors_Address2: - Wilsonville, OR 97070
Authors_Address3: -
Current Status: Submitted
Superseded By:
------------------------
Date Submitted: 02 July 2004
Date Analyzed:
Author of Analysis:
Revision Number: 1
Date Last Revised: 15 December 2004
Description of Problem
----------------------
This is a repository for low-level errors in the LRM which are
basically typos, but which require some analysis to correct. An
example is the use of the word "type" where "base type" or "subtype"
is correct.
1. Section 4.3.3.2 Nonobject aliases
"d) Alternatively, if the name denotes a physical type [...]"
Indeed, physical types are always anonymous. This is due to
clause 3.1.3 (Physical types): A physical type definition defines
both a type and a subtype of that type. The type is an anonymous
type, [...]
As a consequence, the use of a nonobject alias is certainly more
limited than expected (export feature described in LCS-0008).
The following were submitted by James Unterburger (jamesu@model.com)
2. Section 1.3.1, line 356
Does not state that discrete_range must be (globally) static.
Does not state that type of discrete_range or static_expression
must be the same as the type of the FOR GENERATE parameter.
Unclear if the discrete_range or static_expression must belong to
the subtype of the FOR GENERATE parameter and what it means if
they do not, or if a null discrete_range is allowed or not.
3. Section 3.2.1.1, line 383
The rules for determining the index range(s) for individually
associated formals of an unconstrained array subtype do not say
what to do with null slice names in the choices in the association
elements when determining the "maximum and minimum values of the
indices given in the association elements corresponding to the
formal". In fact, they don't mention slices at all, instead using
the term "indices" meaning that they thought only of indexed
names, and not slice names at this point in the LRM.
4. Section 4.3.2.2, line 463
Uses the the term "element association" when "association element"
is intended. Same mistake on lines 468 and 474.
5. Section 4.3.2.2, line 511
Verbiage for "formal port" should probably include a
cross-reference to 1.1.1.2, where stricter rules are laid down.
6. Section 7.2.3, line 138
The term "index subtypes" is used instead of "index ranges" or
"index bounds and direction". Perhaps this sentence should refer
to them in the singular:
The index range of the return value of each of the shift
operators is the same as that of the left operand.
7. Section 7.2.4, line 203 and 7.3.2.2, lines 439 and 440
Same mistaking of "index subtype" for "index range" on 7.2.4, line
203 and also at 7.3.2.2, lines 439 and 440.
8. Section 7.3.1, line 347
The rules for determining the index bounds of a null string
literal say to use either PRED or SUCC, yet the [14.1 Predefined
attributes] rules for these attributes produce an error. A
related problem is that the index range of a null array with an
index subtype that is an enumeration type has no legal
representation at all: type foo is array(character range <>) of
bit; constant c : foo := ""; Constant c has left bound nul,
direction TO, and right bound ???
9. Section 7.3.2.2, line 422
The list appears to have "formal port" left out by mistake, no
doubt when they went from 87 to 93, where expressions in PORT MAPs
became legal.
10. Section 7.3.2.2, line 417
"An OTHERS choice is locally static if the applicable index
constraint is locally static." -- What does "applicable index
constraint" mean?
11. Section 7.3.1, lines 345 and 348
They mention "the direction and bounds of the array value" but
they mean "direction and bounds of the array's index range".
12. Section 3.3, line 491
Says that an object created by an allocator has no simple name,
and that the access value returned by that allocator designates
the object. Yet 8.5, line 360 says that determining the target
type in a variable assignment statement may require determining the
expression type if the target is a name that can be interpreted as
the name of a variable designated by the access value returned by
a function call. Since objects designated by access values have
no names, then how can the access value returned by a function
call be the name of the value is designates?
13. Section8.5, paragraph at line 344
Does not repeat rules similar to those stated in 8.4, paragraph at
line 176, regarding OTHERS choice and discrete range choice.
14. Section 8.4
Does not go into detail, as does 8.5.1, about how an implicit
subtype conversion between array types during signal assignment
occurs.
15. Section 8.4 and 8.5
For aggregate targets, does not specify whether or not an implicit
subtype conversion occurs, for the aggregate as a whole, when of
an array type.
Proposed Resolution
-------------------
TBD
VASG-ISAC Analysis & Rationale
------------------------------
TBD
VASG-ISAC Recommendation for IEEE Std 1076-2003
-----------------------------------------------
TBD
VASG-ISAC Recommendation for Future Revisions
---------------------------------------------
TBD
-------------END OF IR----------------
Received on Wed Dec 15 17:23:21 2004
This archive was generated by hypermail 2.1.8 : Wed Dec 15 2004 - 17:23:25 PST