ISAC: Analysis of IR 2092 Type conversions don't allow for null arrays

From: Chuck Swart <cswart_at_.....>
Date: Wed May 03 2006 - 16:50:20 PDT
We can discuss this at our upcoming meeting.

Chuck Swart


-------------BEGINNING OF IR----------------

VHDL Issue Number:        2092

Language_Version          VHDL-2002
Classification            Language Definition Problem
Summary                   Type conversions don't allow for null arrays
Relevant_LRM_Sections     7.3.5 Type conversions
Related_Issues            IR 2075 Arrays with numeric and enumeration index 
                          types are not closely related
Key_Words_and_Phrases     type conversion, null array
Authors_Name              Peter Ashenden
Authors_Phone_Number      +61 414 709 106
Authors_Fax_Number        
Authors_Email_Address     peter@ashenden.com.au
Authors_Affiliation       Ashenden Designs
Authors_Address1          
Authors_Address2          
Authors_Address3          

Current Status:           Analyzed

Superseded By:

------------------------
Date Submitted:           24 April 2006
Date Analyzed:            03 May 2006
Author of Analysis:       Chuck Swart
Revision Number:          1
Date Last Revised:        03 May 2006

Description of Problem
----------------------

The rules for type conversions for array types include:
    
    In an explicit type conversion where the type mark denotes an
    array type, the following rules apply: if the type mark denotes an
    unconstrained array type and if the operand is not a null array,
    then, for each index position, the bounds of the result are
    obtained by converting the bounds of the operand to the
    corresponding index type of the target type. If the type mark
    denotes a constrained array subtype, then the bounds of the result
    are those imposed by the type mark. In either case, the value of
    each element of the result is that of the matching element of the
    operand (see 7.2.2).
    
    This misses the case of the type mark denoting a unconstrained
    array type and the operand being a null array. For this case,
    there is no definition of the bounds of the result.

Proposed Resolution
-------------------

It's not clear why a null array is excluded in the case of the type
mark denoting an unconstrained array. If there is no good reason for
this, then the exclusion can be dropped, thus subsuming the missing
case. If there is good reason, then a separate rule covering the
missing case needs to be devised, taking into account the reason for
the exclusion.

VASG-ISAC Analysis & Rationale
------------------------------

There does not appear to be any good reason for excluding null arrays
in the case of type marks denoting an unconstrained array type.

The Ada 1983 LRM, upon which the VHDL LRM is based, does not have such
an exclusion. The Ada 1995 LRM, which is written in a different style
says for array type conversions: "...For each nonnull index range, a
check is made that the bounds of the range belong to the corresponding
index subtype." This statement implies that null arrays (which have at
least one null index range) are legal.

In addition to removing the restriction on null arrays from the
original text, a small additional wording change is required to
implement IR 2075, which allows conversions between arrays with
numeric and enumeration index types.  To achieve maximum generality,
in computing array bounds for a target type that is unconstrained, the
direction of the result is that of the target type and the left bound
of each index subtype is the left bound of the corresponding target
index type.  For null arrays, null index ranges in the expression
would have to be mapped to null index ranges in the result.

VASG-ISAC Recommendation for IEEE Std 1076-2002
-----------------------------------------------

Modify the proposed solution to IR 2075 to generate null index ranges
in the result to correspond to null index ranges in the expression.

VASG-ISAC Recommendation for Future Revisions
---------------------------------------------




-------------END OF IR----------------
Received on Wed May 3 16:50:23 2006

This archive was generated by hypermail 2.1.8 : Wed May 03 2006 - 16:50:27 PDT