Subject: [sv-ec] RE: [Opaque] Pointers
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Mon Jan 06 2003 - 14:53:30 PST
> From Bassam@novas.com Mon Jan 6 13:49:34 2003
>
> Hi Kevin and all,
>
> May I suggest we not cc sv-ec always until we have a finalized extension
> to send their way. Likely we'll have some feedback so to minimize
> traffic ....
It's already on the list of EC extensions, I was cc'ing the CC rather than
the EC.
> Some quick comments/questions on this item:
>
> a) (int *) is not that opaque ....
It's only opaque in that you can't dereference it - i.e. SV does
not consider it a memory location.
> b) If it is opaque why all the access mechanisms within SV ??
An address (or whatever it is) is just a number, there's no real
cost in being able to ask what the number is, and you may want to
model access to memory in SV using information in C structs which
is declared as some kind of pointer.
> c) I thought the idea was to have something called "pointer" just as an
> additional data type in SV, and the C code can recast (the "void *") to
> something ....
Why bother, we've got a large junk of C syntax already, adding C pointer
declaration syntax is trivial, and makes it much easier to declare external
C functions without major rewrites of their prototypes and related structs.
> d) If we go by (c), do we REALLY need this in -CURRENT- version given
> our latest tendency to use instance workarea and the like, limitations
> on functions, limitations on passing, and so on .... Can we remotivate
> the need (and attach to proposal) ?
>
> -Bassam.
Feel free to offer an alternative proposal.
Kev.
> -----Original Message-----
> From: owner-sv-cc@server.eda.org [mailto:owner-sv-cc@server.eda.org] On
> Behalf Of Kevin Cameron x3251
> Sent: Monday, January 06, 2003 1:10 PM
> To: sv-ec
> Cc: sv-cc@server.eda.org
> Subject: [Opaque] Pointers
>
>
>
> We seem to be missing an "opaque pointer" proposal in the extensions list (EXT-18). Since
> I seem to have been tasked with the problem from the CC/BC here's my proposed text for
> addition:
>
> Pointers
>
> Pointers in SystemVerilog can be declared as in C by prepending "*" to a declaration e.g.:
>
> int a, // value
> *ap, // pointer to an int
> *argv[5]; // array of pointers
>
> These pointers cannot be dereferenced within SystemVerilog i.e. "*ap" has no valid meaning
> in an expression. Pointers in SystemVerilog are the same size as they are for C on the simulation
> host and can be included in unions. Their primary purpose is to pass data from one external C
> function to another. Pointers can be assigned a value from a pointer of the same type or by casting
> a scalar value to the same type as the pointer, but no other operations can modify the value e.g.:
>
> ap = (int *)'32'h100fffed;
> ap = (int *)'$data_address("gen_packet"); // User PLI
> ap = argv[0];
>
> Similarly the value of a pointer can be read by casting it to a scalar type:
>
> a = int'ap;
>
> Pointers can also be tested for equality if they are of the same type with == and != but no other
> comparisons are allowed. Pointers are initially 0 and can be tested against 0 or null directly:
>
> if (ap != null) ...
>
>
> --
>
> I think this is an easy-to-implement minimum that won't interfere with future enhancements,
> and fits with using C syntax for external function declarations (direct inclusion of headers). It
> violates requirement 2.h and 3, but it's not clear to me that those requirements are necessary
> since the pointer value is never dereferenced inside SV, and req. 3 precludes using predefined
> C structures that do make unions of pointers and integers.
>
> Regards,
> Kev.
>
> --
>
> National Semiconductor, Tel: (408) 721 3251
>
> 2900 Semiconductor Drive, Mail Stop D3-500, Santa Clara, CA 95052-8090
>
This archive was generated by hypermail 2b28 : Mon Jan 06 2003 - 14:54:26 PST