Subject: Re: [sv-cc] DirectC: defaults for args, passing by name
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Tue Feb 18 2003 - 12:07:44 PST
Hi Andrzej,
I am sorry, but I think I have a completely different point of view here. As said, 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)
My proposal would be to support the first two (with only minor restrictions or amendments) and to forbid the third for DirectC
task/functions. 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. As such, any
restriction should be avoided when possible.
b) I think the first two issues are mostly issues of SystemVerilog, there is not much here that is specific for the DirectC
interface; just to give some examples [I am reusing some of your issues below ...]:
- w.r.t. default parameters: assume you have defined extern void foo(int i = 10, bit b = 0); when you call foo(10,5) or foo(,5) it
is irrelevant for the C side where the 10 comes from as long as it is there. The SV standard requires that a missing parameter has a
default, so I think we are on the save side here.
- I would have some issue with specifying complex structures as default value, but if SV does not have a general problem with this
(so it is possible for other tasks/functions), why should we bother? For the C side it does not matter how/where this is being
specified, so if SV solved the problem why should we exclude DirectC from this?
- 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
- w.r.t. to passing parameters by name and having not all names specified as you showed in your examples
extern void foo(int , bit b); // not all names specified
extern void foo(int i, bit );
extern void foo(int , bit ); // no names at all
we have two options:
a) "require a default value for all options without names" to permit the usage of passing parameter by names
b) permit a mixture of pass by order and pass by name (I think we already had some discussion here and the general agreement was
against this)
otherwise passing parameter by names is not permitted. IMHO this is fully in line with the SV spec, since it says I have to
provide a default value for any missing parameter. Since I can not pass a parameter by name, when this name is missing, I need to
have a default value defined for it.
c) Of course we could also use your versions of restrictions, but I would like to make the first less stringent, as follows:
- passing by name is legal only for the external functions when all formal arguments are either named or provide a default value
- multiple external declarations must use same names of formal arguments
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 (if there are any, the only thing I heard until now is the speed comment from Kevin); just some
possible issues I foresee -->
- we might get trapped again into the 'simulator data layout must match C data layout issue' (if we want to directly modify a
variable by a simple C assigment - there are not neccessarily abstract writes here - then the data layout WITHIN the simulator must
match the one seen from C). In my eyes alone this is a "killer" issue.
- I don't see what I gain over an inout parameter: inout delivers my a pointer to a C data, reference delivers me a pointer to a
C data. It is up to the simulator to make sure I don't destroy his data, so he very likely will copy this data, which is a step that
is missing. Yes, this is a performance gain, but at the cost of the previous point. Woooahh!
- How do we handle pass by reference when looking at arrays that are anyway accessed over abstract accesses? I don't see any
difference here, other that the corresponding functions might need to handle two different cases (inout and ref). This might even
lead to performance drops.
- What are the update semantics mentioned by Joao (have the same variable written once by 'ref' the other by 'inout'). The
reference is written within the C code and will be overwritten when copying back the inout one. What happens, if the internal
implementation also permits direct access (we explicitely left this open to the vendors). In this case the order of the writes would
become important (when the inout is written before the ref, the ref wins). Or do we have to check for this special case. Or would
this enforce a copy of the inout variable, now? I am sorry, but for a dumb user like me this is a desaster ...
- Last but not least I heard something about safety and security. I am not sure whether I (in case I would be simulator vendor)
would be happy to provide DIRECT access to simulator internal structures ...
Enough said. Only my $0.02.
Best regards,
-Michael
Andrzej Litwiniuk wrote:
> Hi all,
>
> DirectC had been developed partly out of sync with other committees.
> In particular, default argument values and argument passing by name which have
> been added to SV, are not addressed in DirectC (thanks Francoise for drawing
> our attention to it!). Another newly added feature not addressed in DirectC
> is the ability to pass arguments by reference ('var') in addition to formerly
> sole mode of passing by value. (We are not talking about the C Layer here!)
>
> Shortly speaking, the mechanism for binding the actual arguments to formal
> arguments 'by name' has been extended from module instantiating to all
> function and task calls. This allowed for optional default argument values:
> if not all arguments are actually passed, the default values may be used.
>
> Should this be extended also for DirectC?
>
> My recomendations is:
> do not support default values and argument passing by name for DirectC calls.
>
> My reasoning goes as follows:
>
> 1. Neither default values nor passing by name can be supported for calling
> the exported SV functions from C code. The syntax of C cannot be changed.
>
> 2. Please recall that currently the names of formal arguments are optional
> in the external declarations. Those optional names are ignored in checks
> for consistency of multiple external declarations.
> For example, the following declarations are all equivalent and legal:
>
> extern void foo(int count, bit status);
> extern void foo(int i, bit b); // different names
> extern void foo(int , bit b); // not all names specified
> extern void foo(int i, bit );
> extern void foo(int , bit ); // no names at all
>
> If we decide to support argument passing by name for external function
> calls (in SV only!), then some rectrictions will have to be added:
> a) passing by name is legal only for the external functions with
> all formal arguments named (i.e such that that every formal
> argument has its name specified in the external declaration)
> b) multiple external declarations must use same names of formal
> arguments, i.e. if a name is provided for an argument, the same name
> must be used in every declaration for that function, that provides
> a name for that argument. For example, the first two declarations
> of 'foo' break that rule.
>
> Supporting the default values (in SV only!) seems relatively easy.
> They can be supported with or without supporting argument passing by name.
> If we decide to support default values, then an issue of the equivalence of
> multiple external declarations will immediately arise. (Same value for same
> arguments must be provided, what if there is no default value and yet the
> actual arg. is missing, etc.)
>
> I'm not sure, however, whether we should be bothered with the default values
> at all. Francoise checked that:
>
> => While looking more closely at the bnf for function prototype, I dont see
> => that the bnf allows to provide default values for the formal arguments of
> => a function prototype. It allows it only for the function declaration.
> => [...]
> => Therefore for a extern directC function declaration in the Verilog code,
> => you cannot provide default values for formals.
> => Ex: you cannot write:
> => extern myCfunction (int i = 0);
>
> The syntax can be, of course, extended, but do we want this?
>
> I don't have a clear and strong opinion how to address the issue of formal
> arguments passed by var. I lean to think that we should not support this feature
> in DirectC.
>
> 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 : Tue Feb 18 2003 - 12:08:37 PST