Re: [vhdl-200x-ft] FT22, static aggregates and composite expression has been updated

Peter has pointed out that the new FT-22 was missing a discussion on
the definition of locally static subtypes.  I've added this into the
proposal and have reposted it.

Regards,
   John

Peter Ashenden wrote:
> John,
> 
> Your new version of the proposal has removed the proposed changes to item
> (b) and to the rules for locally static array subtypes.  Is there are
> reason?
> 
> Cheers,
> 
> PA
> 
> --
> Dr. Peter J. Ashenden                        peter@ashenden.com.au
> Ashenden Designs Pty. Ltd.                   www.ashenden.com.au
> PO Box 640                                   Ph:  +61 8 8339 7532
> Stirling, SA 5152                            Fax: +61 8 8339 2616
> Australia                                    Mobile: +61 414 70 9106
> 
> 
> 
>>-----Original Message-----
>>From: owner-vhdl-200x-ft@eda.org 
>>[mailto:owner-vhdl-200x-ft@eda.org] On Behalf Of John Ries
>>Sent: Saturday, 12 March 2005 04:51
>>To: vhdl-200x-ft@eda.org
>>Subject: [vhdl-200x-ft] FT22, static aggregates and composite 
>>expression has been updated
>>
>>
>>FT22 has been updated to reflect the use of aggregates as 
>>choices for case statements and how the effect the value of 
>>the aggregate.
>>-- 
>>-- mailto: johnr@model.com     phone: (503)685-0864
>>--   http://www.model.com        fax: (503)685-0921
>>--
>>
>>
> 
> 


-- 
-- mailto: johnr@model.com     phone: (503)685-0864
--   http://www.model.com        fax: (503)685-0921
--


IEEE 200X Fast Track Change Proposal

ID:	  FT-22

Proposer:     John Ries
email:        johnr@model.com

Status:       Open
Proposed:     04/20/04
 Modified:    03/14/05
Analyzed:     Date
Resolved:     Date

Enhancement Summary:  Allow aggregates, array operands, and array operators
to be locally static.   
Related issues:          
Relevant LRM section:    7.4.1

Enhancement Detail:
----------------------------

Currently the only locally static non-scalars are bit string literals
and string literals.  As a result aggregates, concatenation, slices,
or functions returning composites cannot be used in places that
require locally static expression such as choices for cases.

This enhancement is to modify the statement

  "An expression is said to be locally static if and only if every
  operator in the expression denotes an implicitly defined operator
  whose operands and result are scalar and if every primary in the
  expression is a locally static primary, where locally static primary
  is defined to be one of the following:"

To

  "An expression is said to be locally static if and only if every
  operator in the expression denotes an implicitly defined operator
  and if every primary in the expression is a locally static primary,
  where locally static primary is defined to be one of the following:"

Addition items defining a locally static primary would be added

  "k) An array aggregate, if and only if

      1) All expression in its element associations are locally static
         expressions, and 
      2) All ranges in its element associations are locally static 
         ranges
      3) The aggregate subtype is locally static.

   l) A record aggregate, if and only if all expressions in its
      element associations are locally static expressions and the
      subtype is locally stati

   m) A subelement or a slice of a locally static primary, provided
      that any index expressions are locally static expressions and any
      discrete ranges used in slice names are locally static discrete
      ranges

A locally static range is either a range of the second form (see 3.1) whose
bounds are locally static expressions, or a range of the first form whose prefix 
denotes either a locally static subtype or and object that is of a locally static 
subtype. A locally static range constraint is a range constraint whose range is
locally static.

   n) A selected name, whose prefix denotes a locally static primary."

If the proposal for removal of locally static type on case select
expression (FT25) is accepted. We need to handle choices that are
aggregates.  An aggregate used as a choice has it type determine from
the select expressions type.  If the select expression is one of the
following

  - The name of an object whose subtype is locally static
  - An indexed name whose prefix is one of the members of this list and whose indexing
    expressions are locally static expressions
  - A slice name whose prefix is one of the members of this list and whose discrete range is
    a locally static discrete range
  - A function call whose return type mark denotes a locally static subtype
  - A qualified expression or type conversion whose type mark denotes a locally static subtype
  - An item in this list enclosed by parens.

