Subject: Re: $sv-ec References in SystemVerilog (proposal)
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Tue Sep 24 2002 - 06:29:33 PDT
Kevin,
could you elaborate why you would like to have pointer-arithmetic?
Regards,
Michael
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.
-- Quote of the day: "Better to remain silent and be thought a fool than to speak out and remove all doubt." [Abraham Lincoln (1809-1865)]NOTE: The content of this message may contain personal views which are not neccessarily the views of Motorola, unless specifically stated.
The information contained in this email has been classified as: Motorola General Business Information (x) Motorola Internal Use Only ( ) Motorola Confidential Proprietary ( ) when marked, please note: This e-mail and any attachments are confidential and Motorola reserves all rights of privilege in respect thereof. It is intended for the use by the addressee only. Please delete it from your system, if you are not the intended recipient. Any use, disclosure, or copying of the included information is unauthorised. ___________________________________________________ | | _ | Michael Rohleder Tel: +49-89-92103-259 | _ / )| Software Technologist Fax: +49-89-92103-680 |( \ / / | Motorola, Semiconductor Products, ASA Methodology | \ \ _( (_ | _ Schatzbogen 7, D-81829 Munich, Germany _ | _) )_ (((\ \>|_/ > < \_|</ /))) (\\\\ \_/ / mailto:Michael.Rohleder@motorola.com \ \_/ ////) \ /_______________________________________________\ / \ _/ \_ / / / \ \
This archive was generated by hypermail 2b28 : Tue Sep 24 2002 - 06:30:17 PDT