I was trying to say that the rest of language is defined assuming that a function has no user defined interactions with the scheduling of events. The indirect side effect of a function writing to an externally visible register is the only hole in this interpretation that is explicitly allowed in the current LRM that I am aware of. BTW, this hole creates additional holes by allowing program blocks threads to call functions that make blocking writes to non-program block variables. Final blocks are defined in terms of what was supposed to be legal in a function. What happens if there if a fork/join_none inside a final block? Do we make that illegal or just ignore the thread(s) created? Program blocks are supposed to implicitly exit after all threads created by initial block. That works because only initial blocks can start a thread. I don't think anyone can argue that the current LRM allows functions to call a task or contain blocking statements. The argument about whether fork/join**** is legal is moot without those constructs inside the function. This may very well be a desirable enhancement request, but it's much more complex than just removing a few restrictions in the definition of functions. Dave > -----Original Message----- > From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Steven > Sharp > Sent: Tuesday, March 21, 2006 5:45 PM > To: sv-bc@eda.org; sv-ec@eda.org; shalom.bresticker@intel.com > Subject: RE: [sv-bc] RE: Can a function contain a fork/join/any/none? > > > >From: "Bresticker, Shalom" <shalom.bresticker@intel.com> > > >> Is it really true that "functions are not supposed to interact > >> with the scheduler"? > > I don't believe that there is anything in the LRM that says this. > Dave Rich was stating his interpretation, which is stronger than > what the LRM actually says. > > > >> This implies that the scheduler may suspend function execution > >> in the middle. If this is not so, it needs to be explicitly > >> stated. > > Based on the LRM, there is nothing preventing the scheduler from > suspending function execution in the middle. There are situations > where an implementation might want to do this. If the implementation > wants to inline a continuous assignment from a variable to a net any > place the variable is written, and the variable is written in a > function, then the continuous assignment would be inlined there. This > is equivalent to doing the assignment to the variable, suspending the > function in favor of the continuous assignment, and then resuming the > function afterwards. > > An implementation could get itself into trouble if it went too far > in suspending function execution. If a continuous assignment called > a function, the function suspended, other processes updated inputs of > the continuous assignment that it had already read, and then the > function resumed, the continuous assignment might not work properly. > It evaluated with the old values, and might not re-evaluate for the > changes since it was suspended when they were happening. > > Steven Sharp > sharp@cadence.comReceived on Tue Mar 21 22:50:32 2006
This archive was generated by hypermail 2.1.8 : Tue Mar 21 2006 - 22:50:50 PST