Subject: Re: [sv-cc] DirectC C Layer - (non-portable) access to data
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Thu Feb 06 2003 - 10:12:28 PST
> > my_value = *(MyType *)svGetArrElemPtr2(h, i, j);
> > ...
> > *(MyType *)svGetArrElemPtr2(h, i, j) = my_value;
> > ...
KEVIN:
> 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.
True: the code is not portable.
(In that example MyType was a data type that mixed C compatible types with
simulator's specific representation of packed arrays.)
That example can be re-coded without casting to (MyType *), but still it
would require at least the sizeof(MyType) and therefore won't be portable.
int size = ... ; /* = sizeof(MyType) */
void *s = svGetArrElemPtr2(h, i, j);
void *d = svGetArrElemPtr2(h, i, j);
memcpy(s, d, size);
KEVIN:
> 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.
Could the above functions be able to copy the data of unknown layout?
A handle for an open array may provide the size of an element, so the code of
svGetArrElemPtr2 may employ memcpy similarly to my C code above. This is fine.
But still you will have to declare your variable my_value and this again won't
be portable.
If your point was that it would be more convenient if the copying
of the amorphous data would be done inside library functions,
in other words, getting the pointer and copying the data is bundled inside
a single function, than I may agree.
Sometimes it may be more convenient to have a mere pointer without any
actual copying of data, that's why I wanted it orthogonal: separate function
for getting the address, and separate functions (e.g. memcpy) for moving
data or performing conversion (e.g. svGetLogicVec32, svPutLogicVec32).
But we may add another bunch of functions, that would combine the calcualtion
of array element's address with moving/converting the data.
Is this what you wanted?
Regards,
Andrzej
This archive was generated by hypermail 2b28 : Thu Feb 06 2003 - 10:13:40 PST