Subject: Re: [sv-cc] DirectC C Layer - (non-portable) access to data
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Thu Feb 06 2003 - 13:37:22 PST
> From Andrzej.Litwiniuk@synopsys.com Thu Feb 6 10:12:42 2003
>
> > > 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);
>
Yep, that's semantically identical.
It also has the problem that the simulator has to have permanently
allocated data to support the calls, and the simulator has no idea
when data is being modified - if the user saves the pointer and
uses it on another call there is no way the simulator will know.
> 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 you are casting the data as "MyType" you are making the assumption that
the simulator has an object of the size of "MyType". It's safer not to leave
the casting in the user's code since getting it wrong will have nasty
side-effects (and it's hard to debug).
> 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?
I'll use direct pointers if you give me an open-source simulator that I can
debug the code with, otherwise I'd like an implementation that is relatively
robust i.e. no direct writing into simulator's data.
NB: making the data copying faster does not mean that the simulation will be
quicker if the simulator has to do more work to support the interface.
What I really want is an object oriented interface using C++.
I also think we should have done all the VPI/PLI support before launching
into this "direct" stuff.
Kev.
> Regards,
> Andrzej
This archive was generated by hypermail 2b28 : Thu Feb 06 2003 - 13:38:56 PST