(r26) TopLCS2016_026a < P1076

P1076 Web>Vhdl2019CollectedRequirements>TopLCS2016_026a (revision 26) (raw view)~~EditAttach~~
---+ Language Change Specification for Long Integers

---++ 

| <sticky><b>LCS Number:</b></sticky> | LCS-2016-026a |
| <sticky><b>Version:</b>   </sticky> | 1 {10-Jan-2017} <span data-mce-mark="1">%BR%</span> 2 {11-Jan-2017} <span data-mce-mark="1">%BR%</span> 3 {13-Jan-2017} <span data-mce-mark="1">%BR%</span> 4 {26-Jan-2017} |
| <sticky><b>Date:</b>      </sticky> | 26-Jan-2017  |
| <sticky><b>Status:</b>    </sticky> | Voting |
| <sticky><b>Author:</b>    </sticky> | Patrick Lehmann |
| <sticky><b>Email:</b>     </sticky> | [[Main.PatrickLehmann]] |
| <sticky><b>Source Doc:</b></sticky> | [[LongIntegers][Long Integers]] |
| <sticky><b>Summary:</b>   </sticky> | Extends the range of integer types values. |

---+++ Voting Results: Cast your votes here

Yes:
   1 <span data-mce-mark="1">%USERSIG{YannGuidon - 2017-01-11}%</span> - ver 2
   1 <span data-mce-mark="1">%USERSIG{MartinZabel - 2017-02-10}%</span> - ver 4
   1 <span data-mce-mark="1">%USERSIG{DanielKho - 2017-01-19}%</span> - ver 3
   1 <span data-mce-mark="1">%USERSIG{LievenLemiengre - 2017-01-27}%</span> - ver 4
   1 <span data-mce-mark="1">%USERSIG{HendrikEeckhaut - 2017-01-27}%</span> ver 4
   1 <span data-mce-mark="1">%USERSIG{MartinThompson- 2017-02-17}%</span> ver 4
   1 <span data-mce-mark="1">%USERSIG{MarkZwolinski - 2017-02-28}%</span> ver 4

No:
   1 <span data-mce-mark="1">%USERSIG{ThomasPreusser - 2017-01-13}%</span> - ver 3 - see comment below: 64-bit yes, new types no
   1 <span data-mce-mark="1">%USERSIG{FarrellOstler - 2017-01-31}%</span> - ver 4 - I align with the viewpoint of ThomasPreusser.
   1 %USERSIG{RobGaddi - 2017-03-04}% - ver 4 - New types will require explicit typecasts all over the place. Prefer <a href="LCS2016_026c" title="LCS2016_026c">026c</a>
   1 %USERSIG{PatrickLehmann - 2017-03-04}% - ver 4 LCS 026c has a lower impact

Abstain:
   1 <span data-mce-mark="1">%USERSIG{BrentHahoe - 2017-02-16}%</span> Version 4 - Abstain due to lack of personal time for review.

---++ Style Notes

<noautolink>
<sticky>
Changes are shown in %RED%red font%ENDCOLOR%.%BR%
Deletions are %RED%<del>crossed out</del>%ENDCOLOR%.%BR%
Editing or reviewing notes in %GREEN%green font%ENDCOLOR%.
 
---++ Reviewing Notes
*Version 1:* %BR%
I don't want to minimize the effort from [[Main.PatrickLehmann][Kevin Jennings]], which he put into this proposal and especially answering all the user comments, but the %BR%
discussion seams to be stuck...

This LCS proposes a little step forward with only 64 bit (=LONG_INTEGER=). It also declares =INTEGER= as a subtype using only 32 bit. It also drops %BR%
compatibility for one's complement machines. A research unveiled that these machines are dead. If one finds a way (and an LCS) that brings us an %BR%
512 bit or even 1 MiBit _universal_integer_, please write it!

I strongly recommend that we continue on this LCS and the matching proposal for VHDL-202x.

*Version 2:* %BR%
Declared predefined array types with an index range of =LONG_NATURAL=.

*Version 3:* %BR%
Renamed predefined type to =INTEGER64=, =POSITIVE64=, =NATURAL64=, =INTEGER32=, =POSITIVE32=, =NATURAL32= and created aliases to the old names.

*Version 4:* %BR%
Introduced =SYSTEM_INTEGER= as a longterm name for a integer of growing size with an guaranteed minimal range.

---++ Details of Language Change
---+++ 5.2.3.1 General
%GREEN%[Editor note: Paragraph 8]%ENDCOLOR%

An implementation may restrict the bounds of the range constraint of integer types other than type _universal_integer_ . However, an implementation %BR%
shall allow the declaration of any integer type whose range is wholly contained within the bounds %RED%-(2**63)<del>-2147483647</del>%ENDCOLOR% and %RED%+(2**63)-1<del>+2147483647</del>%ENDCOLOR% %BR%
inclusive.


---+++ 5.2.3.2 Predefined integer types
The only predefined integer type is the type %RED%SYSTEM%ENDCOLOR%_INTEGER. The range of %RED%SYSTEM%ENDCOLOR%_INTEGER is implementation dependent, but it is guaranteed %BR%
to include the range %RED%-(2**63)<del>-2147483647</del>%ENDCOLOR% to %RED%+(2**63)-1<del>+2147483647</del>%ENDCOLOR%. It is defined with %BR%
an ascending range. %RED%The declaration of type SYSTEM_INTEGER appears in package STANDARD in Clause 16.%ENDCOLOR%

