Subject: Re: [sv-cc] DirectC C Layer - revised (ascii)
From: Kevin Cameron (Kevin.Cameron@nsc.com)
Date: Tue Feb 04 2003 - 10:32:06 PST
Andrzej Litwiniuk wrote:
> Hi all,
>
> ....
>
> 3.5 'Context' and non-'context' functions
>
> Only functions specified as 'context' in their corresponding SV external
> declarations may safely call functions from other APIs, including PLI and VPI
> functions, or exported SV functions.
I see no reason for this restriction. It will cause a major headache for anyone
allocating static objects in C/C++ with PLI/VPI handles back into the simulator
and wanting to use simple calls to send messages.
> For functions not specified as 'context' the effects of calling PLI or VPI
> functions or SV functions are unpredictable and such calls may crash.
I see no reason why this should be true.
> 3.6 'Pure' functions
>
> The functions specified as 'pure' in their corresponding SV external
> declarations must have no side effects whatsoever directly or indirectly.
Should be:
The functions specified as 'pure' in their corresponding SV external
declarations will be assumed to have no side effects. Their result
is assumed to depend solely on the values of their input arguments.
Calls to such functions may be removed by SV compiler optimizations.
I may want to use a "debug" version of such a routine that might write to
files etc. - I wouldn't want it optimized differently.
>
> Their result must depend solely on the values of their input arguments.
> Specifically, such functions should not perform any file operations,
> not read or write anything, not access any persistent data like global or static
> variables.
>
> The user should assume that any call of 'pure' function in SV code may be
> removed by SV compiler optimizations.
> ...
> /* canonical representation */
>
> #define sv_0 0
> #define sv_1 1
> #define sv_z 2 /* representation of 4-st scalar z */
> #define sv_x 3 /* representation of 4-st scalar x */
Value, strength and certainty are orthogonal, this would be better as:
#define sv_0 0
#define sv_1 1
#define sv_z 2 /* representation of 4-st scalar z */
#define sv_x 4 /* representation of 4-st scalar x */
- this is relevent if you are bridging into a mixed-signal/analog environment.
> 8.7 Access to array elements of other types
>
> If array's elements are of a type compatible with C, then there is no need
> to use the canonical representation. In such situations the elements will
> be accessed via pointers, i.e. the actual address of an element will be
> computed first and then used to access the desired element.
>
> Example 3 - open array
> ======================
>
> SV:
> typedef struct {int i; ... } MyType;
>
> extern void foo(input MyType i [][]);
> // 2-dimensional unsized unpacked array of MyType
>
> MyType a_10x5 [11:20][6:2];
> MyType a_64x8 [64:1][-1:-8];
>
> foo(a_10x5);
> foo(a_64x8);
>
> C:
> #include "svc_bin.h"
>
> typedef struct {int i; ... } MyType;
>
> void foo(const svHandle h)
> {
> MyType my_value;
> int i, j;
> int lo1 = svLow(h, 1);
> int hi1 = svHigh(h, 1);
> int lo2 = svLow(h, 2);
> int hi2 = svHigh(h, 2);
>
> for (i = lo1; i <= hi1; i++) {
> for (j = lo2; j <= hi2; j++) {
>
> my_value = *(MyType *)svGetArrElemPtr2(h, i, j);
> ...
> *(MyType *)svGetArrElemPtr2(h, i, j) = my_value;
> ...
This is still bad style. It does not allow the system to reinterpret "my_value"
if its internal representation is different, i.e. the code is not portable. It
should be:
svGetArrElemPtr2(&my_value,h, i, j);
svPutArrElemPtr2(&my_value,h, i, j);
- if you want the non-portable version you can use macro-definitions.
Regards,
Kev.
-- National Semiconductor, Tel: (408) 721 3251 2900 Semiconductor Drive, Mail Stop D3-500, Santa Clara, CA 95052-8090
This archive was generated by hypermail 2b28 : Tue Feb 04 2003 - 10:31:42 PST