Greg, I specifically didn't use the term "call by name" since that is clearly not what the LRM intends (at least clearly to me!). The semantics of a (non-ref) formal *during* a call are related to treating the formal as a normal variable. Values are certainly just copied in and out of such formals. The question that I raised was strictly related to the time at which the expression evaluation for an lval actual happens -- are "index like" constituents evaluated at the time that the copy out occurs or are they evaluated at the time that the call is made. With a bit of C-like code around the call, the only for an output (ignoring inout) is whether: t(a.b) acts like: temp = &a.b; t(the_returning_value) *temp = the_returning_value or t(the_returning_value) a.b = the_returning_value Neither is call-by-name; the difference is only whether one is eager or lazy in determining the final result target address. Gord. Greg Jaxon wrote: > Gordon Vreugdenhil wrote: >> The LRM does not address whether "lval" determination is done >> in an eager or lazy manner. > > Most of the description of argument passing has been > couched in the terminology of strict ordering. Sections 13.5.1&2 are > "Pass by value" and "Pass by reference". These terms clearly refer > to evaluation strategies that fall on the "strict" side of the section > headings in wikipedia's article on this subject: > http://en.wikipedia.org/wiki/Evaluation_strategy, which anyone writing > these sections should read. > > Although inout direction is not described in enough detail to unambiguously > categorize it among the host of possibilities, I recall that "copy and restore" > emerged as the most standardizable alternative - and I remember hearing the > phrase "copy-in/copy-out" during committee discussion of this. > >> Execution of the return from the subroutine shall pass values from >> the output and inout type arguments to the corresponding variables >> in the subroutine call. > > Notice that the targets of these assignments are called "variables". > I regard this as coming from the IEEE-1364 mindset where subscripting > was a way of forming variable names. And the activity at "return" > is described as affecting variables from the "call"; which I read as > referenced locations settled at the time the subroutine was called. > > Gordon may be right, though. Because even the Chapter on Assignment > fails to say whether the left-hand side reference is determined before > or after the evaluation of the right hand side. Self-side-effecting > statements have never been a favorite thing to standardize. > > In the evaluation rule Gordon expects, the formal argument "val" acts > more like a "thunk" (call-by-name) than like an "lval" (call-by-reference). > > Thunks evaluate fresh on each use of the formal, becoming miniature > niladic function bodies that are hyper-sensitive to changes in the > binding environment where they were formed. So in: > > task automatic next_val(output int val); > #10 val = 5; > #10 val = 15; > #10 val = 25; > endtask > > next_val will drip side-effects wherever the expression "cid.id" is > taken by its changing name bindings during the 30 tics after next_val(cid.id) > is called. While I can see this being handy for some testbench purposes, > it's hard to imagine that next_val models any single hardware component. > > The ability to pack arbitrary amounts of evaluation and side-effect into > anonymous thunks whose evaluation order will further depend upon the > expression evaluation order inside the subroutine would make a very powerful > language, if you really could standardize it after so many implementations > have been fielded based on years of ambiguous standardization. > > If Gordon is describing the conventional expectations, I'd wonder why the > the classical CS term "Pass by name" did not merit a section heading? > > Greg Jaxon > >> Consider the following: >> >> module top; >> class C; >> int id; >> endclass >> C cid = new(); >> C cid_prev; >> >> task automatic next_val(output int val); >> #10 val = 5; // line 1 >> endtask >> >> initial begin >> #10 next_val(cid.id); // line 2 >> end >> >> initial begin >> #15 cid_prev = cid; // line 3 >> cid = new(); >> #10 $display(cid_prev.id,, cid.id); // line 4 >> end >> endmodule >> >> >> At time 10, line 2 calls next_val; with "cid" having some >> handle value (call it object1). At time 15, "cid" changes >> to associate to a new object (call it object2). At time 20 >> the next_val routine terminates and the copy out occurs. The >> question is whether the lval of "cid.id" was determined >> at the time of the call or at the time of the copy-out. >> In this case, the difference determines whether the >> assignment targets object1 or object2. >> >> Either approach has semantic peculiarities. If "cid" >> would become "null" before the copy-out, the "determination >> at exit" approach would cause a simulation error. If >> the "determination at entry" is adopted, the call might >> be required to keep an object alive if the routine becomes the >> last reference. >> >> There are similar issues with respect to array indexing using >> an index expression that changes during the task evaluation. >> >> In addition, if the formal in "next_val" was "inout", then >> adopting "determination at exit" would mean that the copy-in >> and copy-out could actually relate to different locations >> (object1's id would be copied-in; object2's id would be >> the copy out target). >> >> >> The LRM doesn't clearly discuss this issue, but I suspect that >> "determination at exit" is the expected answer (meaning that >> "object2" is the target in my original example). >> >> Does everyone concur with that expectation? >> >> Gord. >> -- >> -------------------------------------------------------------------- >> Gordon Vreugdenhil 503-685-0808 >> Model Technology (Mentor Graphics) gordonv@model.com > > -- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Fri Dec 12 13:17:05 2008
This archive was generated by hypermail 2.1.8 : Fri Dec 12 2008 - 13:18:10 PST