Subject: Re: Modified Proposal for Context Sensitive Function Calls
From: Stickley, John (john_stickley@mentorg.com)
Date: Wed Nov 20 2002 - 08:09:35 PST
Johnny,
The name lookup typically only needs to be done once at bind
time. Any required instance handles can be stored with the object.
But this usage varies depending on direction (C-to-SV or SV-toC).
Let me see if I can quickly summarize the semantics here:
SV-to-C
* Bind Time (once)
* Use tf_mipname(), tf_isetworkarea() to associate C context with
instance
* Function Call Time (often)
* Use tf_getinstance(), tf_igetworkarea() to retreive C context
(note: these functions can be inlined and made pretty efficient
since there are no lookups involved - just pointer retrieval)
C-to-SV
* Bind Time (once)
* Use tf_mipname() to establish sv instance handle & store in
local C context
* Function Call Time (often)
* Pass sv instance handle directly to call - no lookups involved
-- johnS
Amouroux, John wrote:
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 <mailto: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 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 <mailto:John_Stickley@mentor.com> \ /
Phone: (201)818-2585 \ /
---------
This archive was generated by hypermail 2b28 : Wed Nov 20 2002 - 08:13:09 PST