NOTE - The range of %RED%SYSTEM%ENDCOLOR%_INTEGER in a particular implementation is determinable from the values of its 'LOW and 'HIGH attributes.

---+++ 5.2.3.3 Predefined integer subtypes %GREEN%[New]%ENDCOLOR%
%RED%The following integer subtypes are predefined: INTEGER64, NATURAL64, POSITIVE64, INTEGER32, NATURAL32 and POSITIVE32. The listed subtypes %BR%
appears in package STANDARD in Clause 16.%ENDCOLOR%

<pre>%RED%
subtype INTEGER64  is SYSTEM_INTEGER range -2**63 to 2**63-1;
subtype NATURAL64  is SYSTEM_INTEGER range 0 to INTEGER64'HIGH;
subtype POSITIVE64 is SYSTEM_INTEGER range 1 to INTEGER64'HIGH;

subtype INTEGER32  is SYSTEM_INTEGER range -2**31 to 2**31-1;
subtype NATURAL32  is SYSTEM_INTEGER range 0 to INTEGER32'HIGH;
subtype POSITIVE32 is SYSTEM_INTEGER range 1 to INTEGER32'HIGH;
%ENDCOLOR%
</pre>

%RED%For compatibility, the following aliases are defined:%ENDCOLOR%

<pre>
%RED%
alias INTEGER  is INTEGER32;
alias NATURAL  is NATURAL32;
alias POSITIVE is POSITIVE32;
%ENDCOLOR%</pre>


---+++ 5.2.4.1 General
%GREEN%[Editor note: Paragraph 14]%ENDCOLOR%

An implementation may restrict the bounds of the range constraint of a physical type. However, an implementation shall allow the declaration of any %BR%
physical type whose range is wholly contained within the bounds %RED%-(2**63)<del>-2147483647</del>%ENDCOLOR% and %RED%+(2**63)-1<del>+2147483647</del>%ENDCOLOR% inclusive.


---+++ 5.2.4.2 Predefined physical types
The only predefined physical type is type TIME. The range of TIME is implementation dependent, but it is guaranteed to include the range %BR%
%RED%-(2**63)<del>-2147483647</del>%ENDCOLOR% to %RED%+(2**63)-1<del>+2147483647</del>%ENDCOLOR%. It is defined with an ascending range. All specifications of delays and pulse rejection limits shall %BR%
be of type TIME. The declaration of type TIME appears in package STANDARD in Clause 16.


---+++ 5.2.5.2 Predefined floating-point types
The only predefined floating-point type is the type REAL. The range of REAL is host-dependent, but it is guaranteed to be the largest allowed by the %BR%
chosen representation. It is defined with an ascending range. %RED%The declaration of type REAL appears in package STANDARD in Clause 16.%ENDCOLOR%


---+++ 5.3.2.2 Index constraints and discrete ranges
An index constraint determines the index range for every index of an array type and, thereby, the corresponding array bounds. For a discrete range %BR%
used in a constrained array definition and defined by a range, an implicit conversion to the predefined type %RED%SYSTEM%ENDCOLOR%_INTEGER is assumed if the type of %BR%
both bounds (prior to the implicit conversion) is the type universal_integer. Otherwise, the type of the range shall be determined by applying the rules  %BR%
of 12.5 to the range, considered as a complete context, using the rules that the type shall be discrete and that both bounds shall have the same type. %BR%
These rules apply also to a discrete range used in a loop parameter specification (see 10.10) or a generate parameter specification (see 11.8).


---+++ 5.3.2.3 Predefined array types
The predefined array types are STRING, BOOLEAN_VECTOR, BIT_VECTOR, %RED%SYSTEM_INTEGER_VECTOR, INTEGER64_VECTOR,%ENDCOLOR% INTEGER%RED%32%ENDCOLOR%_VECTOR, REAL_VECTOR, and %BR%
TIME_VECTOR, defined in package STANDARD in Clause 16. %RED%For compatibility, the alias INTEGER_VECTOR is declared.%ENDCOLOR%

The values of the predefined type STRING are one-dimensional arrays of the predefined type CHARACTER, indexed by values of the predefined %BR%
subtype POSITIVE%RED%64%ENDCOLOR%:

<pre>
%RED%<del>subtype POSITIVE is INTEGER range 1 to INTEGER'HIGH;</del>%ENDCOLOR%
type STRING is array (POSITIVE%RED%64%ENDCOLOR% range <>) of CHARACTER;
</pre>

