Subject: RE: [sv-cc] open issue: exported function = virtual function?
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Thu Mar 27 2003 - 09:43:44 PST
Andrzej,
Thanks for this recap.
Please see below.
> -----Original Message-----
> From: Andrzej Litwiniuk [mailto:Andrzej.Litwiniuk@synopsys.com]
> Sent: Thursday, March 27, 2003 9:15 AM
> To: fm@cadence.com
> Cc: sv-cc@server.eda.org
> Subject: Re: [sv-cc] open issue: exported function = virtual function?
>
>
> Team,
>
> > [...] Andrzej's "virtual export function" proposal [...]
>
> This is not my proposal:-) This is my question.
>
>
> The question is: should more than one source code defintion
> be permitted
> per cname of an exported function?
>
> One of the two possible solutions must be chosen:
>
> (NO) Only one SV function may be exported with any cname.
> It is illegal to export two functions with the same (implicit or
> explicit) cname.
>
> (YES) Multiple export declarations are allowed with the same
> (implicit or
> explicit) cname, as long as they are in different
> scopes and have
> the same type signature (as defined in 1.4.4 for
> imported functions).
We (MTI) vote (YES) on this one.
Restricting such multiple declarations wouldn't be too hard.
However, as you say, we will likely have to handle this situation
anyways in cases where one module containing a given cname export
function turns into several different variants, due to parameter
expansion for example.
No reason to be overly restrictive here in our view.
However, if everyone else wants to be restrictive,
it won't be that big of a deal.
Regards,
Doug
>
>
>
> The above issue arose as an effect of nit-picking and
> exegesis of DPI LRM
> rather than as a conscious proposal.
>
>
> Implementation-wise, there are only two restrictions and they
> are not conclusive
> with respect to the issue in matter.
>
> 1. C implementation requires that there will be only one
> signature for each
> cname of exported functions.
> Selecting the code to be executed will be a task of a
> wrapper function
> generated for an exported function, anyway.
> Therefore many function definitions with the same
> signature are acceptable.
>
> 2. SV implementation requires that no scope will export two functions
> with the same cname, because for each instance there must
> be unambiguous
> mapping from cname to function's code (note: 'code' not
> 'definition').
>
>
>
>
>
> I don't have clear opinion, though I may be a little in
> favour for (YES).
> Cannot see any issues with implementation of either solution.
> A support for sort of virtual functions will be needed anyway.
> Don't forget that a single source code function definition
> may result in
> several clones, because of type parameters, defparams,
> generate, optimizations.
>
>
> Pro:
> - the fewer restrictions, the better
> - multiplicity of function definitions may exist anyway, as
> a result of cloning
> or generate
> Against
> - may be confusing for C programmers (?)
>
>
>
>
> > Remember that the cname is optional, and most likely will
> not be provided
> > since the SV function name is a legal C function name.
>
> Francoise, you seem to ignore the scenario in which the same
> SV name is
> defined - and exported! - in different scopes yet with the
> same signature.
> There will be no conflicts from SV point of view!
>
>
> > If provided it is just a C aliased name for the SV function.
> > If we start by allowing same cname for multiple export
> functions, then we
> > reintroduce
> > a complex binding mechanism which was not the original goal of DPI.
> > The original goal was simple default binding between SV and
> C to avoid
> > complex binding and registration of C functions.
> >
> > Francoise
>
> Answer (YES) does not add to the complexity of
> implementation. It may only
> make things more complex conceptually, see "Against'.
>
>
> > >I'm inclined to only allow cnames to map to 1 exported
> > >function, although I understand your desire to support
> > >a virtual function of sorts.
>
> For the record: it wasn't my desire. It was my conclusion
> that LRM as it was
> did not exclude it and we were unaware of it.
>
>
> > >If we allow this I have concerns that the SV compiler
> > >generated code wrappers for the exported functions will
> > >have to decide which SV code to call based on the
> > >module scope setting. This may add extra overhead.
>
> This burden is here anyway, because of cloning.
>
>
> > >Since SV does not support a similar "virtual function"
> > >feature - at least in module scopes, I don't think
> > >we should introduce one.
> > >
> > >-- johnS
>
>
> Summary:
> IMO our decision should be driven mainly by methodological
> criteria, clarity, usefulness, etc.
> There seems to be no technical issues with the implementation.
>
>
> Regards,
> Andrzej
>
This archive was generated by hypermail 2b28 : Thu Mar 27 2003 - 09:48:15 PST