LCS2016_072b_History < P1076

P1076 Web>VHDL2017>LCS2016_072b>LCS2016_072b_History (2017-07-22, JimLewis) (raw view)EditAttach
---+ Language Change Specification for Function Knows Vector Size

---++ 

 | <sticky><b>LCS Number:</b></sticky> | LCS-2016-072b History |
 | <sticky><b>Version:</b>   </sticky> | 18  |
 | <sticky><b>Date:</b>      </sticky> | 23-Mar-2017  |
 | <sticky><b>Status:</b>    </sticky> | Voting |
 | <sticky><b>Authors:</b>    </sticky> | Kevin Jennings, Martin Zabel, Jim Lewis, and Patrick Lehmann |
 | <sticky><b>Source Doc:</b></sticky> | [[FunctionKnowsVectorSize][FunctionKnowsVectorSize]] |
 | <sticky><b>Derived from and conflicts with:</b></sticky> | [[TopLCS2016_072][LCS_2016_072]] |

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

Yes:
   1 %USERSIG{KevinJennings - 2017-3-22}% - Ver 17
   1 <span data-mce-mark="1">%USERSIG{ThomasPreusser - 2016-11-21}%</span> - ver 10
   1 <span data-mce-mark="1">%USERSIG{MortenZilmer - 2016-12-11}%</span>
   1 <span data-mce-mark="1">%USERSIG{MartinThompson - 2016-12-12}%</span>
   1 %USERSIG{JimLewis - 2017-03-23}%. Version 18 
   1 <span data-mce-mark="1">%USERSIG{PatrickLehmann - 2017-03-20}%</span> - ver 14
   1 %USERSIG{ SteveGrout - 2017-03-20}% - ver 14
   1 %USERSIG{RobGaddi - 2017-03-22}% - ver 17

No:
   1 
   1 

Abstain:
   1 %USERSIG{BrentHahoe - 2017-02-16}% Version 9 - Abstain due to lack of personal time for review.
   1 %USERSIG{RyanHinton - 2016-12-21}% lack of time

---++ Revision History
Revision 18  23-Mar-2017
   * Updated purity definition in 4.1 to include return identifier as a parameter
   
 Revision 17 22-Mar-2017
   * Removed requirement for pure.
   * Note that if the return_identifier is used to provide array constraints or determine the value, the function is impure.
   * However, no error clause is needed here as it is already a part of the definition of pure and impure. 
   
Revision 16  21-Mar-2017
   * Changed : to of per comments from Patrick and Rob
   * Update for new Ernst's comments
   
Revision 15  21-Mar-2017
   * Update for Ernst's comments
   * Changed : to of per comments from Patrick and Rob
   
Revision 14:  19-Mar-2017
   * This is entirely derived from LCS_2016_72 written by Kevin Jennings and Martin Zabel
   * It only differs by the text of the added paragraph on page 20 to address issues

Revision 13:  Kevin and Martin's work

---++ Style Notes
<noautolink><sticky>
Changes are shown in %RED%red font%ENDCOLOR%.  
Deletions are %RED%<del>crossed out</del>%ENDCOLOR%. 
Editing notes in %GREEN%green font%ENDCOLOR%. 
 




---++ Comments 



I like the approach of an implicit subtype declaration. However, I find that certain aspects still should be clarified. For example, the return identifier is not an implicit subtype declaration, but it causes one to be generated. The definition should be constructive for this subtype declaration. Also, this definition fits better after the second paragraph on p.20 because that second paragraph defines general terminology. How about:

%RED%If the return identifier is present in a function specification, the corresponding function is said to be a _spying function_. The subprogram declarative part of a spying function is preceded by an implicit subtype declaration declaring a subtype whose name is the return identifier. The properties of the subtype shall be determined from the immediate context of a function call, as follows:%ENDCOLOR%

%RED%a) If the function call is the expression defining the initial value of a constant or variable object, the subtype denoted by the return identifier is the subtype of the corresponding object declaration.%ENDCOLOR%

%RED%b) If the function call is the expression defining the default values of signals in a signal declaration, the subtype denoted by the return identifier is the subtype of the signal declaration.%ENDCOLOR%

%RED%c) If the function call is the value expression in an assignment statement whose target is not an aggregate, the subtype denoted by the return identifier is the subtype of the target of the assignment statement.%ENDCOLOR%

