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

I think that in whole disciussion you've forget about my orginal doubt.
Which is : is automatic lifetime defined for module should change the
lifetime of the variable defined in begin...end blocks in always/initial
processes?
LRM 1800-2009 says: "The module header defines the following: - The
default lifetime (static or automatic) of subroutines defined within the
module"
If this lifetime from module header should change also lifetime of variables
from begin...end blocks then above sentence should be changed. If not then
it is ok.

DANiel

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Bresticker, Shalom
Sent: Friday, February 12, 2010 6:21 AM
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.