Subject: [sv-cc] open issue: exported function = virtual function?
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Wed Mar 26 2003 - 11:05:32 PST
Team,
While revising the SV layer of DPI and nit-picking, I noticed that
some restrictions for exported functions seemed to be missing.
For imported functions the same "type signature" is required and most likely
something like this is needed for exported functions.
In "1.3 Global name space ..." we have:
"Each exported function must have a unique name". (Wrote it myself:-)
Does it mean 1-1 mapping? "For each cname of an exported function there must be
exactly one source code definition of the exported function"?
This led to a more fundamental issue: do we want the exported functions
to be virtual functions?
Initially our intent was (and perhaps still is) to have =one= SV function
per exported cname. In other words, there will be one source code definition
(SV implementation) of each exported function.
Conceptually such a function will have its own declaration in every instance
of a module that contains the function's definition (just like in any
block-structure programming language).
In the simple scenarios all 'instances' of a function declaration will share
the same executable code (and, of course, the same source code).
Hence the C programmer will know where to look for a SV source code of
an exported function called from C.
The same function executed with different instances will access different data,
what is our primary goal, but usually the same code will be executed.
It may happen, however, that the same source code definition of a function
will give rise to several specialized versions (clones) of the code.
It may happen because of the reasons transparent to the users, like compiler
optimizations, or because of more visible factors, like parameters, defparams,
type parameters.
This is where the restriction "unique signature per exported cname" comes
to the picture. (It somehow didn't make into LRM).
Presumably the sole intent of such restriction "one signature per cname"
is the correctness. For C code only the signature of the exported function
matters. Same C code must be used for a call of an exported functions,
regardless of the instance, and consequently, regardless of the eventual
SV code to be executed. It is SV implementation's job to identify the
right code for a given instance.
Susprisingly (for me, Joao wasn't surprised at all!) the restriction
"one signature per cname" does =not= mean "one source code per cname".
Actually, it doesn't matter what was the source code, as long as the signature
matches. SV implementation will have to identify the right code anyway.
So it is conceivable to export =different= SV functions under the same cname,
as long as they have same signature.
Therefore different SV source code definitions will correspond to the same
name, and the right definition will be picked up on per-instance base.
Isn't it a mechanism of virtual functions?
Implementation wise, I don't see any issues.
It could become, however, an issue for C programmers, with debugging their mixed
C/SV code, that a single function may have different definitions (this is
typical in OO world, but not in the oldfashioned world of C).
The sole issue is: do we want such a mechanism of virtual SV functions?
I'm not sure, but we may need to accept it because of exports in 'generate'.
It's kind of funny, how a tiny understatement opens a door to a bigger problem.
Regards,
Andrzej
This archive was generated by hypermail 2b28 : Wed Mar 26 2003 - 11:06:59 PST