Subject: Re: $sv-ec References in SystemVerilog (proposal)
From: Shalom.Bresticker@motorola.com
Date: Tue Sep 24 2002 - 10:49:41 PDT
Also simplicity of coding in some cases, like traversing elements of a
structure.
Shalom
On Tue, 24 Sep 2002, Kevin Cameron x3251 wrote:
> Date: Tue, 24 Sep 2002 09:25:28 -0700 (PDT)
> From: Kevin Cameron x3251 <Kevin.Cameron@nsc.com>
> To: Michael Rohleder <Michael.Rohleder@motorola.com>
> Cc: sv-ec@eda.org
> Subject: Re: $sv-ec References in SystemVerilog (proposal)
>
> > From owner-sv-ec@server.eda.org Tue Sep 24 06:30:02 2002
> >
> > Kevin,
> >
> > could you elaborate why you would like to have pointer-arithmetic?
> >
> > Regards,
> > Michael
>
> Symmetry with C/C++. The more similar the syntax/functionality of SV
> and C/C++ the easier it is convert one to the other for hardware/software
> trade-off.
>
> Completeness. If references are added then it is likely that users will
> demand the functionality, so it is better to have a complete proposal
> that supports pointer-arithmetic than a proposal that doesn't mention
> it and does not support it cleanly as an extension (even if it isn't
> all included in the next LRM).
>
> Regards,
> Kev.
>
> > Kevin Cameron x3251 wrote:
> >
> > > 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 : Tue Sep 24 2002 - 10:51:57 PDT