Subject: Re: DirectC: properties/capabilities of external functions
From: Michael Rohleder (Michael.Rohleder@motorola.com)
Date: Thu Nov 07 2002 - 07:40:43 PST
Hi Andrzej,
I 100% agree with your request for keeping it short and simple.
I am just unsure whether the 'pure' attribute is sufficient for characterizing a function. Having PLI/VPI calls usually requires to
have the design instrumented much more and I don't want to pay this overhead for all functions. IMHO 'pure' is much more than not
calling VPI/PLI, but is clearly preventing it... So you might have
* a clean function 'pure'
* a dirty function, but still not calling VPI/PLI
* a dirty function calling VPI/PLI, plus probably a distinction whether it does accesses read-only or read-write
But yes, I agree, we have to make sure not to overload the user ... And I am not sure whether you did not duplicate some of the
stuff below. I believe we have to clarify first some of the topics and then structure the problem space better.
More comments interspersed.
Regards,
-Michael
Andrzej Litwiniuk wrote:
> 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)
I still hope that we get rid of this distinction... And I am not sure whether we need not to distinguish between C and C++ functions
... See 7 here...
> 2. "pure" - whether function result depends solely on arguments, with
> no side effects, "pure" func call may be optimized away
I think we need to extend this as shown above.
> 3. function or task
Can we defer the decision whether we need this decision until we know about how to continue with c_modules ...
> 4. "dirty" - may or may not access anything in the design, not only actual
> args, via PLI/VPI calls
Isn't this doubling 2. and/or 5. ??? In any case, I think this could be solved by extending 2.
> 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
I disagree to the statement that the compiler need to take into account PLI calls.
I would just suggest just to go with extending the notion in 2.
> 6. may or may not C function/task call SV function/task;
> compiler may have to provide somehow SV context (instance)
This is also not defined yet. It is also possible to have some sv_... or vc_... function to provide the context.
So why do I need to specify this as a user upfront ??? Do I miss here something significant???
> 7. Module qualifier
> from which instance a task/function may be legally called;
> may be needed if default SV context is to be provided
Isn't this the same/similar to 6. Sorry, I am confused now. Please explain the difference.
> 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.
Oh, I really don't want to dig into this ... Isn't a C code that does this not inherently 'dirty' and a task?
> 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.
>
> Thanks,
> Andrzej
This archive was generated by hypermail 2b28 : Thu Nov 07 2002 - 07:41:13 PST