Language Change Specification for Function Knows Vector Size

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:

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:

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.

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.

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.

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.

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.

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.

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.

-- Ernst Christen - 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 '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 ":=", 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.

-- Jim Lewis - 2017-03-21

Jim --

If the return identifier is going to be a type rather than an object, I like the new change to "tgt of subtype" rather than the colon, it definitely cleans up a point of possible confusion. Can you explain why the function can't be pure? Since functions are pure by default, doesn'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'd certainly hate to have to claim that "TO_UNSIGNED(x) return ret of UNSIGNED" was impure.

-- Rob Gaddi - 2017-03-22

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);

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.

-- Jim Lewis - 2017-03-22

A pure function'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.

-- Karl Eisenhofer - 2017-03-23