RE: [sv-bc] "Assignment ... to a constant expression"

From: Steven Sharp <sharp_at_.....>
Date: Fri Apr 25 2008 - 17:08:07 PDT
>From: "Brad Pierce" <Brad.Pierce@synopsys.com>

>I don't think it's a fact that any arbitrary non-constant expression can
>be used as the initializer of a static variable.  Where does the LRM say
>that?

Some other comments on this:

The text on initializers doesn't seem to give different rules for
initializers on static and automatic variables.  It does mention static
variables explicitly a couple of times, but apparently to make the point
that run-time expressions are allowed even on static initializers.

In fact, there is a restriction that is required but is not mentioned
anywhere.  A local static variable initializer must not refer to an
automatic variable, even if it is lexically visible in the scope of the
static variable initializer.

Section 6.20.6 "Const constants" has some references to initializers.
It says that an automatic constant declared with the const keyword can
be set to any expression that would be legal without the const keyword.
My initial thought was that this sentence was pointless if an automatic
variable can be set to any arbitrary expression.  However, that is not
quite true, since things like assignment compatibility are still required.
And it is trying to contrast it with static constants.

The section definitely puts restrictions on static constants.  However,
I don't see much benefit to the restrictions.  If it allowed everything
on the list except other constants, then it would make sense.  The value
would be well-defined and independent of the order in which variables
were initialized.  But when it allows other constants (i.e. other const
variables), it loses any benefit.  It is now dependent on the order in
which constant variables are initialized, which is no more defined than
the order any other variables are initialized.  It might as well allow
any variables, since their initialization is just as well defined as
const variables.  There is no benefit to disallowing non-const variables
if you allow const variables.

The only thing I can see that it prevents is references to nets.  This
might be a minor benefit, since the LRM does not specify the order of
initialization of nets and initial evaluation and propagation of net
values relative to when variable initialization occurs.  However, the
LRM does not restrict non-const variable initializers, so they have the
same problem.  I don't see why it is less of an issue for non-const
variables than for const variables.

So while static constant variables still have some restrictions on
their initializers, they allow enough that I don't see any point in
keeping the remaining restrictions.

Steven Sharp
sharp@cadence.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Fri Apr 25 17:09:12 2008

This archive was generated by hypermail 2.1.8 : Fri Apr 25 2008 - 17:09:37 PDT