The values of the predefined types BOOLEAN_VECTOR, BIT_VECTOR, %RED%SYSTEM_INTEGER_VECTOR, INTEGER64_VECTOR,%ENDCOLOR% INTEGER%RED%32%ENDCOLOR%_VECTOR, REAL_VECTOR, and %BR%
TIME_VECTOR, are one-dimensional arrays of the predefined types BOOLEAN, BIT, %RED%SYSTEM_INTEGER, INTEGER64,%ENDCOLOR% INTEGER%RED%32%ENDCOLOR%, REAL, and TIME, respectively, indexed %BR%
by values of the predefined subtype NATURAL%RED%64%ENDCOLOR%:
<pre>
%RED%<del>subtype NATURAL is INTEGER range 0 to INTEGER'HIGH;</del>%ENDCOLOR%
type BOOLEAN_VECTOR is array (NATURAL%RED%64%ENDCOLOR% range <>) of BOOLEAN;
type BIT_VECTOR is array (NATURAL%RED%64%ENDCOLOR% range <>) of BIT;
%RED%type SYSTEM_INTEGER_VECTOR is array (NATURAL64 range <>) of SYSTEM_INTEGER;%ENDCOLOR%
%RED%type INTEGER64_VECTOR is array (NATURAL64 range <>) of INTEGER64;%ENDCOLOR%
type INTEGER%RED%32%ENDCOLOR%_VECTOR is array (NATURAL%RED%64%ENDCOLOR% range <>) of INTEGER%RED%32%ENDCOLOR%;
type REAL_VECTOR is array (NATURAL%RED%64%ENDCOLOR% range <>) of REAL;
type TIME_VECTOR is array (NATURAL%RED%64%ENDCOLOR% range <>) of TIME;
</pre>

%RED%For compatibility, the following aliases are defined:%ENDCOLOR%

<pre>
%RED%alias INTEGER_VECTOR is INTEGER32_VECTOR;%ENDCOLOR%
</pre>


---+++ 9.2.4 Shift operators
%GREEN%[Editor note: first table]%ENDCOLOR%

| *Operator* | *Operation*                 | *Left operand type*            | *Right operand type*     | *Result type*  |
| sll        | Shift left %BR% logical     | Any one-dimensional array type whose %BR% \
                                             element type is BIT or BOOLEAN | %RED%SYSTEM%ENDCOLOR%_INTEGER | Same as left   |
| srl        | Shift right %BR% logical    | Any one-dimensional array type whose %BR% \
                                             element type is BIT or BOOLEAN | %RED%SYSTEM%ENDCOLOR%_INTEGER | Same as left   |
| sla        | Shift left %BR% arithmetic  | Any one-dimensional array type whose %BR% \
                                             element type is BIT or BOOLEAN | %RED%SYSTEM%ENDCOLOR%_INTEGER | Same as left   |
| sra        | Shift right %BR% arithmetic | Any one-dimensional array type whose %BR% \
                                             element type is BIT or BOOLEAN | %RED%SYSTEM%ENDCOLOR%_INTEGER | Same as left   |
| rol        | Rotate left %BR% logical    | Any one-dimensional array type whose %BR% \
                                             element type is BIT or BOOLEAN | %RED%SYSTEM%ENDCOLOR%_INTEGER | Same as left   |
| ror        | Rotate right %BR% logical   | Any one-dimensional array type whose %BR% \
                                             element type is BIT or BOOLEAN | %RED%SYSTEM%ENDCOLOR%_INTEGER | Same as left   |


---+++ 9.2.7 Multiplying operators
%GREEN%[Editor note: second table]%ENDCOLOR%

| *Operator* | *Operation*    | *Left operand type*      | *Right operand type*     | *Result type*     |
| *          | Multiplication | Any physical type        | %RED%SYSTEM%ENDCOLOR%_INTEGER | Same as left      |
|            |                | Any physical type        | REAL                     | Same as left      |
|            |                | %RED%SYSTEM%ENDCOLOR%_INTEGER | Any physical type        | Same as right     |
|            |                | REAL                     | Any physical type        | Same as right     |
| /          | Division       | Any physical type        | %RED%SYSTEM%ENDCOLOR%_INTEGER | Same as left      |
|            |                | Any physical type        | REAL                     | Same as left      |
|            |                | Any physical type        | The same type            | Universal integer |
| mod        | Modulus        | Any physical type        | Same type                | Same type         |
| rem        | Remainder      | Any physical type        | Same type                | Same type         |


Multiplication of a value P of a physical type T<sub>p</sub> by a value I of type %RED%SYSTEM%ENDCOLOR%_INTEGER is equivalent to the
following computation:

T<sub>p</sub>'Val( Tp'Pos(P) * I )

Multiplication of a value P of a physical type T<sub>p</sub> by a value F of type REAL is equivalent to the following computation:

T<sub>p</sub>'Val( %RED%SYSTEM%ENDCOLOR%_INTEGER( REAL( T<sub>p</sub>'Pos(P) ) * F ))

Division of a value P of a physical type T<sub>p</sub> by a value I of type %RED%SYSTEM%ENDCOLOR%_INTEGER is equivalent to the following
computation:

T<sub>p</sub>'Val( T<sub>p</sub>'Pos(P) / I )

%GREEN%[...]%ENDCOLOR%

The exponentiating operator !** is predefined for each integer type and for each floating-point type. In either case the right operand, %BR%
called the exponent, is of the predefined type %RED%SYSTEM%ENDCOLOR%_INTEGER.

%GREEN%[Editor note: last table]%ENDCOLOR%

