From: Shalom Bresticker (Shalom.Bresticker@motorola.com)
Date: Thu May 22 2003 - 03:08:02 PDT
Precedence: bulk
I don't think 281 was ever formally resolved by the ETF,
just that nobody objected to closing it.
Regardless, if so many people are confused by the semantics of fork-join,
maybe we should add a short explanation in the 1364 LRM.
Shalom
Steven Sharp wrote:
> >The semantics of fork-join in a static environment are very well
> >understood by customers and vendors, alike. The entire discussion/debate
> >I intended to launch is limited to semantic quirks around forks in the
> >presence of automatic variables and then whether SystemVerilog's
> >introduction of a fork-join_none has any bearing on all this.
>
> Perhaps we are going overboard with describing the rationale and
> trying to convince you with it.
>
> The bottom line is that in IEEE 1364-2001, a fork-join subprocess
> inside a reentrant task or function does not allocate new copies of
> any automatic variables in surrounding scopes. This is supported
> reasonably well by the text of the standard, more definitely by the
> knowledge of those who participated in the standardization (such as
> Mac and myself), and officially by the resolution of erratum 281
> by the ETF.
>
> If SystemVerilog is supposed to be backward compatible with 1364-2001,
> which I hear it is, then this applies to fork-join in automatic tasks
> and functions in SystemVerilog also. If SystemVerilog is supposed to
> be reasonably regular, which seems like a good idea, then this should
> apply to explicitly declared automatic variables and the new kinds of
> fork-join also.
>
> Steven Sharp
> sharp@cadence.com
-- Shalom Bresticker Shalom.Bresticker@motorola.com Design & Reuse Methodology Tel: +972 9 9522268 Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478
This archive was generated by hypermail 2.1.4
: Thu May 22 2003 - 03:10:37 PDT
and
sponsored by Boyd Technology, Inc.