Subject: Re: Proposal Update
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Tue Dec 17 2002 - 14:12:33 PST
> From john_stickley@mentorg.com Tue Dec 17 12:08:10 2002
>
> Kevin,
>
> I had a few general comments on on your presentation
> today and your proposal in general.
>
> 1. It's not clear why you need both a "call forward"
> "register locator" and a "call back" binding funciton.
> Since you're already acknowledging that you need to
> call forward to register your locator in the first
> place, why not just have a series of call forward function
> calls to an "svBind()" API call that are used to dynamically
> bind each function coupling that is needed. This would
> simplify your interface by a factor of 2X - only one
> call needed not two.
You could do it with an svBind, but that would require registering
and loading all external functions whether used or not. The 2-step
scheme is meant to reduce the amount of work and defer loading
dynamic libraries in case they are not needed.
> 2. What I've stated above assumes dynamic binding is needed.
> I seriously question this. Let me formulate what I think to
> be the overall requirements here:
>
> a) Need to be able to interface C++ or C models to SV
> b) Need to be able to accomondate different C++ compiler
> environments
> c) May even need to be able to accomodate distribution of
> binary C libraries which may contain C++ and for which
> we don't know what compiler was used.
>
> I will make a case that statically linked functions
> using C linkeage will adequately serve all of these
> requirements and will be much simpler for the user
> to use (and fits the "explain in under 5 minutes"
> requirement).
>
National already uses dynamically loaded C++ libraries with
it's Verilog.
> You can do both of the following with static linking:
>
> - Implement extern "C" linkeage function bodies in C++
> - Pass an extern "C" linkeage functions a context pointer
> that gives it access to a C++ model via its public
> interface by using simple downcasting in the function's
> body.
>
> Using these two techniques, you can fully and completely
> open up the whole wide world of C++ to SV applications.
Anything that has to use an extra layer of C call to map
the name is a) less efficient, and b) more prone to name
clashes.
> Furthermore if you're willing to relax requirement c)
> of distributing binary objects of unknown compiler heritage,
> there are ways of even directly specifying functions with
> C++ linkeage - assuming you can allow the user to pre-specify
> his or her compiler environment. That environment could then
> be used to compile any SV compiler generated wrapper code
> which could then directly reference functions using C++
> linkeage.
True, but that puts an onus on the vendor. The dynamic linking
scheme I proposed puts the onus on the user (me) to write the
code that maps the binding call for the C++ compiler I choose
to use.
It's a big plus not to have to recompile anything to make this
stuff work.
> But I don't want to cloud the issue further with this since
> I think requiring C linkeage will, at a minimum, completely fit
> the requirements.
Not sufficiently for our interests.
NB: Most of the hard work is being done by user code not SV code in
my proposal anyway.
> 3. I have concerns about the complexity and unconventional
> aspects of your string based argument specifications. Even if
> we choose to support dynamic binding API functions (which as
> I've said is questionable) it is totally unecessary to use this
> conconcted string syntax at run-time. There's no reason you
> cannot pass the pointer to a C++ function directly to a simplified
> svBind() function such as I described above. I.e. register
> a function pointer and presto, be done with it. Let optional
> generated headers do the rest as far as argument profile checking.
The argument type strings allow C++ mangled names to be generated,
and so support C++ overloading. I.e. the style of C++ is not
artificially restricted.
> Also, it is not clear from your example how your "myBinder"
> callback functions are using the string argument syntax to
> actually check function's arg profile for compliance ? Can
> you show us an example of how that would be done ?
I can do a full code example if that will help. I left argument
checking out of the proposal example since it would have
over-complicated it.
> 4. Requiring copy-by-value semantics for input arguments.
> As you know from my previous e-mails, I don't agree with this.
> See those e-mail for more explanation of why.
That allows you to match C semantics, e.g. if the C routine is
typedef struct {
int i;
double r;
} cs;
int foo (cs data) {
...
}
The SV spec could be:
struct cs {
int i;
real r;
};
extern foo (input cs data);
I'm not sure how else you could specify it.
I know folks don't like the complexity, but I think it is required
to solve the various problems of dynamic loading and C++.
Regards,
Kev.
> Kevin Cameron x3251 wrote:
> >
> > I think I have this fairly complete now. Latest additions are:
> >
> > Scoping rules for extern.
> > Support pass-by-value and pass-by-reference, with type coercion for pass
> > by value
> > for SV types on arguments and return values (follows from Andrzej's
> > proposal).
> > Note on type promotion.
> >
> > Note: I renamed "vec32" to "svcInteger"since vec32 seemed rather short
> > and not
> > SV specific. That and other types I expect to go in an appendix later.
> >
> >
> > On the question of when you bind dynamic routines:
> >
> > You can bind a routine any time between its SV context being created and
> > actually
> > calling it. The cheaper options are to bind when the context is created
> > or on the
> > the first call. Doing it directly after elaboration has some advantages
> > but has extra
> > overhead. Doing it on the first call can be implemented by using an
> > "extended"
> > context that includes the routine pointer:
> >
> > svcContextIntrnl {
> > void (*func_or_bind)(handle,svcContext...);
> > svcContext cntxt; /* external context */
> > } CI;
> >
> > The simulator always calls (*CI.func_or_bind)(&CI.cntxt) but the initial
> > value of
> > func_or_bind is a call to a loader routine which locates the right
> > routine and
> > updates func_or_bind. This kind of thing is usually refered to as "lazy"
> > loading
> > and has the downside that it may be (too?) late before you find the
> > object code
> > is not available, the upside is that DLLs don't get loaded until they
> > are actually
> > needed (faster startup, lower memory usage).
> >
> > Note: for lazy binding the user_context field of CI.cntxt can be used
> > to save data
> > from elaboration time.
> >
> > Since my interest is in linking C++ I'm assuming that I can use static
> > constructors
> > to register locator functions. If you are just using C you won't need
> > the locator
> > functions (so there isn't a problem).
> >
> > Regards,
> > Kev.
>
> __
> ______ | \
> ______________________/ \__ / \
> \ 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 : Tue Dec 17 2002 - 14:13:15 PST