Subject: RE: DirectC: properties/capabilities of external functions
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Wed Nov 06 2002 - 22:05:24 PST
Andrzej,
After the meeting, I also dug into the issue of
"dirty" vs. "clean" external "C" functions.
The first thing I thought of was the concept of the
"pure" VHDL function. Then I looked in the DirectC
donation more closely, and sure enough! "pure" is
already in there.
A "pure" function is essentially a function guaranteed
not to have side effects. It also should not depend
on external state, such that it might give different
answers from invocation to invocation.
I agree with you that over-attributing function
declarations is counter-productive. Users would shake
their heads in frustration if they were obliged to
precisely specify all those attributes.
I'm thinking that sticking with "pure" is good
enough for the various scenarios you describe.
The current text of the DirectC donation is pretty vague
about "pure". It says that the result of the function
should only depend on the values of its input parameters,
and that using it "enables some optimizations".
Seems like we wouldn't be violating the existing spirit
of "pure" if we extended it to mean "no dependence on
simulator state gathered by making PLI calls, and no
side effects (i.e. modifications) on simulator
state produced by making PLI calls".
As some people noted in the meeting, many PLI calls are
actually harmless with regards to external state dependence
or side effect creation. e.g. io_printf().
Please see below for discussion on each of your points.
I will try to make a case for why we don't need
to attribute function declarations for those points.
Regards,
Doug
> -----Original Message-----
> From: Andrzej Litwiniuk [mailto:Andrzej.Litwiniuk@synopsys.com]
> Sent: Wednesday, November 06, 2002 6:20 PM
> To: sv-cc@server.eda.org
> Subject: DirectC: properties/capabilities of external functions
>
>
> Last Tuesday we decidied that an external function may be specified
> as dirty (or unsafe) if it may call PLI/VPI which could read/write
> arbitrary data objects, not only the actual arguments for the
> particular
> directc call.
>
> I tried to put together several characteristics, properties
> or capabilities
> that may be- or will need to be -specified for external functions.
> Some of these properties/capabilities are related, some may
> be mutually
> exclusive. Some of them are already present in VCS DirectC, others
> will be likely needed for the extensions that have been discussed.
> A need and a syntax for some of such properties appeared in a few
> discussion threads, public or internal.
> These properties have to explicitly specified in order to allow
> the compiler to generate the correct code for a directc function/task
> call and to allow or prohibit compiler optimizations.
>
> 1. "C" or "A" or null - access mode (direct/abstract/default)
DOUG: I think we should condense these into a single access mode,
as proposed in my email on October 7th. I will create a new issue
for this topic. Hopefully we can talk about it at the meeting
tomorrow.
>
> 2. "pure" - whether function result depends solely on arguments, with
> no side effects, "pure" func call may be optimized away
DOUG: This can be the panacea attribute.
Under what circumstances would such a function ever
be totally optimized away? How could you determine
if a function should be analyzed away without actually
parsing its C++ source code to determine functionality?
What about a "pure" function that doesn't have any side
effect on simulator state, but actually does have the
side effect of writing to an output file? What that be
"pure" or not pure? I would vote it could still be pure.
But of course it couldn't be optimized away.
>
> 3. function or task
DOUG: Do we really need this distinction?
Since C++ only has functions, we might as well not
complicate this and simply call them extern "C" functions.
I would say we should keep the interface to external "C"
functions very simple and not constrain implementations
with rules such as "time advance is/is not allowed".
>
> 4. "dirty" - may or may not access anything in the design,
> not only actual
> args, via PLI/VPI calls
DOUG: I reasoned above why this could be condensed into "pure".
>
> 5. may or may not PLI be called from C function;
> compiler may need to set some variables in order to support
> further PLI calls
DOUG: I don't quite understand this.
I would prefer not to interpret the content
of C functions so precisely. All we are trying to do
is create an interface. In existing PLI, there are no
bounds on what users can write in their C code. If we
start bounding what can/can't be inside DirectC code,
users will be perplexed.
>
> 6. may or may not C function/task call SV function/task;
> compiler may have to provide somehow SV context (instance)
DOUG: I think John Stickley's proposal takes care of this
and doesn't put any burden on the compiler.
>
> 7. Module qualifier
> from which instance a task/function may be legally called;
> may be needed if default SV context is to be provided
DOUG: We may be able to not provide that default context
and require the user to fetch it dynamically at runtime.
That would keep declaration syntax simpler.
>
>
> I may speculate also that calling tasks from the other language
> may involve creating and switching threads, what may be done
> on SV side
> or C side; it's possible, that additional properties will be needed
> to inform SV compiler who is responsible for thread creation.
DOUG: Once again, we are just making an interface.
For many applications, threading isn't an issue at all.
If it is an issue, we should leave implementation of
threading to the tool providers.
We need to make sure our interface won't interfere with any
of the threading schemes that have been discussed. That is
one of John Stickley's main points.
>
>
> With this many characteristics very likely the syntax will be
> confusing
> or clumsy or both. We may use long sequences of keywords
> (e.g.: extern "A" dirty task calls_PLI calls_SV owns_thread foo();)
> or 'fopen'-like lists of characters (e.g.: extern "ADTPSO" foo();)
> but still there are two many properties to be specififed.
> Sure, they might be bundled into few sets of capabilities, but then
> very likely users will tend to use the most general combination
> (like enabling all acc capabilities "just for case").
> And this will kill the performance.
>
> Ok, my point is: keep it simple. Do not attempt to solve all problems
> via DirectC. VPI/PLI will be still there.
DOUG: I agree - we need it to be simple.
I propose doing so by simplifying our vision of DirectC into
simply a DFLI (Direct Foreign Language Interface) binding mechanism.
Not a modeling medium that is highly aware of simulation semantics.
>
> Thanks,
> Andrzej
>
Thank you.
Regards,
Doug
This archive was generated by hypermail 2b28 : Wed Nov 06 2002 - 22:05:57 PST