Subject: Re: Context Sensitive Function Calls - more constrains
From: Stickley, John (john_stickley@mentorg.com)
Date: Wed Nov 27 2002 - 13:48:02 PST
Team,
I agree with what Andrzej is stating here. I would add that supporting
function
types with different parametrized bounds on array types does not violate
this
provided array types are accessed via the abstract access interface
rather than
the direct access interface.
In such cases the C function profiles will not change for different
parametrizations
since such arguments would be represented by handles.
As for "type" parametrizations mentioned by Andrzej below, I agree that it
should be illegal to export functions that depend such types. The only
way to
do this would be to concoct a way to make use of C++ templates to solve this
which I think is way beyond the scope of what we really need for a useful
interface.
-- johnS
Andrzej Litwiniuk wrote:
>IMO some constrains should be put on the exported SV functions (to be
>called from C).
>
>If a module is parametrized (with defparams, or type parameters),
>then a function defined inside such a module may have different signature
>(i.e. different result type or types of formal arguments) for different
>instances.
>
>Please remember that SV allows not only to use different constants
>as module's parameters (what would in the worst case affect only bounds/sizes
>of arrays/vectors), but also "type" parameter, what can make function
>headers absolutely incompatible across different instances.
>
>Thereofore it should be an error to export a function such that
>its signature may vary from an instance to an instance.
>
>I propose to impose rigid constraints:
>
> The function header for exported a function
> must not depend on module's parameters.
>
>Note that the above restriction eliminates any possibility for
>variations in a function's header.
>
>This may seem to restrictive if for a particular design all instances
>of a module share the same function header.
>On the other hand, it would be confusing, if - with less rigid constrains -
>an addition of a new instance (with another value of module's parameters)
>would invalidate otherwise correct a design because it would create
>a clone of the exported function with the header inconsitent with
>headers of the same function from other instances.
>
>Note, however, that functions defined in $root scope are not subject
>to these problems.
>
>Andrzej
>
>
>
--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 Nov 27 2002 - 13:52:41 PST