| *Operator* | *Operation*    | *Left operand type*     | *Right operand type*     | *Result type* |
| !**        | Exponentiation | Any integer type        | %RED%SYSTEM%ENDCOLOR%_INTEGER | Same as left  |
|            |                | Any floating-point type | %RED%SYSTEM%ENDCOLOR%_INTEGER | Same as left  |


---+++ 16.3 Package STANDARD

<pre>
package STANDARD is
%GREEN%[...]%ENDCOLOR%
  type %RED%SYSTEM%ENDCOLOR%_INTEGER is range implementation_defined;
  -- The predefined operations for this type are as follows:
  -- function "**"(anonymous: universal_integer; anonymous: %RED%SYSTEM%ENDCOLOR%_INTEGER) return universal_integer;
  -- function "**"(anonymous: universal_real; anonymous: %RED%SYSTEM%ENDCOLOR%_INTEGER) return universal_real;
  -- function "="(anonymous, anonymous: %RED%SYSTEM%ENDCOLOR%_INTEGER) return BOOLEAN;
  -- function "/="(anonymous, anonymous: %RED%SYSTEM%ENDCOLOR%_INTEGER) return BOOLEAN;
  -- function "<"(anonymous, anonymous: %RED%SYSTEM%ENDCOLOR%_INTEGER) return BOOLEAN;
  -- function "<="(anonymous, anonymous: %RED%SYSTEM%ENDCOLOR%_INTEGER) return BOOLEAN;
  -- function ">"(anonymous, anonymous: %RED%SYSTEM%ENDCOLOR%_INTEGER) return BOOLEAN;
  -- function ">="(anonymous, anonymous: %RED%SYSTEM%ENDCOLOR%_INTEGER) return BOOLEAN;
  -- function "+"(anonymous: %RED%SYSTEM%ENDCOLOR%_INTEGER) return %RED%SYSTEM%ENDCOLOR%_INTEGER;
  -- function "-"(anonymous: %RED%SYSTEM%ENDCOLOR%_INTEGER) return %RED%SYSTEM%ENDCOLOR%_INTEGER;
  -- function "abs"(anonymous: %RED%SYSTEM%ENDCOLOR%_INTEGER) return %RED%SYSTEM%ENDCOLOR%_INTEGER;
  -- function "+"(anonymous, anonymous: %RED%SYSTEM%ENDCOLOR%_INTEGER) return %RED%SYSTEM%ENDCOLOR%_INTEGER;
  -- function "-"(anonymous, anonymous: %RED%SYSTEM%ENDCOLOR%_INTEGER) return %RED%SYSTEM%ENDCOLOR%_INTEGER;
  -- function "*"(anonymous, anonymous: %RED%SYSTEM%ENDCOLOR%_INTEGER) return %RED%SYSTEM%ENDCOLOR%_INTEGER;
  -- function "/"(anonymous, anonymous: %RED%SYSTEM%ENDCOLOR%_INTEGER) return %RED%SYSTEM%ENDCOLOR%_INTEGER;
  -- function "mod"(anonymous, anonymous: %RED%SYSTEM%ENDCOLOR%_INTEGER) return %RED%SYSTEM%ENDCOLOR%_INTEGER;
  -- function "rem"(anonymous, anonymous: %RED%SYSTEM%ENDCOLOR%_INTEGER) return %RED%SYSTEM%ENDCOLOR%_INTEGER;
  -- function "**"(anonymous: %RED%SYSTEM%ENDCOLOR%_INTEGER; anonymous: %RED%SYSTEM%ENDCOLOR%_INTEGER) return %RED%SYSTEM%ENDCOLOR%_INTEGER;
  -- function MINIMUM (L, R: %RED%SYSTEM%ENDCOLOR%_INTEGER) return %RED%SYSTEM%ENDCOLOR%_INTEGER;
  -- function MAXIMUM (L, R: %RED%SYSTEM%ENDCOLOR%_INTEGER) return %RED%SYSTEM%ENDCOLOR%_INTEGER;
%GREEN%[...]%ENDCOLOR%
  -- Predefined type TIME:
  type TIME is range implementation_defined
    units
      fs;             -- femtosecond
      ps  = 1000 fs;  -- picosecond
      ns  = 1000 ps;  -- nanosecond
      us  = 1000 ns;  -- microsecond
      ms  = 1000 us;  -- millisecond
      sec = 1000 ms;  -- second
      min =   60 sec; -- minute
      hr  =   60 min; -- hour
    end units;
  -- The predefined operations for this type are as follows:
  -- function "="(anonymous, anonymous: TIME) return BOOLEAN;
  -- function "/="(anonymous, anonymous: TIME) return BOOLEAN;
  -- function "<"(anonymous, anonymous: TIME) return BOOLEAN;
  -- function "<="(anonymous, anonymous: TIME) return BOOLEAN;
  -- function ">"(anonymous, anonymous: TIME) return BOOLEAN;
  -- function ">="(anonymous, anonymous: TIME) return BOOLEAN;
  -- function "+"(anonymous: TIME) return TIME;
  -- function "- (anonymous: TIME) return TIME;
  -- function "abs"(anonymous: TIME) return TIME;
  -- function "+"(anonymous, anonymous: TIME) return TIME;
  -- function "-"(anonymous, anonymous: TIME) return TIME;
  -- function "*"(anonymous: TIME; anonymous: %RED%SYSTEM%ENDCOLOR%_INTEGER) return TIME;
  -- function "*"(anonymous: TIME; anonymous: REAL) return TIME;
  -- function "*"(anonymous: %RED%SYSTEM%ENDCOLOR%_INTEGER; anonymous: TIME) return TIME;
  -- function "*"(anonymous: REAL; anonymous: TIME) return TIME;
  -- function "/"(anonymous: TIME; anonymous: %RED%SYSTEM%ENDCOLOR%_INTEGER) return TIME;
  -- function "/"(anonymous: TIME; anonymous: REAL) return TIME;
  -- function "/"(anonymous, anonymous: TIME) return universal_integer;
  -- function "mod"(anonymous, anonymous: TIME) return TIME;
  -- function "rem"(anonymous, anonymous: TIME) return TIME;
  -- function MINIMUM (L, R: TIME) return TIME;
  -- function MAXIMUM (L, R: TIME) return TIME;
