Subject: Re: Proposal Update
From: Stickley, John (john_stickley@mentorg.com)
Date: Tue Dec 17 2002 - 12:06:44 PST
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.
2. What I've stated above assumes dynamic binding is needed.
I seriously question this. Let me forumate 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).
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.
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.
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.
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.
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 ?
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.
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 - 12:10:44 PST