RE: [sv-bc] changing the lifetime of begin end block

> By the way, it was recently asked, and there was not a final answer, what is the meaning of "class static"?

That is an excellent question. I suspect allowing a lifetime qualifier for the class in the BNF may be a typo. The semantics of a "class static" are certainly not defined by the LRM. There are some plausible definitions of what a static class may be, but I doubt they are particularly useful. One conjecture is that this was an attempt to define synthesizable classes - which would require some form of dynamic creation limitation. But, the actual semantics are currently undefined. Perhaps we should remove that syntactical construct until such time that we define its semantics.

        Arturo

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Bresticker, Shalom
Sent: Thursday, February 11, 2010 9:21 PM
To: jwill@BasicISP.net; sv-bc@eda.org
Subject: RE: [sv-bc] changing the lifetime of begin end block

The LRM defines the behavior of automatic variables in procedural blocks:

"Such variables have the lifetime of the call or block and are initialized on each entry to the call or block".

and

integer unsigned I;

is indeed legal.

The LRM says,

"The data types byte, shortint, int, integer, and longint default to signed. The data types bit, reg, and logic default to unsigned, as do arrays of these types. The signedness can be explicitly defined using the keywords signed and unsigned.

int unsigned ui;
int signed si;"

By the way, it was recently asked, and there was not a final answer, what is the meaning of "class static"?

Shalom

> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On
> Behalf Of John Michael Williams
> Sent: Friday, February 12, 2010 7:22 AM
> To: sv-bc@eda.org
> Subject: Re: [sv-bc] changing the lifetime of begin end block
>
> Hi Steven.
>
> A variable not on a stack is NOT "automatic". Whether a keyword
> was used on it or not -- if it can not be deallocated AUTOMATICALLY
> because of exit of some process or thread, it is not an automatic
> variable.
>
> I think there is a confusion here over what "automatic" means.
> The LRM has to be modified, if this is a real confusion, rather
> than just a confusion during this discussion.
>
> For another example, what if I declared,
>
> "integer unsigned I;" ?
>
> Would the keyword make an integer "unsigned"? No,
> because an integer is defined as a 32-bit variable
> having a sign bit as its MSB.
>
> A conforming compiler should report an error if
> it encountered "module automatic mod1;" just
> as it should "integer unsigned I;"
>
> Steven Sharp wrote:
> > Note that in most cases, variables outside of tasks and
> functions don't
> > need to use automatic storage. There cannot be multiple
> activations of the
> > scope except in certain circumstances involving
> fork..join_any/join_none
> > inside loops. An implementation might try to optimize the
> other cases by
> > treating them as statics regardless of how they were
> declared. They might
> > go too far and allow hierarchical references to them as if
> they were static,
> > exposing this treatment. That would be a faulty
> optimization, but would
> > not necessarily indicate that these variables are not
> otherwise treated as
> > automatics.
> >
> > If you really want to test whether these variables default
> to automatic,
> > you should write a testcase that creates multiple
> simultaneous activations
> > of the scope, and see whether each gets its own storage.
> >
> > Steven Sharp
> > sharp@cadence.com
> >
> >
>
> --
> John Michael Williams
> jwill@BasicISP.net
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.