%GREEN%[...]%ENDCOLOR%
  -- Predefined numeric subtypes:
  %RED%subtype INTEGER64  is SYSTEM_INTEGER range -2**63 to 2**63-1;%ENDCOLOR%
  %RED%subtype NATURAL64  is SYSTEM_INTEGER range 0 to INTEGER64'HIGH;%ENDCOLOR%
  %RED%subtype POSITIVE64 is SYSTEM_INTEGER range 1 to INTEGER64'HIGH;%ENDCOLOR%
  
  %RED%subtype INTEGER32  is SYSTEM_INTEGER range -2**31 to 2**31-1;%ENDCOLOR%
  subtype NATURAL%RED%32%ENDCOLOR%  is %RED%SYSTEM%ENDCOLOR%_INTEGER range 0 to INTEGER%RED%32%ENDCOLOR%'HIGH;
  subtype POSITIVE%RED%32%ENDCOLOR% is %RED%SYSTEM%ENDCOLOR%_INTEGER range 1 to INTEGER%RED%32%ENDCOLOR%'HIGH;

  %RED%alias INTEGER  is INTEGER32;%ENDCOLOR%
  %RED%alias NATURAL  is NATURAL32;%ENDCOLOR%
  %RED%alias POSITIVE is POSITIVE32;%ENDCOLOR%
%GREEN%[...]%ENDCOLOR%
  -- Predefined array types:
  type STRING is array (POSITIVE%RED%64%ENDCOLOR% range <>) of CHARACTER;
  -- The predefined operations for these types are as follows:
%GREEN%[...]%ENDCOLOR%
 
  type BOOLEAN_VECTOR is array (NATURAL%RED%64%ENDCOLOR% range <>) of BOOLEAN;
  -- The predefined operations for this type are as follows:
%GREEN%[...]%ENDCOLOR%

  type BIT_VECTOR is array (NATURAL%RED%64%ENDCOLOR% range <>) of BIT;
  -- The predefined operations for this type are as follows:
