Subject: Re: [sv-cc] Polls on extern/export and representation of SV data
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Fri Mar 07 2003 - 16:20:41 PST
> Andrzej Litwiniuk wrote:
> > - I'm very hesitating whether the representation of unpacked arrays
> > of =packed= types should be defined.
> John Stickley wrote:
> To resolve this dilema is it possible we could require
> that any reference to a packed array from a structure or an
> unpacked array must have 1 level of indirection ?
I strongly object this! Veto! (if I may :-)
This would bring serious performance penalty.
> This would allow us to unambiguously define layout requirements
> on all the unpacked portions of a structure or unpacked
> array but defer implementation specific representation
> of packed arrays through a required indirect pointer.
>
> So, for example for
>
> typedef struct {
> int a;
> bit [6:1][1:8] b [4:2];
> int c;
> } triple;
>
> we require the following C layout:
>
> typedef struct {
> int a;
> void *b[0]; ---> indirection to packed array representation
> void *b[1]; ---> " " " " "
> void *b[2]; ---> " " " " "
> int c;
> } triple;
Consider another example:
typedef struct {
bit [1:8] a [4:1];
bit [1:8] b [4:1];
bit [1:8] c [4:1];
} triple;
Contiguous representation may take as little as 12 bytes in total (4 bytes per
array).
Indirection would take 12 pointers in addition to the actual representation of
packed arrays, 12*4+12 in total.
And what about 'bit [1:8] b [4:1][4:1]' ?
16-pointers overhead to 16 bytes of payload?
> Essentially the unpacked array of packed arrays is required to be an
> array of references to implementation specific representations
> of packed array.
>
> Seems like this would simplify things.
Aggregate assignments (including array slices) are allowed.
They may be as simple as a block-copy, or pretty expensive if indirection
is involved.
>
> The only disadvantage is that it requires implementations to
> have a level of indirection in their representation of data structures
> rather than a contiguious block of memory. However I will contend
> that implementations can even represent indirect structures
> efficiently in contiguous memory if they choose to do so for example:
>
> Possible Contiguous Memory Layout for "triple":
>
> +---------------+
> | int a |
> |---------------|
> | void *b[0] ------+
> |---------------| |
> | void *b[1] ------|--+
> |---------------| | |
> | void *b[2] ------|--|--+
> |---------------| | | |
> | int c | | | |
> |---------------| | | |
> | packed bit |<-+ | |
> | representation| | |
> | for b[0] | | |
> |---------------| | |
> | packed bit |<----+ |
> | representation| |
> | for b[1] | |
> |---------------| |
> | packed bit |<-------+
> | representation|
> | for b[2] |
> +---------------+
The above layout does not eliminate the overhead of pointers.
Neither it eliminates the complexity of an algorithm for copying an
aggregate (an array or array slice).
If that very layout may not be assumed, then the copying algorithm
must follow individual pointers both on lhs and rhs.
If the above regular layout were quaranteed, then it would be no different
(elements that follow the block of pointers) from C compatible layout
of arrays and the all burden of indirection would be simply unkustified.
Besides, do we want to impose such restriction for DirectC/DPI or for
all argument of native functions? (Please remember that 'pass by value'
is the default mode for native calls.)
Regards,
Andrzej
This archive was generated by hypermail 2b28 : Fri Mar 07 2003 - 16:21:43 PST