ISAC: Analysis of IR 2073: Index constraints and discrete range conversions from universal_integer

Please read this over carefully. I would appreciate any help in 
improving the
text.  We'll go over it at the next meeting.

Chuck



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

VHDL Issue Number:        2073 

Language_Version          VHDL-2002
Classification            Language Definition Problem
Summary                   Index constraints and discrete range conversions from universal_integer
Relevant_LRM_Sections      3.2.1.1  Index constraints and discrete ranges
Related_Issues            
Key_Words_and_Phrases     range, type, universal_integer
Authors_Name              Gingold
Authors_Phone_Number      0
Authors_Fax_Number        
Authors_Email_Address     tgingold@free.fr
Authors_Affiliation       
Authors_Address1          
Authors_Address2          
Authors_Address3          

Current Status:           Analyzed

Superseded By:

------------------------
Date Submitted:           24 August 2005
Date Analyzed:			  31 October 2005
Author of Analysis:		  Chuck Swart
Revision Number:          1
Date Last Revised:		  31 October 2005

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

The above section makes such a code invalid:
      for i in 0 to 2 ** N - 1 loop ...
    However, the user may like to use such constructs,
    and I don't think there is rational to deny them.
    The work-around is to write:
      for i in integer range ...
    But this is more verbose.
    
    I think this is a real issue, since even the IEEE
    vital code use such invalid construct.  (Of course,
    VITAL use other invalid construct, but this is not
    for VASG).

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

Replace
 
   "an implicit conversion to the predefined type INTEGER is assumed
   if each bound is either a numeric literal or an attribute, and if
   the type of both bounds (prior to the implicit conversion) is the
   type universal_integer."
    
    by
    
    "an implicit conversion to the predefined type INTEGER is assumed
    if the type of both bounds (prior to the implicit conversion) is
    the type universal_integer."
    

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

This is a famous problem inherited from Ada 83.

In Ada 83 the expression

    for I in -1 to 100 loop ...

is illegal for the same reason as reported by the submitter.  The
solution for Ada 95 was to add two new anonymous types: root_integer
and root_real from which all other integer or real types derive. In
addition, the Ada 95 Rationale document states that "The overload
resolution rules of Ada 83 were confusing and unclear and this section
of the reference manual has been completely rewritten."

To change VHDL in the same way would require considerable effort,
which is probably not justified.

We should point out that many implementations already accept the
submitter's code, although it is technically illegal.

To understand the basic problem let's first look at a simpler example:

CONSTANT c1: integer := 3+5;

The fundamental problem is to determine which + operator is used.  The
two potential candidates are INTEGER + and universal_integer +.  From
a practical perspective, it seldom makes any difference which + is
used, but there is a theoretical issue. If the INTEGER + were
overloaded, perhaps to form some sort of absorbing operator, then the
choice of operator would be significant.

Clause 7.3.5 deals with this issue:

"An implicit conversion of an operand of type universal_integer to
another integer 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.  [Such a conversion] is applied if and only if the
innermost complete context determines a unique (numeric) target type
for the implicit conversion, and there is no legal interpretation of
this context without this conversion."

This clause implies that implicit conversions occur as far down as
possible in the expression tree. Therefore, in the constant expression
in the above example there is an implicit conversion of each literal
to type INTEGER, and then the INTEGER + operation is performed.

With this as background we can better understand the original
issue. It appears that the LRM in clause 3.2.1.1 allows only numeric
literals or attributes of type universal_integer, in order to prevent
any ambiguity about which operator applies. (As a side issue, the LRM
should have also allowed division of two physical types as in Clause
7.3.5). If we accept the proposed solution, then the ** operator will
be that of universal_integer, not that of INTEGER, i.e.,

  function "**" ( anonymous: universal_integer; anonymous: INTEGER) return universal_integer;

instead of the more natural:

  function "**" ( anonymous: INTEGER: anonymous: INTEGER) return INTEGER;


Although this is a problem theoretically, in practice this is
acceptable.


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

Interpret the LRM as if the submitter's suggestion were in effect.

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

Adopt the submitter's suggestion. Change clause 3.2.1.1 as indicated.


-------------END OF IR----------------