Subject: Re: [sv-cc] open issue: exported function = virtual function?
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Thu Mar 27 2003 - 09:14:32 PST
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).
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:16:13 PST