LCS History for Extended Ranges / Operations on Ranges

Voting Results:

1. Lieven Lemiengre - 2017-03-09 - ver 5
2. Patrick Lehmann - 2017-03-21 - ver 7
3. Rob Gaddi - 2017-03-23 - ver 7
4. Jim Lewis - 2017-03-23 - ver 7

No:

Abstain:

1. Martin Zabel - 2017-02-25 - ver 4 - Can't tell whether the removal of item e) in clause 9.4.2 is okay or not.
2. Martin Thompson - 2017-03-08 - abstain, insufficient time to review properly

Revisions

• Implement ranges as an implicitly pre-defined record type
• Make that record type and it's instances available through attributes
• Allow range records to be used where ranges can be used.

Version 2: 21-Feb-2017

• Changes LowerBound/UpperBound to LeftBound/RightBound
• Found a place for the simple range and range expression evaluation
• Strike out a staticness restriction:
  • Currently only pre-defined operators and operators defined in STD.* and IEEE.* are static, whereas operators in defined in user code are not static.

Version 3: 21-Feb-2017

• Fixed EBNF

Version 4: 22-Feb-2017

• Adjusted this LCS to the Reflection API => TopLCS2016_041
  Renamed the bounds again to Left and Right as used by the reflection API's mirror types.

Version 5: 07-Mar-2017

• Made attributes secondary attributes.
  "P'RANGE_RECORD" becomes "P'RANGE'RECORD" and
  "P'RANGE_VALUE" becomes "P'RANGE'VALUE".
• Decreased the number of needed attributes, because secondary attributes allow a higher degree of reuse.

Version 6: 14-Mar-2017

• Fixed my misunderstanding of 9.4.3. These sentence must exist, but the list of packages shouldn't be restricted.
  This sentence also excluded operators define e.g. in an architecture or process to be locally static.

Version 7: 21-Mar-2017

• Moved type check from elaboration to analysis
• Moved 9.4.3.2 to a separate LCS

Comments

Draft

-- Thomas Preusser - 2017-02-10

I know, this is still a draft. Thus take the following as hints for further updates.

1) I have fixed the modifications for clause 5.2.2.2 to make clear that DIRECTION is a new predefined enumeration type.

2) The type DIRECTION is not needed, BOOLEAN can be used instead. Also the attribute ASCENDING of array objects and types returns a boolean. Thus the record should have a field Ascending : BOOLEAN instead of Direction.

3) The type of an expression depends only upon the types of its operands and on the operators applied, see clause 9.1, bottom of page 117. Thus, please remove the blue words "result" in the modifications for 8.5.

4) If you store 'LOW and 'HIGH in the record, then the direction will be always ascending. I think what you want instead is 'LEFT in LeftBound and 'RIGHT in RightBound.

5) Within 8.5, this sentence is wrong: _The slice is a null slice if the discrete range is a null range or if the distance between LowerBound and UpperBound (based on position numbers) is less or equal zero._

If LowerBounds / LeftBound equals UpperBound / RightBound then the slice has a length of 1. The definition should be also more explicit and maybe written as a bulleted list:

The slice is a null slice:

• • if the discrete range is a null range, or
  • if Ascending is true and LeftBound is greater than RightBound, or
  • if Ascending is false and LeftBound is less than RightBound.

This definition is based on the fixes from points 2) and 4) above. See also definition of null range on bottom of page 36.

6) A slice name denotes a one-dimensional array composed of a sequence of consecutive elements of another one-dimensional array, see clause 8.5. So what is the purpose of the additional attributes defined in 16.2.2?

7) A slice has always a discrete range because an index constraint shall provide a discrete range for each index of the array type, see 5.3.2.2. That's why only discrete ranges are allowed for slice names, see 8.5. Thus, range records for real and universal_real have no use.

-- Martin Zabel - 2017-02-17

TBP: Are use cases so widespread that we should ask tool vendors to provide such records for you?

PL: This feature is not for me. But yes, I developed major ideas behind it, I implemented a range arithmetic package and I fully support the proposal. The proposal was ranked and not moved to "Some day maybe". The first ideas to support an arithmetic on ranges is from Stewart Cobb planned for VHDL-93. Use cases are linked in the LCS header as in any other LCS.