%RED%d) If the function call is the actual in an association element, the subtype denoted by the return identifier is the subtype of the corresponding formal.%ENDCOLOR%

%RED%e) If the function call is the formal in an association element, the subtype denoted by the return identifier is the subtype of the corresponding actual. It is an error if in this case the actual is itself a function call calling a spying function.%ENDCOLOR%

%RED%f) If the function call is the operand in a qualified expression, the subtype denoted by the return identifier is the subtype defined by the type mark of the qualified expression.%ENDCOLOR%

%RED%It is an error if a spying function is called in any other context. It is also an error if the subtype denoted by the return identifier is an unconstrained or a partially constrained composite subtype.%ENDCOLOR%

-- %BUBBLESIG{ErnstChristen - 2017-03-21}%

---+++ Version 15


Thanks for the review Ernst.
I would have preferred to use yours directly, but I modified it slightly.

First paragraph is different.   A function that has a return identifier but either does not use the return identifier, or only uses it to access non-subtype stuff (such as &#39;SIMPLE_NAME) is not a spying function.

I merged items a and b.   I looked through the LRM section on constants, variables and signals.   The term initial value is not defined in variable declarations.    They all have an expression that follows the assignment symbol &#34;:=&#34;, in fact this is how it is referenced in the constant declaration section.

I used c, d,  f directly (other than renumbering) and added a then (as the LRM has so many places that this would help me read it).

On e, I dropped the error condition because an actual could be an expression for which we can not determine the constraints.   Likewise, a type qualifier can also be a partially constrained composite.   Both of these are covered already by making it an error if the subtype of the return identifier is  an unconstrained or partially constrained subtype.

For the final error checks, I allow the subtype of the return identifier to have missing constraints provided they are not accessed.  Is this too hard for the compiler to detect, I could change to make it an error if the subtype of the return identifier is either an unconstrained or partially composite subtype. 


-- %BUBBLESIG{JimLewis - 2017-03-21}%


Jim --

If the return identifier is going to be a type rather than an object, I like the new change to &#34;tgt of subtype&#34; rather than the colon, it definitely cleans up a point of possible confusion.  Can you explain why the function can&#39;t be pure?  Since functions are pure by default, doesn&#39;t that force an explicit impure qualifier.

One of the things that drove me to write 071c was thinking about that return identifier as just another function parameter.  I still like that one better, I think it is less novel than this.  But even in this case, you can consider the type of the return to be a parameter to the function.  I think that mental model removes the restriction that the function be impure.  I&#39;d certainly hate to have to claim that &#34;TO_UNSIGNED(x) return ret of UNSIGNED&#34; was impure.

-- %BUBBLESIG{RobGaddi - 2017-03-22}%

<pre>
constant w_uv8 : unsigned(7 downto 0)   := to_unsigned(15);
constant x_uv10 : unsigned(9 downto 0) := to_unsigned(15);

signal y_uv8 : unsigned(7 downto 0) := w_uv8 ;
--! signal z_uv10 : unsigned(9 downto 0) := w_uv8 ; -- error
constant x_uv10 : unsigned(9 downto 0) := to_unsigned(15);
</pre>

A pure function returns the same value every time it is called.  
Since to_unsigned(15) can return a different subtype for each
call, to_unsigned[integer] is an impure function.   

OTOH, I suppose if the return value is a scalar or an already
sized return value, then it need not be impure.

OTOH, if the return_identifier is used to provide array constraints or 
determine the value, the function is impure.   However, I do not
need to make that observation here as it is already a part of the 
definition of pure and impure.

-- %BUBBLESIG{JimLewis - 2017-03-22}%


A pure function&#39;s result depend only upon its interface elements.  The return context is an explicit part of the interface when functions are declared this way.   The function is pure when you consider both the target subtype and the input argument.

constant w_uv8 : unsigned(7 downto 0) := to_unsigned(15);
constant w_uv8_2 : unsigned(7 downto 0) := to_unsigned(15);

These two will always result in the same value regardless of simulator or external state.

-- %BUBBLESIG{KarlEisenhofer - 2017-03-23}%
%COMMENT%</sticky>

<span data-mce-mark="1"></noautolink></span>
Topic revision: r1 - 2017-07-22 - 17:37:26 - JimLewis
P1076