From: Michael McNamara (mac@surefirev.com)
Date: Fri Jul 24 1998 - 10:57:44 PDT
Adam Krolnik writes:
>
>
> Good afternoon Karen,
>
> I understand your apprehension, however recommendations for
> duplication of code make me apprehensive. Someone now has to
> recognize that two functions have exactly the same coding and
> require a fix to be implemented twice.
>
> Your recommendation is exactly the same as I have proposed - but
> without requiring the user to do it manually!
>
> Side effects can also occur if one uses local state computed from a
> previous call. Are you then going to check for all local variables
> initialized (written) before being read to ensure no side effects?
>
>
> Adam
Content-Length: 992
X-Lines: 30
X-Status: $$$$
X-UID: 0000000588
Status: RO
I still see great value in using perl, or a pre processor for this.
Yes, we can define the side effect free (other than those that have
the side effect of altering the log file) system tasks, and allow
them.
Yes we can identify functions that have a potential use before def of
a variable.
Adding a user visible 'elaboration phase' strikes me as abhorrent.
All of this seems like a lot of work, for gain for how many users?
(Yes I know, they are all on the BTF committee :-)
*sigh* maybe I'm just in a down mood...
Karen, how about we get Synopsys to give the 1364-BTF the Vera
Language specification? That should address making Verilog a 'Systems
Design Language'
<p><p>
--
/\ Michael McNamara <mac@surefirev.com>
/\// SureFire Verification Inc.
/\///\ <http://www.surefirev.com>
_\///\/ Formerly Silicon Sorcery
\//\/ Get my verilog emacs mode from
\/ <http://www.surefirev.com/verilog-mode.html>
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:52:58 PDT
and
sponsored by Boyd Technology, Inc.