Subject: Re: $sv-ec Re: SV 3.1 draft 1 LRM available
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Fri Dec 06 2002 - 14:05:23 PST
> From: eolson@cisco.com [mailto:eolson@cisco.com]
>
> C++ reference parameters are pass by reference just like pointers.
> They differ from pointer parameters in three ways:
> 1) the data must exist (you can have a NULL pointer, but the data
> refered
> to by a reference is there)
> 2) you cannot change which data is referenced (you can the value of a
>
> pointer, but a refrence is a reference). You can duplicate this
> with a 'const pointer, non-const data' declaration:
> void foo( char * const p);
> 3) in the definition of the function, the variable is used by its
> normal name (much like a pass by value parameter) - like in
> David's
> example below
>
> Reference parameters are the prefered method of parameter passing in
> C++. In the case where the referenced data does not change, the prefered
>
> method is a constant reference parameter:
> void foo (const string& p); // p cannot be modified in foo
>
> Most current EE graduate should be familiar with this C++ syntax.
That's why I'd rather use it than "var".
My main complaint about the syntax is that there is no distinction
between something which is declared as a pointer/reference and something
which is an actual object i.e.:
struct foo {...}
...
foo my_foo; // creates a struct
and
class bar ... endclass
...
bar my_bar; // creates an unassigned reference
have entirely different behavior (unlike C++) - and they shouldn't.
(IMO classes should use {} the same as C++ too).
Very little existing Vera code is going to be directly SV compatible,
so I see no reason to maintain the syntactic anomilies.
Note: the usage of class/mailbox/semaphore references in SV 3.1 is
more like pointers than references - C++ references cannot be reassigned
after declaration. The reference declaration in C++ is effectively just
a shorthand for using "const" pointers to non-dynamic objects.
Kev.
> "David W. Smith" wrote:
> >
> > Kevin,
> > Looking through the book "The C++ Programinng Language Special
> > Edition" by Bjarne Stroustrup in Section 5.5 there is a discussion on
> > references. Let me quote:
> >
> > A reference is an alternative name for an object. The main use of
> > references is for specifying arguments and return values for functions
>
> > in generatl and for overloaded operators in particular. The notation
> > X& means a reference to X. For example:
> >
> > void f()
> > {
> > int i = 1;
> > int &r = i; // r and i now refer to the same int
> > int x = r; // x = 1
> >
> > r = 2; // i = 2
> > }
> >
> > As you can see the use of the variable that is a reference is NOT a
> > dereferenced and is NOT a pointer. There is NO similar statement in C
> > but there is in C++. A further example on argument passing can be
> > found later in the same section. I quote:
> >
> > A reference can be used to specify a function argument so that the
> > function can change the value of an object passed to it. For example:
> >
> > void increment(int &aa) {a++;}
> >
> > void f()
> > {
> > int x = 1;
> > increment(x); // x = 2;
> > }
> >
> > My interpretation of the use of var for pass by reference within
> > System Verilog is that it is identical in semantic but that we use a
> > different syntax for the actual declaration (section 10.5.2 of SV3.1
> > draft 1) where the above example would be:
> >
> > function void increment (var int aa);
> > aa++;
> > endfunction
> >
> > function void f ()
> > int x = 1;
> > increment(x);
> > endfunction
> >
> > Now, the function declaration syntax is clearly not C or C++. This is
> > the choice that Verilog made years ago and I do not believe we have
> > intended to change it. This actually more obnoxious then having to do
> > "var int aa" instead of "int &aa".
> >
> > So, based on the C++ definition of a reference I do believe we have it
>
> > correct SystemVerilog.
> >
> > Your issue on [*] versus [] for dynamic arrays does show a difference
> > between SV and C/C++. I kinda of like the indication of the * but
> > agree that I do not see a requirement for the *.
> >
> > I will add both of these to the issues list so that they are captured.
>
> > I hope that my first response address your issue though.
> >
> > Regards
> > David
> >
> > David W. Smith
> > Synopsys Scientist
> >
> > Synopsys, Inc.
> > Synopsys Technology Park
> > 2025 NW Cornelius Pass Road
> > Hillsboro, OR 97124
> >
> > Voice: 503.547.6467
> > Main: 503.547.6000
> > FAX: 503.547.6906
> > Email: david.smith@synopsys.com
> > http://www.synopsys.com
> >
> > -----Original Message-----
> > From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
> > Kevin Cameron
> > Sent: Tuesday, December 03, 2002 6:25 PM
> > To: sv-ec; sv bc
> > Subject: $sv-ec Re: SV 3.1 draft 1 LRM available
> >
> > I still have a major problem with the lack of syntactic distinction
> > between references and actual objects in this extension, and the use
> > of "var" (as a keyword). It makes the language a lot harder to parse
> > and makes it quite unlike C/C++. [ Can this be added to the issue
> > list?]
> >
> > On page 26 there is an example of an array copy:
> >
> > int A[100:1]; // fixed-size array of 100 elements
> > int B[*]; // empty dynamic array
> > int C[*] = new[8]; // dynamic array of size 8
> >
> > B = A; // ok. B has 100 elements
> > B = C; // ok. B has 8 elements
> >
> > - B & C are effectively references (to dynamically allocated objects),
>
> > similar statements in C:
> >
> > int A[100],
> > *B,
> > *C = (int *)malloc(8 * sizeof(int));
> >
> > B = A;
> > B = C;
> >
> > - have entirely different semantics: SV does a copy of the object, C
> > copies the reference (address). [Is there syntax for copying a
> > reference in SV?]
> >
> > Also, the inability to distinguish between pass-by-reference and
> > pass-by-value in the caller's context makes it a lot harder to analyze
>
> > modules in isolation when they use non-local functions or tasks.
> >
> > It would be nice to have the SV syntax/semantics match C and C++
> > conventions as much as possible so that it is easy to translate C/C++
> > algorithms into SV (and users don't get confused).
> >
> > In the same vein I don't see why the "*" is necessary in the "[*]" for
>
> > unsized arrays, C just omits the size.
> >
> > Kev.
> > --
> > National Semiconductor, Tel: (408) 721 3251
> > 2900 Semiconductor Drive, Mail Stop D3-500, Santa Clara, CA 95052-8090
>
> --
> Eric Olson eolson@cisco.com 408-526-5530
>
>
>
This archive was generated by hypermail 2b28 : Fri Dec 06 2002 - 14:06:17 PST