RE: [sv-bc] task/function inout arguments with default values

>From: "Bresticker, Shalom" <shalom.bresticker@intel.com>


>> And the next time they call, they
>> want the same default value as last time, not the value that
>> got left in that shared place by the previous call.
>
>Not quite. Since the default can be an expression, then even if you
>treat it as in input, its value can change between task calls.

Sure.  I was simplifying it to be easier to follow.  To be more
precise, they want a default value computed the same way as last time,
from scratch, not something left over from the output of the previous
call.  If someone wants to communicate a value from one call to the
next, the clean way of doing this is to use a static variable in the
task/function.


>> (For a ref arg, there
>> seems to be no choice but for the default to be a valid reference.)
>
>I understand you to mean that a ref argument would have to be treated
>that way even as a default. If so, it might be inconsistent to treat an
>inout default differently than an explicit inout argument.

The apparent difference from ref args is probably the strongest argument
against my suggested treatment.

Note that from the viewpoint of someone who understands the implementation
of ref args (or any C programmer), this difference isn't real.  All
default argument values would be only copied in, never out.  A ref arg
doesn't have a copy-out part.  It is an input argument whose value is an
address.  Like any of the other argument types, the default provides
an input value.  It is just that this value must be a reference to a
variable.  However, since typical users won't understand this, it may
still look different to them.


>> When you leave off an output, you want the output discarded.
>
>While you can leave off a module output, I don't think you can leave off
>a task/function output.

I think you are correct.  However, we have had this request from our
users.  I think we may have allowed it in our implementation as a
nonstandard but natural extension.


>> When you leave off an input, you want a default value. When
>> you leave off an output, you want the output discarded. So
>> when you leave off an inout, you probably want a default value
>> for the input, and the output discarded.
>
>One thing I discovered about inout module ports only last year is that
>you can't connect them to a constant. I think the particular case was of
>an inout that was not actually being written to. It's obvious once you
>think about it, of course. If you have declared it as an inout, that is
>a statement of intent that you want it to be writable. 
>
>I assume the same is true of task and function inouts.

It is true.

It isn't a close analogy, since inout module ports are really more
like ref arguments/ports that apply to nets than they are like inout
arguments.  Like a ref arg/port, they provide a continuous connection
such that both sides are referring to the same object.  There are no
procedural copy-in/out operations.

But in both cases, constants are not allowed.  For inout ports, it is
because you cannot alias/collapse a constant with a net.  For inout
arguments, it is because you cannot do the assignment for the copy-out.


>Until now, there was no suggestion that a default be treated differently
>than an explicit argument. If you do, then an inout default could be a
>constant as well as an expression.

Yes.  And my suspicion is that this is what you would want most of the
time, for inouts as with inputs.


>On the other hand, if you say that an inout default is like an explicit
>inout argument and there is copy-out at the task end to the default
>expression, then it might also be logical to allow defaults for outputs.

Agreed.  The fact that defaults are not allowed for outputs tends to
indicate that the copy-out functionality was never intended to be
applied for defaults.

It might just be that it wasn't considered.  But even that would say
something significant about the usefulness of it.


>If you oppose defaults for outputs, and I admit I am not sure about the
>idea, then defaults for inouts or ref arguments also sounds like a bad
>idea.

I think that users want to leave off output arguments, but not to have
to supply a default place to copy the output to.  They just want the
output discarded.  I think the behavior of inouts then follows from the
combination of inputs with defaults and outputs.

Only allowing defaults for inputs is another possibility.  I assume that
this feature was adopted from C++, which only has input and ref arguments.
Somebody may have noticed that inouts were half input, and added them to
the list for that reason.  They may not have considered the output half,
or thought that it was obvious.  But it isn't to us.


To summarize my points:

As you mentioned in your original email, the LRM talks about defaults as
if they only provide a value for the argument.  It doesn't say anything
about their providing a place to copy out the result for an inout.  You
proposed that it be modified to say something about that.  I am suggesting
that it doesn't say anything because defaults were never intended to supply
anything but an input value.  The fact that output arguments are not
allowed to have defaults tends to support that view.

Even if this was not the intent, I think it may make more sense and be
more useful that way.  It is not a big deal, since I think that less than
1% of arguments with defaults will be inouts.  But if we define defaults
for inouts to have the copy-out semantics also, I think they will be used
0% of the time.

Steven Sharp
sharp@cadence.com