Subject: DirectC: access to arrays; pointers & handles
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Tue Jan 07 2003 - 16:00:06 PST
Michael & Kevin,
Whatever are your concerns, right or wrong, justified or not,
they do apply both to the sized arrays and to the unsized arrays.
Actually there is not much differences between accessing the sized arrays
via direct access and accessing the unsized arrays via abstract access.
In both cases it is silently assumed, perhaps wrongly, that an array occupies
a contigouos block of memory. I don't know how to deal without that assumptions,
at least for the arrays that may be embedded in structures.
(How to replace an array that is embedded in a structure, with a handle without
the overhead of copying the whole structure?)
Let me recall differences (and similarities) between the two cases.
Sized arrays with direct access:
--------------------------------
- an array may be embedded in a structure
- all ranges and size are statically known and are same for all the actual
arguments
- normalized ranges are assumed in C code
- normalized indices are used, with hard-coded ranges
- address of the relevant element is calculated by the C compiler
in a transparent way, based on the definition of an array
- no index checking is performed
- a pointer to an element (or to the whole array) is implicitly used
(any access to an element of an array involves an implicit calculation
of the address of that element)
Unsized (open) arrays with abstract access:
-------------------------------------------
- an array must be a standalone object (may not be embedded in a structure)
- ranges and size are not statically known and may be different for
different actual arguments
- original SV ranges are used in C code
- original indices are used, the ranges are dynamically determined via query
- address of the relevant element is calculated by the library function
using a handle
- index checking may/will be performed by the library function
- a pointer to an element is explicitly calculated and used.
In the case of sized arrays and direct access, the pointers to array elements
are implicitly calculated by the C compiler and that's why, I guess, they
didn't draw your attention.
Anyway, all problems that you have validly pointed for the abstract access,
do occur also for the direct access.
Therefore no restriction for abstract access will do, as long as direct
access is also possible. And direct access cannot be eliminated because there
is no easy way to provide handles for arrays embedded in structures.
Michael wrote:
> I think you need to distinguish between the need for pointers to
> . permit the reference to arbitrary types
> . modify the actual value of a simulation object.
> While I agree to the first bullet, Kevin and myself have some concerns about the second one.
>
> When we would have a set of GetElement and PutElement functions to read and modify the
> actual value of an element, then the remaining functionality could be exactly like with parameters
> of a DirectC function.
Kevin wrote:
> Most simulators do some scattering and gathering of net data, i.e what looks
> like an array of values to the user is actually an array of references to
> slices of nets in other scopes, some of the drivers of those nets may be 0/1
> (bit) others may be 0/1/X/Z. Some implementations copy value changes to a
> local copy of the data that does look like what the user sees, others don't.
>
> Data written to a signal is often written to a driver and not to the same
> location as the signal value is read from, and driver structures are not
> the same as signal value structures. Drivers may also only be associated
> with parts of a larger structure rather than the whole too.
>
> Generally it's not the sort of thing you want to hand the user a pointer to.
Another issue: should the maximal number of indices be restricted?
> > > NB: Macro definitions generally don't take "..." arguments.
> >
> > Right. So, macros won't do the trick either, will they?
>
> They do, but you might have to specify more of them.
Yes, but they have to be defined up-front and that way we de-facto will limit
the maximal number of indices.
(The same applies to Kevin's example based on C++ overloading.)
It may be a reasonable approach and I don't mind it.
If we restrict the maximal number of indices, say to 5, then a general
function with a varaiable list of indices will not be necessary.
Andrzej
This archive was generated by hypermail 2b28 : Tue Jan 07 2003 - 16:01:32 PST