From: Adam Krolnik (adamk@cyrix.com)
Date: Mon Jan 05 1998 - 20:58:46 PST
I wrote,
"When I think about reentrant I am thinking multiple processes will call
a task that consumes time to perform its operation."
Implied by this statement is the fact the each process passes some
information to the task that is different then another process. Then as
you state, one would need multiple variables for the inputs and local
state.
This feature is not specifically for hardware description but I would use
it for hardware verification. You also correctly note that the "disable"
statement now becomes somewhat obscure.
I asked this very question at the last call. I have used disable in two
ways: disabling a task from outside it(disable all executing processes),
and disabling a task from inside it (instead of return.) There can be
multiple definitions for what "disable" should do to a reentrant task
considering simply these two cases. Karen was most interested in leaving
the definition of "disable" to simple terminating the task (*all* flows of
control outstanding.)
It is interesting that by changing the wording of this enhancement
request from reentrant to recursive we have lost some of the reasons for
this request.
With reentrant functions, and allowing them to consume time, mac wrote:
> assign a = b[f(c)];
> mod m1 (a,b,f(c));
> These constructs get real weird to think about if f(c)
>contains #10.
assign #10 a = b[f(c)];
I would be interested in working on a definition for assignments with a
function that consumes time if that is the only hurdle. I would like the
ability to call tasks from functions; removing the "functions don't
contain time restriction" would allow this.
It would seem that if people are interested in having recursive tasks,
someone is going to ask why not recursive functions too?
<p> Adam Krolnik
Verification Engineer
Cyrix - NSM
Richardson TX. 75083
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:52:45 PDT
and
sponsored by Boyd Technology, Inc.