%GREEN%[...]%ENDCOLOR%

  %RED%type SYSTEM_INTEGER_VECTOR is array (NATURAL64 range <>) of SYSTEM_INTEGER;
  -- The predefined operations for this type are as follows:
  -- function "="(anonymous, anonymous: SYSTEM_INTEGER_VECTOR) return BOOLEAN;
  -- function "/="(anonymous, anonymous: SYSTEM_INTEGER_VECTOR) return BOOLEAN;
  -- function "<"(anonymous, anonymous: SYSTEM_INTEGER_VECTOR) return BOOLEAN;
  -- function "<="(anonymous, anonymous: SYSTEM_INTEGER_VECTOR) return BOOLEAN;
  -- function ">"(anonymous, anonymous: SYSTEM_INTEGER_VECTOR) return BOOLEAN;
  -- function ">="(anonymous, anonymous: SYSTEM_INTEGER_VECTOR) return BOOLEAN;
  -- function "&"(anonymous: SYSTEM_INTEGER_VECTOR; anonymous: SYSTEM_INTEGER_VECTOR) return SYSTEM_INTEGER_VECTOR;
  -- function "&"(anonymous: SYSTEM_INTEGER_VECTOR; anonymous: SYSTEM_INTEGER) return SYSTEM_INTEGER_VECTOR;
  -- function "&"(anonymous: SYSTEM_INTEGER; anonymous: SYSTEM_INTEGER_VECTOR) return SYSTEM_INTEGER_VECTOR;
  -- function "&"(anonymous: SYSTEM_INTEGER; anonymous: SYSTEM_INTEGER) return SYSTEM_INTEGER_VECTOR;
  -- function MINIMUM (L, R: SYSTEM_INTEGER_VECTOR) return SYSTEM_INTEGER_VECTOR;
  -- function MAXIMUM (L, R: SYSTEM_INTEGER_VECTOR) return SYSTEM_INTEGER_VECTOR;
  -- function MINIMUM (L: SYSTEM_INTEGER_VECTOR) return SYSTEM_INTEGER;
  -- function MAXIMUM (L: SYSTEM_INTEGER_VECTOR) return SYSTEM_INTEGER;%ENDCOLOR%
 
  %RED%type INTEGER64_VECTOR is array (NATURAL64 range <>) of INTEGER64;
  -- The predefined operations for this type are as follows:
  -- function "="(anonymous, anonymous: INTEGER64_VECTOR) return BOOLEAN;
  -- function "/="(anonymous, anonymous: INTEGER64_VECTOR) return BOOLEAN;
  -- function "<"(anonymous, anonymous: INTEGER64_VECTOR) return BOOLEAN;
  -- function "<="(anonymous, anonymous: INTEGER64_VECTOR) return BOOLEAN;
  -- function ">"(anonymous, anonymous: INTEGER64_VECTOR) return BOOLEAN;
  -- function ">="(anonymous, anonymous: INTEGER64_VECTOR) return BOOLEAN;
  -- function "&"(anonymous: INTEGER64_VECTOR; anonymous: INTEGER64_VECTOR) return INTEGER64_VECTOR;
  -- function "&"(anonymous: INTEGER64_VECTOR; anonymous: INTEGER64) return INTEGER64_VECTOR;
  -- function "&"(anonymous: INTEGER64; anonymous: INTEGER64_VECTOR) return INTEGER64_VECTOR;
  -- function "&"(anonymous: INTEGER64; anonymous: INTEGER64) return INTEGER64_VECTOR;
  -- function MINIMUM (L, R: INTEGER64_VECTOR) return INTEGER64_VECTOR;
  -- function MAXIMUM (L, R: INTEGER64_VECTOR) return INTEGER64_VECTOR;
  -- function MINIMUM (L: INTEGER64_VECTOR) return INTEGER64;
  -- function MAXIMUM (L: INTEGER64_VECTOR) return INTEGER64;%ENDCOLOR%
 
  type INTEGER%RED%32%ENDCOLOR%_VECTOR is array (NATURAL%RED%64%ENDCOLOR% range <>) of INTEGER%RED%32%ENDCOLOR%;
  -- The predefined operations for this type are as follows:
  -- function "="(anonymous, anonymous: INTEGER%RED%32%ENDCOLOR%_VECTOR) return BOOLEAN;
  -- function "/="(anonymous, anonymous: INTEGER%RED%32%ENDCOLOR%_VECTOR) return BOOLEAN;
  -- function "<"(anonymous, anonymous: INTEGER%RED%32%ENDCOLOR%_VECTOR) return BOOLEAN;
  -- function "<="(anonymous, anonymous: INTEGER%RED%32%ENDCOLOR%_VECTOR) return BOOLEAN;
  -- function ">"(anonymous, anonymous: INTEGER%RED%32%ENDCOLOR%_VECTOR) return BOOLEAN;
  -- function ">="(anonymous, anonymous: INTEGER%RED%32%ENDCOLOR%_VECTOR) return BOOLEAN;
  -- function "&"(anonymous: INTEGER%RED%32%ENDCOLOR%_VECTOR; anonymous: INTEGER%RED%32%ENDCOLOR%_VECTOR) return INTEGER%RED%32%ENDCOLOR%_VECTOR;
  -- function "&"(anonymous: INTEGER%RED%32%ENDCOLOR%_VECTOR; anonymous: INTEGER%RED%32%ENDCOLOR%) return INTEGER%RED%32%ENDCOLOR%_VECTOR;
  -- function "&"(anonymous: INTEGER%RED%32%ENDCOLOR%; anonymous: INTEGER%RED%32%ENDCOLOR%_VECTOR) return INTEGER%RED%32%ENDCOLOR%_VECTOR;
  -- function "&"(anonymous: INTEGER%RED%32%ENDCOLOR%; anonymous: INTEGER%RED%32%ENDCOLOR%) return INTEGER%RED%32%ENDCOLOR%_VECTOR;
  -- function MINIMUM (L, R: INTEGER%RED%32%ENDCOLOR%_VECTOR) return INTEGER%RED%32%ENDCOLOR%_VECTOR;
  -- function MAXIMUM (L, R: INTEGER%RED%32%ENDCOLOR%_VECTOR) return INTEGER%RED%32%ENDCOLOR%_VECTOR;
  -- function MINIMUM (L: INTEGER%RED%32%ENDCOLOR%_VECTOR) return INTEGER%RED%32%ENDCOLOR%;
  -- function MAXIMUM (L: INTEGER%RED%32%ENDCOLOR%_VECTOR) return INTEGER%RED%32%ENDCOLOR%;%ENDCOLOR%

  %RED%alias INTEGER_VECTOR is INTEGER32_VECTOR;%ENDCOLOR%
%GREEN%[...]%ENDCOLOR%
 
  type REAL_VECTOR is array (NATURAL%RED%64%ENDCOLOR% range <>) of REAL;
  -- The predefined operations for this type are as follows:
%GREEN%[...]%ENDCOLOR%
  
  type TIME_VECTOR is array (NATURAL%RED%64%ENDCOLOR% range <>) of TIME;
  -- The predefined operations for this type are as follows:
