Subject: Re: DirectC: C layer - call by value vs. reference
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Tue Dec 17 2002 - 11:23:25 PST
> From john_stickley@mentorg.com Tue Dec 17 10:53:16 2002
>
> Kevin,
>
> Kevin Cameron wrote:
> >
> > 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.
>
> johnS:
> My feeling is that copy-in of input arguments is just as susceptible to
> crashes as pass by const * ref. In fact one can argue more because
> if the C code is going to overindex the argument on stack vs. in memory
> somewhere, stack crashes are often the most evil type !
>
> So, assuming that is a wash, I would err on the side of the calling convention
> that has the most performance potential which is const * ref.
"const" is not enforcable. Anyway, my proposal gives you two options you can pick
which you get by swapping "input" to "inout". "input" allows you to match C calling
conventions for C calls needing pass-by-value.
Passing by reference (pointer) probably requires to an intermediate call layer
in the simulator:
SV:
extern int foo(inout struct bar);
SV simulator C (equiv):
int call_foo(struct intrnl_bar *data) {
struct c_bar c_data; // C canonical
int r;
... // copy *data to c_data
r = foo(&c_data);
... // copy c_data back to *data
return r;
}
User C:
int foo(struct c_bar *data) {
...
}
- so the data ends up in the same place on the stack either way.
Kev.
> >
> >
> >>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.
> >
>
> johnS:
> I don't feel strongly for what syntax is used. But I do feel strongly that we
> use standard function call syntax rather that matches the SV language rather
> than something specific to a C interface. Which, I think is what you're saying
> here also and what Michael is also saying.
>
> >
> >>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.
>
> johnS:
> I think in general that Andrezj's proposal is not inconsistent with having
> calling semantics of C function calls match those of the basic SV language.
> The abstract vs. direct issue only affects the C layer side not the SV caller side.
>
> >
> > 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 email may contain material that is confidential, privileged
> and/or attorney work product for the sole use of the intended
> recipient. Any review, reliance or distribution by others or
> forwarding without express permission is strictly prohibited.
> If you are not the intended recipient, please contact the sender
> and delete all copies.
> __
> ______ | \
> ______________________/ \__ / \
> \ H Dome ___/ |
> John Stickley E | a __ ___/ / \____
> Principal Engineer l | l | \ /
> Verification Solutions Group | f | \/ ____
> Mentor Graphics Corp. - MED C \ -- / /
> 17 E. Cedar Place a \ __/ / /
> Ramsey, NJ 07446 p | / ___/
> | / /
> mailto:John_Stickley@mentor.com \ /
> Phone: (201)818-2585 \ /
> ---------
>
>
This archive was generated by hypermail 2b28 : Tue Dec 17 2002 - 11:24:01 PST