Subject: RE: Modified Proposal for Context Sensitive Function Calls
From: Amouroux, John (john_amouroux@mentorg.com)
Date: Wed Nov 20 2002 - 07:55:11 PST
John,
I like your new proposal especially because no new pli's need to be created,
but I don't understand your reply to Kevin below. In your context-sensitive
C function you always need to call tf_igetworkarea and tf_getinstance on
each function invocation, which I don't understand how to optimize in the
wrapper functions you mentioned. Can you explain this better for me?
The merit I see in Kevin's approach is that in the simulator I can see how
to efficiently pass in a pli handle and C context pointer directly from SV,
as these data structures could naturally be stored in the simulator's
instance-specific work area (thus requiring no run-time mapping or name
lookup).
Regards,
Johnny
-----Original Message-----
From: Stickley, John
Sent: Tuesday, November 19, 2002 6:37 PM
To: Kevin Cameron x3251
Cc: sv-cc@server.eda.org
Subject: Re: Modified Proposal for Context Sensitive Function Calls
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
__
______ | \
______________________/ \__ / \
\ 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 <mailto:John_Stickley@mentor.com> \
/
Phone: (201)818-2585 \ /
---------
This archive was generated by hypermail 2b28 : Wed Nov 20 2002 - 07:56:23 PST