%GREEN%[...]%ENDCOLOR%

  -- Predefined TO_STRING operations on scalar types
  -- function TO_STRING (VALUE: BOOLEAN) return STRING;
  -- function TO_STRING (VALUE: BIT) return STRING;
  -- function TO_STRING (VALUE: CHARACTER) return STRING;
  -- function TO_STRING (VALUE: SEVERITY_LEVEL) return STRING;
  -- function TO_STRING (VALUE: universal_integer) return STRING;
  -- function TO_STRING (VALUE: universal_real) return STRING;
  -- function TO_STRING (VALUE: %RED%SYSTEM_%ENDCOLOR%INTEGER) return STRING;
  -- function TO_STRING (VALUE: REAL) return STRING;
  -- function TO_STRING (VALUE: TIME) return STRING;
  -- function TO_STRING (VALUE: FILE_OPEN_KIND) return STRING;
  -- function TO_STRING (VALUE: FILE_OPEN_STATUS) return STRING;
  -- Predefined overloaded TO_STRING operations
  -- function TO_STRING (VALUE: REAL; DIGITS: NATURAL%RED%64%ENDCOLOR%) return STRING;
  -- function TO_STRING (VALUE: REAL; FORMAT: STRING) return STRING;
  -- function TO_STRING (VALUE: TIME; UNIT: TIME) return STRING;
</pre>


