Subject: Re: DirectC: C layer - call by value vs. reference
From: Kevin Cameron (Kevin.Cameron@nsc.com)
Date: Mon Dec 16 2002 - 15:54:18 PST
Michael Rohleder wrote:
> 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).
Copy-in/out is safer than direct access, as a user you benefit from a more debuggable interface and fewer
crashes.
> 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
The implementation in C++ is the same as '*' for '&' wrt argument passing, it's just syntactically limited. Since
it's new in SV we can say it will behave the same as C++ for C types, whether it's '&' or 'var'.
Since we are going to cross-call C/C++ I would prefer to use the C++ syntax for external definitions so
that you can re-use C/C++ header files as is (as much as possible), so I'm voting for '&' rather than 'var'
for that and other reasons. I hope any CC members attending the EC will vote that way too.
> 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.
There isn't a problem with that other than it can't be a direct reference if the data layout is not known, it has
to be abstract through a handle with methods.
> 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.
I think the argument was more about the meaning of "abstract". Andrzej's proposal was (IMO) only partially
abstract and therefore only a partial solution.
BTW, arguments types are given to the svcLocateTF call for checking the arguments of C to SV calls
bound dynamically in my proposal. The export statement doesn't include much extra info becase it will
be in actual task/function declaration.
Kev.
> 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! ***
-- National Semiconductor, Tel: (408) 721 3251 2900 Semiconductor Drive, Mail Stop D3-500, Santa Clara, CA 95052-8090
This archive was generated by hypermail 2b28 : Mon Dec 16 2002 - 15:54:26 PST