Subject: DirectC C layer - open arrays and portability - PLEASE READ
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Fri Jan 10 2003 - 08:00:38 PST
Team,
In the revised version of the C Layer I tried to address Kevin's concerns with
the representation of arrays.
The solution that I came to may be a bit controversial, so I ask you to analyze
it kindly.
For your convenience here are the relevant pieces extracted from the doc.
Andrzej
============================================
Representation of the data
--------------------------
The following is assumed about the representation of SV data:
a) representation of packed types is implementation dependent
b) basic integer and real data types are represented as defined in LRM 3.3,
3.4.2, see also "Data type mapping" below.
c) layout of unpacked structures is same as used by C compiler (LRM 3.7)
d) layout of sized unpacked arrays is same as used by C compiler;
this includes arrays embedded in structures and the standalone arrays
(i.e. not embedded in any structure)
Note that this is a restriction imposed on the SV side of the interface!
Depending on the implementation, a particular array may or may be not
accepted as an actual argument for the formal argument which is a sized
array (it will be always accepted for unsized array).
e) layout of the unsized (aka open) standalone unpacked arrays
is implementation dependent with the following restriction:
an element of an array must have the same representation as
individual a value of the same type, with the exception of scalars
(bit or logic) and packed arrays as a type of an element.
Hence array's elements other than scalars or packed arrays can be
accessed via pointers similarly to individual values.
Note that d) actually does not impose any restrictions on how unpacked arrays
are implemented; it says only that an array that does not satisfy d)
may not be passed as an actual argument for the formal argument which is
a sized array; it may be passed, however, for unsized array.
Therefore, the correctness of an actual argument may be implementation
dependent. Nevertheless an open array provides implementation independent
solution. This seems to be a reasonable trade-off.
Access to the actual representation
-----------------------------------
The following functions provide an actual address of the whole array or
of its individual element. These functions will be used for accessing
elements of the arrays of types compatible with C.
These functions will be also usefull for the vendors, because
they provide access to the actual representation for all types of arrays.
If the actual layout of the SV array passed as an argument for an open unpacked
array is different than C layout, then it will not be posssible to access such
array as a whole and therefore the address and size of such array will be
undefined (zero, to be exact).
Nonetheless the adresses of individual elements of an array will be always
supported.
/* a pointer to the actual representation of the whole array of any type */
/* NULL if not in C layout */
void *svGetArrayPtr(svHandle);
int svSizeOfArray(svHandle); /* total size in bytes or 0 if not in C layout */
Example 4 - open array
======================
SV:
typedef struct { ... } MyType;
extern void foo(input MyType i [], output MyType o []);
MyType source [11:20];
MyType target [11:20];
foo(source, target);
C:
#include "svc_bin.h"
typedef struct ... } MyType;
void foo(svHandle hin, svHandle hout)
{
int count = svUnpackedLength(hin, 1);
MyType *s = (MyType *)svGetArrayPtr(hin);
MyType *d = (MyType *)svGetArrayPtr(hout);
if (s && d) { /* both arrays have C layout */
/* an efficient solution using poiter arithmetics */
while (count--)
*d++ = *s++;
/* even more efficient:
memcpy(d, s, svSizeOfArray(hin));
*/
} else { /* less efficient yet implementation independent */
int i = svUnpackedLow(hin, 1);
int j = svUnpackedLow(hout, 1);
while (i <= svUnpackedHigh(hin, 1)) {
*(MyType *)svGetArrElemPtr1(hout, j++) =
*(MyType *)svGetArrElemPtr1(hin, i++);
}
}
}
This archive was generated by hypermail 2b28 : Fri Jan 10 2003 - 08:01:09 PST