Then the aggregate has a locally static subtype constructed from the
base type and the constraint determined from the list above. This allows for 
the use of OTHERS in an aggregate.  For example:
SIGNAL  s : std_logic_vector(3 DOWNTO 0);
...

CASE s IS
  WHEN ( 0 => '1', OTHERS => '0') =>  -- same as "0001"
  WHEN ( 1 => '1', OTHERS => '0') =>  -- same as "0010"
  WHEN ( 2 => '1', OTHERS => '0') =>  -- same as "0100"
  WHEN ( 3 => '1', OTHERS => '0') =>  -- same as "1000"
...

If the select expression is not an item in the above list,
then the aggregates constraints are determined from the aggregates contents.
As the result OTHERS cannot be used in an aggregate that is a choice.

This does cause some odd things though.  For example

SIGNAL s : std_logic_vector(3 DOWNTO 0);

CASE  s IS
 WHEN ( 0 => '1', 1 TO 3 => '0') => -- same as "0001"
 WHEN ( 0 => '0', 1 => '1' 2 TO 3 => '0') => -- same as "0010"
 ...

SIGNAL s2 : std_logic_vector ( some_generic - 1 DOWNTO 0);

CASE s2 IS
 WHEN ( 0 => '1', 1 TO 3 => '0') => -- same as "1000"
 WHEN ( 0 => '0', 1 => '1' 2 TO 3 => '0') => -- same as "0100"
 ...

This is because in the first example the aggregate's subtype is
determine fromt he select expression.  In the second case the
subtype is determined from the aggregate's choices and the
indexed constraint of the base type array indices.

We also need to address the definition of  what a locally static subtype 
is. Take the following example:


package p1 is

  constant c1: integer; -- deferred constant;

  subtype shortInt is integer c1 downto 0;

  array arrayType is array ( shortInt range <> ) of bit;

  constant arrayConst : arrayType := "0000";

  constant arrayConst2 : arrayType := arrayConst & arrayConst;


end package;

By the current locally static expression rules arrayConst is
locally static because of items a and b in the list in section
7.4.1.  What is interesting is that the bounds of arrayConst are
unknown because C1 is a deferred constant and not known.  
With the modified rules of FT22 then arrayConst2 would also be
locally static but again here we don't know the bounds or arrayConst2.
Why do we care about the bounds?  We know the length in both cases.
If we want do to allow for indexing and slice as FT22 allows, be need
to know the bound to do the correct element selection. There is also
the catching of error cases.  For example if C1 is initialized to
-1 then arrayConst is an error.  If arrayConst is truly locally static
the compiler may have removed the constant and force the compiler to
generate a runtime check seems a little extreme.

I believe the solution is very straight forward.  If the restriction
that the subtype of an object be locally static, at least 
for composite types, is added to item b in section 7.4.1.
The definition of locally static subtype type needs to be changed 
also.  Currently for array a locally static subtype is defined as

"A locally static array subtype is a constrained array subtype formed
 by imposing on an unconstrained array type a locally static index
 constraint." Section 7.4.1 line 606.

This has a boundary case where the index constraint on the array type
is not locally static.  If the index constraint is not locally static
it is again impossible for the compiler to flag errors in locally
static expression at compile time.  It is also impossible for the
implicit "&" to compute the correct result bounds. In 93 version
the result's bounds depend on the base type's index constraint.

So the proposal needs to be update to reflect the changes in item b
and the definition of a locally static array subtype. The ISAC is
also proposing some changes here, currently its a change in the language
of item b to.

b) A constant (other than a deferred constant) explicitly declared by 
  a constant declaration with a locally static subtype and initialized
  with a locally static expression.

This is change in b is good.

The  line 

"A locally static array subtype is a constrained array subtype formed
 by imposing on an unconstrained array type a locally static index
 constraint." Section 7.4.1 line 606.

Would be changed to 

"A locally static array subtype is a constrained array subtype formed
 by imposing on an unconstrained array type with a locally static index
 constraint. The unconstained array type must have a locally static element subtype
and locally static index subtype definitions."


These changes allow better use of existing language construct at the
expense of compiler complexity.  Specifically the inability to use
& in constants that are then used as case choices currently is illegal
and causes problems for users.  


Analysis:
----------------------------
[To be performed by the 200X Fast Track Working Group]


Resolution:
----------------------------
[To be performed by the 200X Fast Track Working Group]