Subject: Re: Proposal Update
From: Stickley, John (john_stickley@mentorg.com)
Date: Tue Dec 17 2002 - 14:51:30 PST
Kevin,
Kevin Cameron x3251 wrote:
>>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.
johnS:
Since this type of thing is only done at init time and not
continually at run time, there's really negligible difference.
Even if we're talking about 1000 functions and each 1 takes
1 ms to bind (should be far less) and we only use 10 of those
functions, it only took 1 second to bind all 1000 of them before
the simulation starts.
Of course with static linking it takes 0 seconds at run-time !
>
>
>>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.
johnS:
You should be able to use dlopen to load such
libraries and call function pointers derived
from dlsym() from your C linkeage functions.
Would this work in your environment ?
>
>
>>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.
johnS:
As I see it, whether you dyamically link a C++ friend function
or statically link a C function, you still only need
1 level of indirection to get at your context.
>
>
>>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.
johnS
That's why ...
>
>
>>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.
>
... I did not want to cloud the issue. C linkeage will support
what you're describing. Also, even if you used C++ linkeage,
it is not too far fetched for vendors to supply multiple binary
object libraries compiled for different compiler environments.
So, one of those two schemes, either C linkeage or multiple
binaries should meet the requirement and still only require
static linking.
>
> 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.
johnS:
So here I guess you're assuming the C code has to parse the
profile strings then form form mangled names knowing the C
compiler's mangling scheme up front, then use dlsym() to look
up those symbols ?
This does not seem too portable to me. Isn't there an easier
way ?
>
>
>>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.
johnS:
That would be helpful. Perhaps if you sent it as a separate
example from your proposal.
>
>
>>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.
johnS:
Exactly as you show here except with the following change:
int foo( const cs *data ){
...
}
-- johnS
>
>
> 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 email may contain material that is confidential, privileged and/or attorney work product for the sole use of the intended recipient. Any review, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. __ ______ | \ ______________________/ \__ / \ \ 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:55:53 PST