Subject: Re: $sv-ec References in SystemVerilog (proposal)
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Tue Sep 24 2002 - 09:25:28 PDT
> 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 - 09:27:00 PDT