Subject: Re: [sv-cc] DirectC: defaults for args, passing by name
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Wed Feb 19 2003 - 02:39:55 PST
Hmmm. Not bad for just entering the discussion. There is not so much difference on opinions here. I think Kevin's position was much
more contrary ... Kevin, what are your points ???
-Michael
Andrzej Litwiniuk wrote:
> 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?
I think the agreement reached at yesterday's conference call was that Swapnajit will decide whether we can raise a poll on _all_ those
issues as soon as there was sufficient information/discussion about his topic. Francoise has already received some response from Dave
Rich of the EC committee on her questions. None of them made me change my opinion. I think I am ready for a poll.
> 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.
YES
> 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.
Until here, I think, we are in full agreement.
> 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)
YES. I was taking this as a given, since we said the signature for all prototypes must be the same. A default value must be part of
the signature, IMHO.
> 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.
From what I see the only difference is
on b) You require that there is always a name.
I propose that we require either a name for an argument OR a default value.
on c) You require that all names for a formal argument match or are left unspecified [although think this collides with your rule in
b)]
I have to admit I didn't think about conflicting names as you defined within your example.
I still believe that with the restrictions I stated already PLUS forbidding to use the same name for different formal
parameters, it would be possible to solve this issue. So
extern void foo(int count = 13, bit status = 1);
extern void foo(int i = 13, bit status = 1); // different names
is correct and can always be properly solved:
foo(status = 0, count = 4); // O.K.
foo(status = 0); // ambigous, but the default value is the same. It is still the _same_ Direct C function!
foo(count = 1); // O.K.
foo(i =2); // O.K.
foo(); // ambigous, but see above.
But to be honest, I am not religious at all about your restriction w.r.t. topic c). I could also live with your restriction. I am just
an user and a lazybone, so if a vendor can do it for me, why should I bother checking prototypes ...
> 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
--NOTE: The content of this message may contain personal views which are not neccessarily the views of Motorola, unless specifically stated.
___________________________________________________ | | _ | Michael Rohleder Tel: +49-89-92103-259 | _ / )| Software Technologist Fax: +49-89-92103-680 |( \ / / | Motorola, Semiconductor Products, System Design | \ \ _( (_ | _ Schatzbogen 7, D-81829 Munich, Germany _ | _) )_ (((\ \>|_/ > < \_|</ /))) (\\\\ \_/ / mailto:Michael.Rohleder@motorola.com \ \_/ ////) \ /_______________________________________________\ / \ _/ \_ / / / \ \
The information contained in this email has been classified as: Motorola General Business Information (x) Motorola Internal Use Only ( ) Motorola Confidential Proprietary ( )
*** This note may contain Motorola Confidential Proprietary or Motorola Internal Use Only Information and is intended to be reviewed by only the individual or organization named above. If you are not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any review, dissemination or copying of this email and its attachments, if any, or the information contained herein is prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system. Thank you! ***
This archive was generated by hypermail 2b28 : Wed Feb 19 2003 - 02:41:18 PST