Subject: Re: Vote on Kevin's proposal
From: Stickley, John (john_stickley@mentorg.com)
Date: Sun Dec 22 2002 - 11:46:47 PST
I vote "no" on accepting 1.1b in its current form
mainly because,
1. I don't think dynamic binding is needed in first version
of the C calling interface.
2. Even if it were, a significantly simpler dynamic binding
scheme can be realized than what Kevin proposes.
I would also like to say that I carefully went over Kevin's
detailed examples on how the interface would be used.
These examples demonstrate a complex technique for dynamically
binding C++ functions where the code itself requires knowledge
of the name mangling schemes of specific C++ compiler
environments. This, in my view, is unacceptible.
Here are my other main objections to it:
1. We don't need both a "call forward" "register locator"
*and* a "call back" binding function. All we would need is
a call forward binding function (i.e. svBind()).
2. The string parsing requirement for argument profiles
is overly complicated and buys you very little. Plus
it requires the code to have knowledge of C++ compiler
name mangling schemes and even with this, there's no
guarantee that the pointers to the functions being
bound match the profiles of the extern definitions in
the SV side. So really the type safety that it is
attempting to create, falls well short of its goal.
A static linking scheme that makes use of optional
SV compiler generated headers provides superior type
safety checking than Kevin's scheme does. The same
overall goals of the example given by Kevin can
alternately be accomplished using the static linking
scheme.
Here's how:
1. In SV code declare extern functions to Kevin's
"foo" double and "foo" int functions:
SV declarations:
----------------
extern context "foo_double" integer foo( real arg );
extern context "foo_int" integer foo( integer arg );
In this case foo_double() and foo_int() are extern "C"
linkage wrappers for the real overloaded C++ variants
of these functions shown in Kevin's example.
Now, on the C side, you can still use dlopen() and dlsym()
to look up the functions as Kevin shows. But what you
do is set pointers that the C wrappers call.
Here you've created application level dynamic binding
capability from static capability with very little
added overhead and with no name mangling interpretation
required.
A better designed, more compact object oriented scheme
could also be used but here I just used a rudimentry
scheme to follow with the flow of Kevin's example.
Optional SV compiler generated header sv_decls.h:
-------------------------------------------------
extern "C" {
extern int foo_double( svHandle context, double arg );
extern int foo_int ( svHandle context, int arg );
};
test.c:
-------
// Define pointers to the real C++ functions here:
static int (*real_foo_double)( svHandle context, double arg );
static int (*real_foo_int) ( svHandle context, int arg );
// Define the wrappers here that will be directly called
// from SV, which then call the real C++ functions.
extern "C" {
int foo_double( svHandle context, double arg ){
return (*real_foo_double)( context, arg ); }
int foo_int( svHandle context, int arg ){
return (*real_foo_int)( context, arg ); }
void (*bindMyFoos)( void *, void *); // "Locator" function pointer.
};
main(){
// Dynamically load code library containing real functions:
void *lib = dlopen("./liblib.so",RTLD_NOW); // Open dynamic library
// Now look up and call "locator" function that, itself,
// is an extern "C" function.
bindMyFoos = dlsym(lib,"BindMyFoos");
(*bindMyFoos)( (void *)&real_foo_double, (void *)&real_foo_int );
...
}
Dynamically loaded lib.cc:
--------------------------
// Here are the real C++ foo functions:
int foo( svHandle context, double arg ) {
fprintf(stderr,"Called (double)\n");
return arg * ((user_struct *)(svGetUserData(context))->dbl;
}
int foo( svHandle context ,int arg ) {
fprintf(stderr,"Called (int)\n");
return arg * ((user_struct *)(svGetUserData(context))->data[0];
}
typedef int (*foo_double_type)(svContext context, double arg );
typedef int (*foo_int_type) (svContext context, int arg );
extern "C" {
void BindMyFoos( void *real_foo_double, void *real_foo_int ){
// This assignments will pick correct variants of foo
// according to Stroustrup $r.13.3
*((foo_double_type *)real_foo_double) = &foo;
*( (foo_int_type *)real_foo_int) = &foo;
}
};
Note that this is just as efficient as Kevin's example with
two added benefits:
1. No need for knowledge of compiler specific mangling schemes
2. No dynamic binding needed in DirectC API. Can be handled
completely at application layer if required.
-- johnS
Warmke, Doug wrote:
> Team,
>
> I believe today is the deadline for voting on Kevin's proposal.
> Kevin requested an extension this week but there was no reply
> from either Ghassan or Swapnajit.
>
> If there is no extension, my vote on the proposal is "no".
>
> I feel the complexity is too high and therefore it is not
> in the spirit of the original DirectC requirements,
> "convenience and performance". Also the proposal is making
> too many assumptions regarding the rest of SV 3.1 which
> may or may not come true.
>
> Thanks for all the work you did on it, Kevin.
> I'm sorry I couldn't go with you on this one.
>
> Regards,
> Doug Warmke
--
__
______ | \
______________________/ \__ / \
\ 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 : Sun Dec 22 2002 - 11:54:31 PST