Subject: Re: Modified Proposal for Context Sensitive Function Calls
From: Kevin Cameron (Kevin.Cameron@nsc.com)
Date: Wed Nov 20 2002 - 11:31:50 PST
Bassam Tabbara wrote:
> Kevin to save time, and back and forth, can you perhaps prepare a presentation (by Tuesday's meeting when this issue is to be discussed) proposal that mimics John's and Joao's (preferrably same example stubs ...) so we won't have to wade through emails ?
>
> -Bassam.
I'll see what I can do.
The approaches are not mutually exclusive, it's mostly a tradeoff between ease-of-use and
(post elaboration) execution speed.
Kev.
>
> Kevin Cameron wrote:
>
>>
>>
>> "Stickley, John" wrote:
>>
>> > Kevin,
>> >
>> > Kevin Cameron x3251 wrote:
>> >
>> >> > Your approach solves this problem, however I think a more elegant
>> >> > way to solve it is, rather than to use dynamic binding as you suggest,
>> >> > to have a globally scoped "C name" indication as part of the the
>> >> > export declaration. This would be more consistent with the global
>> >> > scoping used counterpart extern declarations for the SV-to-C
>> >> > direction as was outlined by Andrezj today.
>> >> >
>> >> That still suffers from the inefficiency that you have one "C" name
>> >> for multiple (distinct) instances of the task/function, so you need
>> >> an extra level of indirection to get to the actual task or function.
>> >> Calculating the indirection may be nontrivial, so it is prefereable
>> >> to do it just once (as with the dynamic binding) rather than on
>> >> every call.
>> >>
>> >> I'll take efficiency over elegance :-)
>> >>
>> >> The dynamic binding mechanisms are also less dependent on the linker's
>> >> capabilities, avoid C name clashes entirely, and also allow checking
>> >> that the arguments match up (which C linking doesn't).
>> >>
>> >> I'm OK with the "export ... <module>::<function>" syntax (I used that
>> >> in the earlier e-mail proposal).
>> >>
>> >> Kev.
>> >>
>> > I think either approach can be implemented equally as efficiently.
>> > If I were going to implement the C-to-SV capability I would have my
>> > tool compiler generate a highly efficient, pre-compiled code wrapper stubs
>> > with the proper C names for each required (exported) function, along with a
>> > header file containing the function prototypes of the stubs that the user could
>> > include in his or her code.
>> >
>> > Now by merely calling the stub function and passing the context
>> > pointer your code will execute just as efficiently as calling the dynamically
>> > bound function pointer to the stub function.
>> >
>> > -- johnS
>> >
>> I'm afraid I have to disagree. Since your scheme has a single C-to-SV
>> entry-point per module, and mine can create an entry-point per instance
>> there is no way that your scheme will be as fast - it always has to decode
>> the instance on each call.
>> To get the same/better efficiency with your approach you would have to
>> add the instance name to the export statement.
>> There is still no way to check that arguments match if you just link by
>> C name.
>> Kev.
>>
>>
>> --
>> National Semiconductor, Tel: (408) 721 3251
>> 2900 Semiconductor Drive, Mail Stop D3-500, Santa Clara, CA 95052-8090
>
> --
> Dr. Bassam Tabbara
> Technical Manager, R&D
>
> Novas Software, Inc.
> bassam@novas.com
> (408) 467-7893
>
>
-- 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 : Wed Nov 20 2002 - 11:32:04 PST