Subject: RE: $sv-ec References in SystemVerilog (proposal)
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Thu Sep 19 2002 - 17:20:02 PDT
I forgot we had added "&=" as an asignment operator already for
"x = x & b" -> "x &= b", so if you read the proposal assume that I'll
be changing it to ":=" (and maybe use "?=" for $cast_assign).
> From owner-sv-ec@server.eda.org Thu Sep 19 11:35:28 2002
> From: "David W. Smith" <david.smith@synopsys.com>
> To: "'sv-ec'" <sv-ec@server.eda.org>
> Subject: RE: $sv-ec References in SystemVerilog (proposal)
> Importance: Normal
>
> I think the first discussion that has to occur is how many of the
> following three (and possibly more) items we are trying to provide:
>
> 1. support of opaque pointers that can be passed in from C calls and
> passed to other C calls but have no other usefulness in SV.
The proposal is just for "references" not opaque pointers for C interfacing
(or arbitrary memory access).
I can't see any easy way to do pointers that won't interfere with how
the simulation kernel wants to store 4-value data. You can always hand
data from C to SV to C using int or real types in SV (if SV isn't using
the values).
> 2. support pass-by-reference semantics for passing composite data types
> around. There is no pointer and no pointer arithmetic to deal with. This
> has the advantage of allowing calls to be more effecient but the
> possibility of unintended modifications of data. The type of data
> structure would be manipulated in the called location the same as in the
> calling (arrays are indexed, structures are refenced by field, etc).
That's part of what I was addressing, except that I like having the
pointer arithmetic :-)
> 3. support full pointer concepts where pointer arithmetic can be used
> etc... The problem here is that it can be either a cost due to extensive
> checking or stability problems.
The reference proposal is a compromise - it gives you something with
pointer-like semantics but not arbitrary access to memory, and it can
probably be implemented fairly easily.
> So, what requirement do we have for reference and/or pointers in
> System-Verilog?
a) Improve efficiency on function/task calls using large arrays.
b) Improve coding - eliminate need to repeat indexing expressions.
c) Improve optimization - references ease recognition of common
expressions (helps synthesis too).
d) Save memory - the channel example in the proposal only creates
a data object once and sends a reference to it rather than a copy
when communicating with other processes, that saves memory usage
and the copying overhead.
e) Reference/pointer mechanism should be "safe" i.e. no direct access
to kernel data - akin to no writing into the operating system's
memory with a C program.
> Regards
> David
I think the pointer issue should stay with the C/C++ committee, but having
said that it should be possible to cast a pointer returned from C into a
reference (of the type in the proposal) which would limit the semantics.
E.g. something like:
typedef FILE; // only good for references and type checking
extern "C" { // declare external C routines (C syntax)
FILE *fopen(char *,char *);
int fprintf(FILE *,char *,...);
}
module hw;
FILE &fp;
initial begin
fp := fopen("/dev/tty","w");
fprintf(fp,"Hello World\n");
end
endmodule
Regards,
Kev.
This archive was generated by hypermail 2b28 : Thu Sep 19 2002 - 17:23:40 PDT