Subject: Re: Modified Proposal for Context Sensitive Function Calls
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Wed Nov 20 2002 - 13:30:52 PST
> From joao@dhcp-146-225-131-45.synopsys.com Wed Nov 20 11:58:26 2002
>
> Kevin.Cameron@nsc.com said:
> > The converse mechanism could be used to link module (class) specific
> > routines to module instances, i.e. if a module declares an XF (rather
> > than in $root) it would be bound to a C/C++ function pointer at
> > elaboration by calling a user-supplied (PLI) routine e.g.:
>
>
> Kevin,
>
> You are assuming that "context" always means "virtual function". I am
> not sure that there is such a strong (ie unbreakable) coupling. It seems just
> as likely that all I'd want to store in the context is some "per instance" data
> and have the same one function manipulate this data: ie the context selects
> the data to work on and not what function does the work.
The "context" for a virtual function is something like the C++ "this" - you can't
have a virtual function without a context (reference). SV module function calls
are very similar to C++ virtual function calls with the context being the module
instance, but (as with C++) if you know the context you can de-virtualize as
an optimization (i.e. within SV), but external to the context (e.g. in C and
all you have is the instance handle from PLI) you cannot determine what code
is going to be called from only the module's name for the function and the
instance reference - an extra layer of dereferencing is required.
Anyway, the "converse mechanism" stuff was aimed at binding C++ (class) routines
for calling SystemC from SV.
> I personally think this is and also more generic, since if you have
> context data you can clearly implement context specific functions (as per John's
> proposal), but if all you have is context specific functions, implementing the
> simpler cases can become cumbersome.
You can always ignore the context data.
Just linking on C names doesn't set up any context. The proposed dynamic binding
scheme includes the possibility of performing context setup when binding so that
subsequent calls don't have to worry about it.
> Kevin.Cameron@nsc.com said:
> > The approaches are not mutually exclusive, it's mostly a tradeoff
> > between ease-of-use and (post elaboration) execution speed.
>
>
> As to the optimization issue: the entire difference between the approaches
> appears to be:
> a) if context is required, it has to be explicitly requested with John's
> proposal. (1 function call per invocation)
> b) dereferencing the context to get a function pointer
> Whether it happens internally or externally, this still must occur, so
> this is the same in both cases.
No, my scheme does the dereferencing at elaboration so subsequent calls
are faster.
> Note that in neither case am I accounting for the one off setup costs.
My scheme's setup costs are probably higher.
> So, yes, John's proposal may be *slightly* more expensive. However, John's
> proposal needs no new APIs, is simple to explain and is generally applicable
> to a wide domain of uses. My personal approach is to avoid premature optimizations
> (ie follow Amdahl's Law :-)) if "genericity" or simplicity would be sacrificed.
> Given free choice I'd defer choosing what to optimize until I could see what
> really mattered, and that is clearly going to be dependent on the real world
> usage of these interfaces.
I would argue my scheme is actually more general since it doesn't depend on the
linker.
> BTW: I just saw more traffic on the server on this subject. I will hold further
> comments until I see your more detailed proposal.
>
> Joao
Maybe it'll all be clearer when I do the rewrite :-)
Kev.
This archive was generated by hypermail 2b28 : Wed Nov 20 2002 - 13:31:25 PST