Subject: Re: [sv-cc] DirectC: defaults for args, passing by name
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Tue Feb 18 2003 - 15:27:03 PST
Michael wrote:
> [...] I think there are basically three different issues:
> . passing of task/function arguments by name
> . the possibility to define default value for parameters
> . the support of pass by reference (ref modifier)
Absolutely agree. That's my point, too.
> My proposal would be [...] to forbid the third for DirectC
> [...]
> d) I am against the support of pass by reference 'ref', since I think there
> are several issues for an user that I don't think outweight the benefits
> provided
Many of us seem to share that opinion and opt for forbidding 'ref' modifier for
DirectC. If there are no further comments on this issue, can we poll on this?
Michael wrote:
> My proposal would be to support the first two (with only minor restrictions or
> amendments) [...] The reasoning here is as follows:
> a) One of the goals we had was to make DirectC tasks/functions look like any
> other SystemVerilog task/function.
> [...]
> it is irrelevant for the C side where the [actual value] comes from as long
> as it is there.
I agree with the motivation.
I agree that both features (pass by name, default values) are fully transparent
for the C side.
And I agree that this is doable for SV side. I hope you all do agree that C side
will not support neither of these features.
Let's assume for now that we want to support pass by name and default values
for external function calls in SV and let's focus on the needed restrictions.
Where I disagree with Michael is what are the additional restrictions needed.
It may seem natural to follow the rules or relay on the restrictions imposed
by the basic committee on the function prototypes in SV.
Pls. note that SV prototypes need not to provide neither formal argument
names nor default values, because there is always a back-up source of information:
the actual function definition themself.
There is no such definition, however, for an external function, so whatever
information is to be provided for an external function, it must be given in
every of multiple external declarations for that function.
I would recommend more stringent restrictions.
a) if a default value is defined for a formal argument of an external function
then every external declaration for that function must define the same
default value for that argument (.e. must define a defalut value and the value
must be same)
b) arguments may be passed by name only for the external functions that have
all their formal arguments named
c) if multiple external declarations specify the name of a formal argument,
than the names must be the same.
In other words, a name is still optional, but if specified, it becomes
a part of definition. Repeated declarations must either use the same name
or not specify the name.
Michael wrote:
> - w.r.t. to passing parameters by name and using different names; as in your example
> extern void foo(int count, bit status);
> extern void foo(int i, bit b); // different names
> IMHO this can be solved with stating a simple rule:
> "the name of the parameter used specifies the prototype being used", plus the restriction "only the names used within a
> single prototype can be used". Since (if I recall properly) all prototypes must have the same signature, we are on the same side
> (although I believe that even different signatures could be supported with these rules).
> as a result the call 'foo(status = 1, count = 255)' is correct, while 'foo(i = 3, status = 0)' is wrong
I don't think the names from different prototypes can be mixed. That's why
I requested that names, if defined, must be same for all prototypes.
Consider this:
extern void foo(int count, bit status);
extern void foo(int status, bit count);
(I propose that such prototypes are incompatible because of different
names of formal arguments.)
foo(status = 1, count = 255); // which prototype?
// what is 'status'? what is 'count'?
Regards,
Andrzej
This archive was generated by hypermail 2b28 : Tue Feb 18 2003 - 15:27:57 PST