-- Patrick Lehmann - 2017-02-20

MZ: 1)
PL: Thanks.

MZ: 2) The type DIRECTION is not needed, BOOLEAN can be used instead.
PL: The using a BOOLEAN is against the ideas of VHDL/Ada and also against strong typing. We have the ability to define 2 distinct integer types so both cannot be mixed up. The LRM does it itself e.g. for SIDE. Even BOOLEAN itself could be represented by BIT. Both are predefined enumerations of just two values. So I prefer a DIRECTION enumeration matching the corresponding EBNF rule.

MZ: 3)
PL: Doesn't apply anymore.

MZ: 4) If you store 'LOW and 'HIGH in the record, then the direction will be always ascending.
PL: That's not true. 'LEFT=/='RIGHT and 'LOW=/='HIGH are orthogonal values, convertible by 'ASCENDING. (See 16.2.2 - Note 1).
But the main reason is that arithmetic with LowerBound and UpperBound requires less conditions based on Direction.

MZ: 5)
PL: Doesn't apply anymore.

MZ: 6) So what is the purpose of the additional attributes defined in 16.2.2?
PL: The user needs an API to access the internal representation of a range of a scalar subtype. The result is a range record.

MZ: 7)
PL: First part doesn't apply anymore.
MZ: Thus, range records for real and universal_real have no use.
PL: Ranges can be used in more places than only in places where discrete_range is allowed. Ranges can be passed via generic or parameter maps. Timespans can now be described as:

alias TIME_SPAN is TIME'RANGE_RECORD;

constant MyTimeSpan : TIME_SPAN := (5 ns, 10 ns, ASCENDING);

A future version could allow this:

constant MyTimeSpan : TIME_SPAN := TIME'(5 ns to 10 ns);

-- Patrick Lehmann - 2017-02-20

Version 1

-- Lieven Lemiengre - 2017-02-20

PL: Use cases are linked in the LCS header as in any other LCS.

TBP: I am sorry but although the proposal Extended Ranges is linked, I would not at all read it as a use case for this LCS. The proposal is asking for operations on ranges. However, the central invention of this LCS is this range record, which is, indeed, used by the proposal for illustrating the backing implementation-specific data structure but is not actually asked for in an implementation. Such a range record could be helpful for implementing a library workaround for a missing language feature but this is all it is. And by itself, it really is just a shorthand for querying three attributes in a single step. It does not provide any of the desired range operations. I do not think that it would be a good idea to establish this workaround in the standard because this will block the future thorough adoption of the proposal by the virtue of compatibility issues.

-- Thomas Preusser - 2017-02-20

TBP: And by itself, it really is just a shorthand for querying three attributes in a single step.
PL: Yes and no. Yes you could query all three members by hand, what gives you a lot of code. Then you could implement arithmetic on user defined records, but no comes the missing part: You can't use such a user define record in e.g. a generate statement as a locally static discrete range.

TBP: It does not provide any of the desired range operations.
PL: VHDL is going away from the out-dated principle that a languages should define the complete language library. That is thinking of the 80s. We are now providing a basic functionality that allows user to develop further features based on such basic functionality like range records.

TBP: ... because this will block the future thorough adoption of the proposal ...
PL: We had long discussions in meetings and on the IEEE reflector as we discussed how to incorporate ranges as a first class objects as required by the original proposal. That was also my own first thought of how to implement it. But the analysis showed that subtypes and ranges can not be divided into two VHDL constructs. You would endup in defining operators and expressions for subtypes. I think we shouldn't go that route.

So feel free to do the same basic analysis of ranges as a first class object and how to meet all the design goals or see our long discussions on the reflector.

-- Patrick Lehmann - 2017-02-20

Version 4

MZ: Can't tell whether the removal of item e) in clause 9.4.2 is okay or not.
PL: According to Tristan, locally static expressions are needed in choices (e.g. case statements). He further states that GHDL doesn't enforce that rule.

-- Patrick Lehmann - 2017-03-07

Version 7