Subject: Re: Extended (dynamic) linking
From: Stickley, John (john_stickley@mentorg.com)
Date: Wed Nov 27 2002 - 17:50:08 PST
Kevin,
I would like to address a number of issues that you've raised and then
show how, aside from dynamic binding, those issues might already be
handled with my proposal.
Comments embedded.
Kevin Cameron x3251 wrote:
[http://www.eda.org/sv-cc/hm/att-0380/
<http://www.eda.org/sv-cc/hm/att-0380/> ]
The basic (C) linking functionality of my proposal is the same as John's
except that
I don't have an optional context on calls from C to SV (it's always the
pli handle of
the instance - which may be $root). The use of '*' in extern argument
lists does not
imply that SV supports pointers in general, only that it understands
what a C call's
interface is (it would be nice to use the same definitions as C so that
there is no
need to copy and edit), once the EC agrees on how to do references we
can finalize
that syntax (noting references are part of the testbench donation, but
the syntax is
inconsistent).
johnS:
So the point you're making is that we don't need optional context on
C-to-SV calls.
I think I also agree that this is not necessary (see my e-mail earlier
this
week to Andrezj). A call from C-to-SV always requires some context.
Most of the time it will be instance specific PLI handles. "Free
functions"
are equivalent to calling and SV function in root context which will
have its
own PLI handle.
Kevin Cameron x3251 wrote:
The "extended" linking behavior allows linking of foreign languages that
do not
have standard C entry points e.g. C++ which mangles names so that
routines have
a unique entry-point for each (overloaded) argument set. Since the name
mangling
in C++ is different for different compilers it is difficult to predicate
what the "C"
name should be for binding at link time.
johnS:
I thought some more about this. The good news is that I think you can
still have C++ linkeage and support argument overloading even with
a static linking approach.
The SV compiler will need to generate some C code wrapper that actually
makes the C call (in SV-to-C direction). Either scheme requires that.
So suppose the user's C++ compiler, say g++ is used to compile that SV
compiler generated code wrapper. In making the call to the C function
the
code wrapper will generate a reference to the appropriately mangled
symbol
since g++ automatically makes this happen based on the call site.
Therefore linkage would occur correctly and naturally using whatever
name mangling scheme that compiler happens to use.
By doing this, C++ linkage could be automatically supported. So we can
then allow C functions called from SV to actually have private access to
user defined C++ model classes (what you called "shadow_class" in
your example) by using friend functions.
I've revised your example so show how this can be done.
C Code:
class shadow_class {
private:
void method( int data );
friend void friend_cpp_method( int data );
};
void friend_cpp_method( int data ){
shadow_class *me = (shadow_class *)tf_igetworkarea( tf_getinstance()
);
me->method(data);
}
I will argue that, if implemented properly, this is just as efficient as
the dynamic
variant that you show here:
Kevin Cameron x3251 wrote:
The dynamically bound routine can skip the context test (which is
handled during
binding) and can find a per-instance version of cpp_method so the code
is like:
void cpp_method_2(handle ip,svcContext *p_context,int data)
{
shadow_class_2 *cp = (shadow_class_2
*)p_context.user_context.ptr;
cp->method(data); // call method (direct)
}
Since the class shadow_class_2 is specific to the instance "method" does
not
have to be virtual.
johnS:
Here's the associated SV code that shows a declaration that supports C++
linkage:
SV Code:
extern void cpp_method( input integer data ) "friend_cpp_method";
The SV compiler generates a wrapper with a direct call to
friend_cpp_method() with an appropriate argument profile that is
declared
as follows (translated using implied type mapping from SV extern
declaration):
extern void friend_cpp_method( int data );
The wrapper then makes the call to this function passing the appropriate
argument data.
The user's C++ compiler that compiles the wrapper will
naturally perform appropriate mangling, arg overloading, and external
symbol referencing.
Furthermore it will automatically type check the arguments since, if
there is no
match, an unresolved symbol will occur at link time.
Kevin Cameron x3251 wrote:
The sequence for dynamic linking (with VCS) is something like:
Compile Verilog:
Compiler will note external calls.
Link code:
Use a C++ linker if foreign code is C++ (SystemC)
Run simulation:
C++ static constructors get called for permanent data (see test
below),
register binders.
Simulator main() gets called.
Elaborate design. Call "binder" function for foreign routines as
encountered
(per instance) or post elaboration.
Start simulation.
The "binder" functions may be C++ functions (name mangled) since they
are
passed through the C registration interface as pointers. When the binder
functions
are called they can use the call arguments to ensure an exact match
between
SV and C and to select between multiple (overloaded) versions of calls.
johnS:
So this really gets down to the one big difference in our proposals:
Is dynamic binding needed ?
First of all, I would like to say that if it is needed, that we add it
as a capability on top of static binding as I've proposed, which is
what I think you've already stated.
Secondly, if the answer is yes, then we must conceed that this requires
a brand new API call where one never existed before. So far, with
everything I've proposed including the latest stuff shown above, still
no
new API call is required.
Thirdly, I would like to suggest the the dynamic "binder" function,
if we agree it is necessary, is something more minimalist like this:
void SvccBindSVtoCFunc( "MySvModule::cpp_method", friend_cpp_method );
Conceptually this allows the C side to perform the aliasing instead of
the "cname"
part of the extern declaration on the SV side.
It really needs no more than this. I think you can still do context
pointer
handling the same way that I do it in the static binding proposal (i.e.
using tf_getinstance(), etc.).
So really all we're doing is specifying a pointer in place of a dynamic
symbol reference.
One thing that gets tricky however, is how does the SV compiler know
to generate a dynamic call or a static call in its wrapper ? Do we need
another
extern attribute called dynamic ?
Actually now that I think about it, perhaps it is as simple as this:
We say if "cname" exists, static binding is implied.
If it does not exist, dynamic binding is implied.
Does this work ?
Admittedly, dynamic binding probably has some merits. But, as I said,
we would have to conceed to creating an API where one did not
otherwise exist.
Also, one thing you state here:
Kevin Cameron x3251 wrote:
So the benefits of the dynamic binding mechanism are a) handles non-C
foreign languages, b) arguments can be checked for compatibilty, c) more
efficient run-time calling with instance specific functions, d) doesn't
add
exported names to C name space (less chance of a name clash).
johnS:
It's not quite clear to me how b) works. It seems to me
that in the description I gave above using static binding,
you can rely on the C compiler to automatically check
arguments. But how do you do that in b) ?
johnS:
Finally one other point I would like to note is that I replaced your
svcContext struct with just a plain opaque void context pointer that is
fully
user interpreted. I this it is better not add all the info you show in a
special
C struct. Since most of the time this info is not needed and when it is,
it can be
retreived through the VPI. This makes the interface easier to understand
and explain (in under 5 minutes ;-).
-- 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 <mailto:John_Stickley@mentor.com> \
/
Phone: (201)818-2585 \ /
---------
This archive was generated by hypermail 2b28 : Wed Nov 27 2002 - 17:57:10 PST