Subject: Re: DirectC: C layer - call by value vs. reference
From: Stickley, John (john_stickley@mentorg.com)
Date: Tue Dec 17 2002 - 10:52:06 PST
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.
>
>
>>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 - 10:56:07 PST