Subject: Re: DirectC: C layer - call by value vs. reference
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Mon Dec 16 2002 - 08:31:01 PST
Hi all,
I have now about 20 'Re: DirectC' emails in my folder, therefore I start to distinguish the threads a little bit. Otherwise there
will be a huge confusion ...
My opinion w.r.t. to call by value vs. reference has some facets I would like to share with you:
a) When we don't impose a 'copy-in', 'copy-out' style we leave it to the vendors how their internal data representation might look
like. This might result in some performance improvements. On the other side I don't see what I win as a user by having a copy-in,
copy-out style over just saying 'you better don't overwrite this variable' (which can be done by const and thus even checked by the
compiler).
b) With respect to Kevin's idea of a '&' call-by-reference designator, my understanding is that this is a counter-proposal for the
recent addition of the keyword 'var' and draw your attention to section 10.5.2 at page 64 of the 3.1 draft LRM
c) We also said that any call of a C function from SV should look like any other call of a SV function. As such we better do support
call-by-reference as it is defined in 10.5.2 additionally to the standard call-by-value style.
d) When going this route, I don't see any more room for discussion, since - imposed by the need to look like a SV call - we anyway
have to support both styles.
Just my $0.02
-Michael
"Stickley, John" wrote:
> Kevin and Francoise,
>
> Kevin Cameron wrote:
> >> simulator side rather than by
> >> a C user function, the simulator knows how much he needs to allocate.
> >> And as a bonus this solution is always binary compatible if we agree
> >> on the canonical representation
> >> of the copyout value on the C side, which I think should be in a VPI
> >> vecval structure format.
> >> There is no C API function to manipulate the values that are passed.
> >>
> >> I would like to know what you think about these issues.
> >>
> > I agree. There's a proposal for copy-in and copy-out (pass-by-value)
> > returns for SV types in
> > my document. Copy-out is limited to return values because that's the
> > only pass-by-value output
> > of a C call.
> >
>
> johnS:
> So I'm afraid I have to disagree with both of you here.
> Please read over my previous e-mails see if you can appreciate
> why it is really important to support a pass-by-reference
> mode for performance reasons. Particularly for frequently
> passing aggregate data objects back and forth between
> the language domains.
>
> If it is felt by the committee that both copy-by-value
> and copy-by-reference are important we may want to consider
> enhanced syntax as was suggested by Kevin earlier.
>
> His idea was to designate a '&' symbol prefix to an arg name
> to let the user decide for themselves whether call-by-value
> or call-by-reference should be used. But I would contend
> that if this is to be adopted it should be applied at
> the basic language level not only at the SV-to-C-to-SV level.
>
> In fact, as shown in my proposal the function declaration
> that gets placed in the "extern" decl should be a legal
> named_function_proto as currently defined in the 3.1 spec.
> Not a new duplicate function syntax of our own making.
>
> If we think adding '&' or '*' to the SV prototype is a good
> idea, the benefit should exist for SV-to-SV calls and
> SV-to-C-to-SV calls alike.
>
> Bear in mind that in Kevin's proposal there's really no
> way of doing this in the C-to-SV direction anyway since
> the export decl simply references an existing function definition.
> However if that function definition had enhanced syntax
> as did the named_function_proto then you would have complete
> symetry in the feature. But I think this should be taken
> up with the SV-basic committee not here.
>
> And I'm still not convinced that this is worth doing.
>
> In the meantime, I urge us go for something something
> that's not going to inherently kill performance with
> excessive memory-to-memory copies everytime functions
> are called.
>
> -- johnS
>
--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 : Mon Dec 16 2002 - 10:51:33 PST