Subject: Re: [sv-cc] svPut/GetUserData()
From: Stickley, John (john_stickley@mentorg.com)
Date: Tue Mar 18 2003 - 20:12:21 PST
Andrzej,
Andrzej Litwiniuk wrote:
> John,
>
> I've got a question concerning svGetUserData(). I'm not sure I understand
> how it's supposed to work.
>
> void* svGetUserData();
> // Returns user context for current extern'ed function
> // of current scope
>
> Note that a function (the current extern context func) is only implicit
> here.
> You can set the scope to a different scope, by calling svPutScope(), but
> you cannot set a different function. That way svGetUserData() cannot be
> used in call chains that contain more than one context function. (The same
> function could be legitimately called both from SV and from C).
> Your example didn't help me much.
johnS:
In the new proposal there will be a call that can be called from
each imported function in the call chain that returns a handle
denoting the current function scope. This call is,
svScope svGetFunctionScope();
Its semantics are identical to svGetScope() except that it returns
a function scope rather than a module scope for the benefit of
applications that need to know specifically the function scope.
Either type of handle can be passed into svGetUserData().
Have a look at my new example and tell me if it makes sense.
>
> public:
> MyCModel( const char *svModulePath ){
> dSvScope = svGetScopeByName( svModulePath );
> svPutUserData( dSvScope, "MyExternedCFunc", this );
> } // This function is called from SV ...
>
> friend void MyExternedCFunc( args ... ){
> MyCModel *me = (MyCModel *)svGetUserData(); // <- No args !!!
>
> me->processArgs( args ... );
> }
>
>
> It's my guesswork only that SV compiler shall instrument a call to a
> context
> function by setting some global variable that would identify the function
> being called. Then, svGetUserData() will fetch this global variable and
> will
> calculate the right mapping: (instance x function_name) ---> user_data
>
> Is it how you envisioned it?
johnS:
Yes, that's how I envisioned it. But the latest proposal that I just
sent out now only retreives the user data from an explicity passed
function or module scope. So it does not do the implicit mapping
that you show above.
i.e.,
void *svGetUserData( svScope scope );
where scope denotes the handle of either a function or a module
depending on which type the application is interested in using.
>
> I've got a couple of questions. (Please ignore them if I got it wrong!)
>
> - Wouldn't a pointer to a function be a more efficient key than a function
> name?
johnS:
In the new proposal what we do this to get the current function scope as,
svScope svGetFunctionScope();
The only place we pass a name is into the new function,
svScope svGetFunctionScopeFromName(svScope moduleScope, const char *cname);
This function, like our existing svGetScopeFromName() would typically
be called at initialization time and therefore the overhead would
not be a factor. At init time you would call these functions and
store the handles where they can be efficiently accessed frequently
at run-time as needed.
>
> - Why to bear some overhead, even if tiny, for extern context calls which
> may not use that functionality?
johnS:
In the new proposal the function scopes don't have to be used in cases
where just module scope association with user data is needed.
The current module scope capability will continue to be supported.
>
> - If all my extern context functions share the same data per instance,
> will it be necessary to 'register' each of them separately, by
> calling svPutUserData(dSvScope, func_name, shared_data) for each
> function?
johnS:
No. See above.
>
> - A function cannot fetch another function's data, since a function
> is available to svGetUserData() only implicitly and cannot be
> switched to
> another one. So, if several functions are to share the same instance
> specific
> data (say, a pointer to C/C++ structure/object),
> then svPutUserData(..., shared_data) must be called for all of them
> with the same data. If you don't have access to the original data,
> you cannot later add another function that would share the same data!
>
johnS:
Yes, I think the new proposal fixes this. Tell me if you agree.
>
> Thanks and regards,
> Andrzej
>
-- 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 \ /
Phone: (201)818-2585 \ /
---------
This archive was generated by hypermail 2b28 : Tue Mar 18 2003 - 20:14:40 PST