Subject: Re: [sv-cc] Updated extern/exports proposal
From: Stickley, John (john_stickley@mentorg.com)
Date: Wed Mar 12 2003 - 15:00:23 PST
Joao,
That sounds reasonsable. If I understand what you're saying,
this only affects the C-layer so is not subject to our Friday
deadline is that correct ?
BTW, I carefully read over your proposal and it really looks
good to me. I have no additional feedback that has not already
been covered by others.
-- johnS
Joao Geada wrote:
> John, Doug:
>
> If I may, I would like to separate this discussion from the export/extern
> proposal. The urgent item right is to reach full agreement on the language side
> changes (language BNF) for the export/extern syntax and semantics. The details on
> what functionality is exposed/provided by the C side layer belongs to just our
> committee and we have a little more time to finish that part.
>
> Is that acceptable?
>
> Thanks,
>
> Joao
> ==============================================================================
> Joao Geada, PhD Principal Engineer Verif Tech Group
> Synopsys, Inc TEL: (508) 263-8083
> 344 Simarano Drive, Suite 300, FAX: (508) 263-8069
> Marlboro, MA 01752, USA
> ==============================================================================
>
>
> -----Original Message-----
> From: Stickley, John [mailto:john_stickley@mentorg.com]
> Sent: Wednesday, March 12, 2003 5:36 PM
> To: Warmke, Doug
> Cc: 'Joao.Geada@synopsys.com'; sv-cc
> Subject: Re: [sv-cc] Updated extern/exports proposal
>
>
> Doug,
>
> Warmke, Doug wrote:
>
>>2) The purvue of the user data should be per-function,
>> rather than per-scope. Otherwise it will be impossible
>> to mix completely independent external context functions
>> within the same module scope.
>
>
> johnS:
> This is the solution I had in mind when we discussed
> this issue in today's meeting. You should have spoken up !
> Anyway, it was decided to discuss by e-mail.
>
> To clarify what I think you are saying, we need
> svPut/GetUserData() to take a second argument
> in addition to the svScope, namely, the function name
> - as a string I guess. Does that make sense ?
>
> Something like this:
>
> void* svGetUserData(const svScope, const char *cname );
>
> void svPutUserData( const svScope, const char *cname, void * );
>
> where cname is the 'cname' in one of the extern declarations
> given in the scope (or the fname if aliasing is not used).
>
> Is this what you were thinking Doug ? It seems to be
> to be a fairly simple solution.
>
>
>> This is a trade-off and may be an opinion-call.
>>
>> As you have defined it (user data shared by all extern
>> functions in the scope) it is convenient for implementors
>> of sets of related external functions. However, if there
>> are multiple independent external context functions
>> declared in the same module scope, they couldn't
>> co-exist. (Similar to having multiple UNIX signal
>> handlers all on SIGINT, but *no* handler-chaining
>> mechanism defined so that they can co-exist).
>>
>
> > [...]
>
> -- 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 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 : Wed Mar 12 2003 - 15:01:49 PST