RE: [sv-ec] Re: [sv-bc] ballot comment on static reference arguments

Please pardon me for dropping in in the middle of the discussion, but
I couldn't help overhearing the sentence:

  "...So the simpler solution is to just forbid declaring a static
  task in this case, which is the direction we want users to take
  anyway..."

I hope we are not talking about forbidding static tasks in all cases,
as we will then eliminate a very useful and long standing feature of
the Verilog language.  Originally, all tasks were static; and they
were used as a somewhat simplistic means for object oriented like
design.  There are well known problems with their semantics for this
purpose.

However, a purpose for which they remain well suited is to serve as a
bridge from outside software (and often hardware begind that), as many
tools allowed foreign tools to invoke tasks to launch desired behavior
when an external tool changed some state on an interface.

Clearly to facilitate such purpose, tasks must be static, so that the
external tool can be assured the task is always present.

If this case remains well regarded, and we are not proposing its
removal, then I apologize for my interruption.  If however there was
some proposal to eliminate static tasks in this case as well, then my
objection is hereby registered.

-mac

-- On Apr 8 2005 at 19:26, Steven Sharp sent a message:
 > To: sharp@cadence.com, sv-bc@eda.org, Brad.Pierce@synopsys.com, Dave_Rich@mentorg.com, sv-ec@eda.org
 > Subject: "RE: [sv-ec] Re: [sv-bc] ballot comment on static reference arguments"
 > 
 > >In general, static tasks are a problem for garbage collection, even with
 > >out the ref argument. If I pass a class handle to an argument of a
 > >static task/function, that static argument retains the handle after the
 > >task/function returns.
 > 
 > Have you proposed a solution for that issue as well?
 > 
 > 
 > >If you just disallow hierarchical references to the static argument,
 > >that doesn't change the fact that the argument still contains the
 > >reference after the task exits (or you would have to add more language
 > >that says that it doesn't).
 > 
 > If you can't access the value, does it matter whether it is still there?
 > (If a tree falls in the forest...)  If you can access it via PLI or a
 > user interface, perhaps so.  However, as you say, such references could
 > be specified to be NULLed out on exit.
 > 
 > 
 > >So the simpler solution is to just forbid declaring a static task in
 > >this case, which is the direction we want users to take anyway.
 > 
 > I'm not sure that "we" includes everyone.  Static tasks offer some
 > advantages, such as efficiency.  Other new language features that are
 > effectively requiring automatics to be garbage-collected are increasing
 > that efficiency gap.
 > 
 > 
 > >BTW, you can't  declare a static argument to an automatic task.
 > 
 > Well, that avoids that issue anyway.
 > 
 > 
 > Steven Sharp
 > sharp@cadence.com
 >