Re: [sv-cc] Polls on extern/export and representation of SV data


Subject: Re: [sv-cc] Polls on extern/export and representation of SV data
From: Stickley, John (john_stickley@mentorg.com)
Date: Tue Mar 11 2003 - 08:37:10 PST


Andrzej,

Of course you're right on all points.

I'm just desparately seeking some solution to the
problem embedded packed arrays. This is one of the very
few things in the C layer that still seems to lack an
elegant solution.

-- johnS

Andrzej Litwiniuk wrote:
>>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
>

                                                            __
                        ______ | \
______________________/ \__ / \
                                 \ H Dome ___/ |
John Stickley E | a __ ___/ / \____
Principal Engineer l | l | \ /
Verification Solutions Group | f | \/ ____
Mentor Graphics Corp. - MED C \ -- / /
17 E. Cedar Place a \ __/ / /
Ramsey, NJ 07446 p | / ___/
                                  | / /
mailto:John_Stickley@mentor.com \ /
Phone: (201)818-2585 \ /
                                    ---------



This archive was generated by hypermail 2b28 : Tue Mar 11 2003 - 08:41:45 PST