Re: [sv-bc] What constitutes the actual lval in an output?

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


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.