---+++ Annex D (Potentially nonportable constructs)
The use of the following constructs may lead to nonportable VHDL descriptions:
   * icon:line_lr Resolution functions that do not treat all inputs symmetrically
   * icon:line_lr The comparison of floating-point values
   * icon:line_lr Events on floating-point-valued signals
   * icon:line_lr The use of explicit type conversion to convert floating-point values to integer values
   * icon:line_lr Any value that does not fall within the minimum guaranteed range for the type
   * icon:line_lr The use of architectures and subprogram bodies implemented via the foreign language interface (the 'FOREIGN attribute)
   * icon:line_lr Processes that communicate via file I/O, including TEXTIO
   * icon:line_lr Impure functions
   * icon:line_lr Linkage ports
   * icon:line_lr Ports and generics in the root of a design hierarchy
   * icon:line_lr Use of a time resolution greater than 1 fs
   * icon:line_lr Shared variables
   * icon:line_lr Procedure calls passing a single object of an array or record type to multiple formals where at least one of the formals is of mode out or inout
   * icon:line_lr Models that depend on a particular format of T'IMAGE
   * icon:line_lr %RED%<del>Declarations of integer or physical types that have a secondary unit whose position number is outside of the range -(2**31-1) to 2**31-1</del>%ENDCOLOR%
   * icon:line_lr The predefined attributes 'INSTANCE_NAME or 'PATH_NAME, if the behavior of the model is dependent on the values returned by the attributes
   * icon:line_lr Use of a conversion specifier F, a, or A in the value for the FORMAT parameter of a call to the predefined function TO_STRING

---++ Comments
Most of the objections to LCS-2016-026 have to do with the '512 bits' and a smaller number grousing over the lack of providing any
subtype that map back to VHDL-87 integers.  In that vein, changing LCS 26 to '64 bits' would fairly simply address the majority of
the concerns.  If that is acceptable then it provides precedence down the road for a similarly minor edit when 128 bit integer math
becomes the norm and there is pressure to expand integers yet again.

In addition to 64 bits, LCS 26a addresses the perceived need for a 32 bit integer subtype, but does so by making a lot more edits
and would be harder to scale that to the next larger size.  Now that there would be INTEGER and LONG_INTEGER, what comes next?
REALLY_LONG_INTEGER when VHDL gets to 128 bit integers?  REALLY_REALLY_LONG_INTEGER when VHDL gets to 256 bits?

The current LRM provides no guarantee about the maximum integer size so there is no fundamental requirement to provide a 32 bit
integer subtype and create LONG_INTEGER type.  That is only a perceived need (that might also be accurate).

I'm not trying to lobby here for or against LCS 26 versus LCS 26a, just providing a discussion topic for comparing the two LCS
on some future Thursday call.  

-- %BUBBLESIG{KevinJennings - 2017-01-11}%


I was also thinking about other names like =IMPL_INTEGER= for implementation integer, =UNI_INTEGER= or =VHDL_INTEGER= ... Such an
integer could grow in each revision.

Personally, I wouldn't be so friendly with the EDA industry (vendor and users). If they rely on false code, then they might get
broken code when using a new VHDL revision. But language designers are still willing to satisfy their audience at every cost.

Creating a subtype INTEGER, catches every design which falsely relies on fixed 32-bit integers, by using e.g. ='LEFT= or hoping
for overflow arithmetic in the tool.

@Kevin
If you really want to make 512 bit or even more possible, then we need a "derived types LCS" and especially derived integers.
I don't know if I have enough time to write such a big text, because I still need to write the Spaceship LCS ...

-- %BUBBLESIG{PatrickLehmann - 2017-01-11}%


*PL:* Creating a subtype INTEGER, catches every design which falsely relies on fixed 32-bit integers, by using e.g. 'LEFT or hoping
for overflow arithmetic in the tool. 

*MZ:* The new INTEGER (backed up by a &#62;= 64-bit implementation) will not overflow as the old INTEGER which is often backed-up
by a 32-bit implementation. An out-of-bounds exception should be happen now.

Having a subtype INTEGER with range -2**31 to 2**31-1 only catches designs which falsely rely on the values of INTEGER'LEFT, 'RIGHT,
and so on.

Another (major) benefit of a such a subtype INTEGER is that the simulator can (!)  keep the memory footprint the same for existing
designs and finally also the simulation performance.

-- %BUBBLESIG{MartinZabel - 2017-01-12}%


*MZ:* Another (major) benefit of a such a subtype INTEGER is that the simulator can (!) keep the memory footprint the same for
existing designs and finally also the simulation performance

*KJ:* Doesn't that assumes that all intermediate calculations do not overflow 64 bit?  When I went looking, I didn't see anything
specifying what to do if an intermediate calculation overflows so an implementation today might use 64 bit operations (or at least
something larger than 32 bits) in order to try to guarantee correct 32 bit results.  If they now have to guarantee correct 64 bit
results and they applied a similar strategy then 64 bit low level operations wouldn't cut it. Either that or it assumes that the
operations to use are determined based on the subtype ranges.

-- %BUBBLESIG{KevinJennings - 2017-01-12}%


*KJ:* When I went looking, I didn't see anything specifying what to do if an intermediate calculation overflows so an implementation
today might use 64 bit operations (or at least something larger than 32 bits) in order to try to guarantee correct 32 bit results.

*MZ*: My interpretation of the LRM is: one has to use an arbitrary precision during calculation of an integer expression, and then
check the range during assignment. This cannot be even achieved by using a 64-bit arithmetic for a 32-bit INTEGER type as you already
demonstrated by your exponentiation example in the e-mail discussion between you and Tristan. Another example is =n*n*n/n/n=
where n is INTEGER'high.

Unfortunately the current situation is even worse: I have tested 4 simulators: G, M, I, X. Given a variable =n= of type INTEGER,
all of them use 32-bit modulo arithmetic for the expression =n := n+1=, thus the result is -2**31 (negative!) if =n= was 2**31-1.
Only I and X detect the overflow if it is visible from static elaboration. When requesting 64-bit for universal integer, the
intermediate result would be 2**31 (positive) and the range check during the assignment to the INTEGER =n= will fail as expected.
Nevertheless, the simulator can still use only 4 bytes to store =n= in memory, thus the memory footprint for the current state of
the model will not grow.

Addendum: I do not expect that simulators will ever use arbitrary precision for integer expressions. I think, if the vendors are
lazy then they will use 64-bit arithmetic and 8 byte storage for any integer type. If they optimize a bit, then they will use 64-bit
for arithmetic and 8 byte storage for LONG_INTEGER, but only 4 byte storage for INTEGER. Having a small memory footprint (cache
utilization) is important for simulation speed.

-- %BUBBLESIG{MartinZabel - 2017-01-12}%


After the renaming to INTEGER64, one might intuitively expect that the size is exactly 64 bits as is the case for the int64_t in C
or C++ for example. 

Thus, I would argue to change Section 5.2.3.2 so that INTEGER64 is defined as *exactly* the range -2**63 to 2**63-1.

-- %BUBBLESIG{MartinZabel - 2017-01-13}%


No technical objections. However, I do not like the approach of fuzzing things up and introduce =(INTEGER|NATURAL|POSITIVE)(32|64)=
or whatever. Couldn't we just require implementors of the new language revision to have =INTEGER= support, at least, the range
of signed 64-bit values: no new types, only new bounds.

-- %BUBBLESIG{ThomasPreusser - 2017-01-13}%


What is the impact if we alias INTEGER to INTEGER64 instead of INTEGER32, and do the same for the other 64-bit types?

-- %BUBBLESIG{DanielKho - 2017-01-19}%


I am fine with having INTEGER64 and INTEGER32, with INTEGER aliasing to either of these. In future revisions, INTEGER could alias
UNIVERSAL_INTEGER which could be a more generic and complete implementation of the integer type.

-- %BUBBLESIG{DanielKho - 2017-01-19}%


@Danielkho: If we alias INTEGER to INTEGER64 instead of INTEGER32, then the memory footprint will increase because now each INTEGER
has to be stored in 8 bytes instead of 4 bytes. Having a small memory footprint (cache utilization) is important for simulation speed.

The intention of Patrick was to "catch every design which falsely relies on fixed 32-bit integers, by using e.g. 'LEFT", see
his comment dated from 2017-01-11.

-- %BUBBLESIG{MartinZabel - 2017-01-21}%




I feel that no code should exist that relies on the range of VHDL&#39;s INTEGER type being exactly -2**31 to 2**31+1. Wherever this was needed, the user could have declareded, e.g., &#34;type integer_32 is integer range -2**31 to 2**31-1&#34;. Users who failed to handle this properly can make the correction going forward.

VHDL users have always known that the range of integer could be more than 32 bits. In some ways it is surprising that no vendor has supported 64 bits (or at least, say, -2**31 to 2**32-1) for a competitive advantage.

-- %BUBBLESIG{FarrellOstler - 2017-01-31}%

*RG:* New types will require explicit typecasts all over the place. %BR%
*PL: I think you mean LCS 026b not this (LCS 026a).

-- %BUBBLESIG{PatrickLehmann - 2017-03-04}%

%COMMENT%
</sticky>
</noautolink>
Topic revision: r1 - 2020-02-17 - 15:34:41 - TWikiGuest
P1076