Subject: Re: [sv-ec] fork..join_none/join_any and automatic variables
From: Randy Misustin (ram@Model.com)
Date: Wed May 21 2003 - 09:03:54 PDT
Hi Mac,
Michael McNamara wrote:
>Randy Misustin writes:
> > begin
> > automatic int i = 0;
> > fork
> > i = 1;
> > join
> > #10 $display(i);
> > end
>
>I would be very surprised if the answer anything other than 1; and
>there would certainly be backwards compatibility issues.
>
>
From my user-sanity perspective, I tend to agree, although I'm
unconvinced that this is a compatibility issue (unless, of course,
you're thinking about the implications on 1364-2001 automatice tasks,
but this whole discussion is relevant to it as well).
>If we want to stick to Verilog-1364 semantics, then fork does not
>create a new variable, and instead references the nearest enclosing
>declaration of an 'i', which is the automatic int; this same 'i' is in
>scope to the fork, and to the $display; and the $display can not be
>executed until the join completes: hence the fork..join wrapper should
>have no effect. The fork..join does not create any new scopes as
>well.
>
>In 1364, all the automatic does is make the 'i' cease to exist once we
>leave the begin .. end (as well as make the 'i' invisible to
>$monitors, $dumpvars, pli accesses, et cetera), as well as make
>multiple silmultaneous executions of this begin end have their own
>copy of an i.
>
>
Ahh, this last statement is the core issue. As you said, multiple
simultaneous executions need to have their own copy of i. I guess given
your ealier reaction and thinking, you feel that the code executing
within the fork isn't a separate simultaneous execution?
If you'll allow me to put my implementor's hat on for a moment, let's
look at it from the other side. Automatic variables, it seems to me, are
begging to behave like conventional automatic variables in C. They don't
have a hierarchical path, they have a lifetime governed by the enclosing
scope, and they are useful in recursive and reentrant styles of coding.
This path also allows automatic Verilog functions and tasks to sit in a
far sweeter spot in terms of their effecient relationship to the
underlying hardware (ie, processors are designed with efficient stack
access in mind). All is good.
A fork statement creates a new thread and, with it, a new stack. This
argues heavily that all forms of forks copy relevant stack areas at
fork-time. Specifying otherwise would imply Scheme-like closures or
fairly exotic stack implementations (the latter undoubtably leading to
"interesting" interactions with DPI). Thus the stack copy seems like the
right implementation path, but we are now in the space where my snippet
implies 2 separate copies of 'i' and the result of the $display in my
example is the possibly unintuitive '0' (or is it?).
>Because of the '= 0' the automatic doesn't even usefully serve to
>prevent a previous value of i from being available, as the unilateral
>assignment to 0 overwrites this old value when the scope is reentered.
>
>
Hmm..not following this one...sorry.
Thanks Mac.
-randy.
>-mac
>
>
This archive was generated by hypermail 2b28 : Wed May 21 2003 - 09:26:13 PDT