Subject: Re: [sv-cc] Polls on extern/export and representation of SV data types
From: Stickley, John (john_stickley@mentorg.com)
Date: Fri Mar 07 2003 - 15:24:50 PST
I vote yes on 1, yes on 2
I sent out some small feedback on 1. earlier.
As for 2 I have one suggestion here:
Andrzej Litwiniuk wrote:
>
> - I'm very hesitating whether the representation of unpacked arrays
> of =packed= types should be defined.
> Whatever is the decision, it should be clearly stated.
> I'm rather biased towards opinion that the representation of unpacked
> arrays
> of =packed= types should be left to compiler.
> Compiler may decide to use different representation for array elements
> than for a single element of the same type.
> For example, single value of type 'bit[18:1]' may be represented as
> 'int',
> while 3 bytes may be used for each element of that type in an unpacked
> array.
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 ?
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;
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.
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] |
+---------------+
-- johnS
Swapnajit Mittra wrote:
> Please send your comment (Y/N/A) on the following two items as
> we discussed in the last meeting:
>
> 1. Poll on acceptance of Joao's modified extern/export proposal.
> http://www.eda.org/sv-cc/hm/0920.html
>
> 2. Poll on agreement on SV-CC's opinion on the SV LRM language
> issue. Andrzej's comment on this is at:
> http://www.eda.org/sv-cc/hm/0908.html
>
> The deadline is Saturday 3/8.
>
> The eligible members for sending their comments are:
>
> Francoise Martinole
> Stuart Swan
> John Amouroux
> John Stickley
> Doug Warmke
> Michael Rohleder
> Kevin Cameron
> Bassam Tabbara
> Joao Gaeda
> Andrzej Litwiniuk
>
>
>
>
> --
> Swapnajit Mittra
> Project VeriPage ::: http://www.angelfire.com/ca/verilog
>
>
> ________________________________________________________________
> Sign Up for Juno Platinum Internet Access Today
> Only $9.95 per month!
> Visit www.juno.com
>
--__ ______ | \ ______________________/ \__ / \ \ 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 : Fri Mar 07 2003 - 15:30:42 PST