Subject: RE: $sv-ec Re: SV 3.1 draft 1 LRM available
From: David W. Smith (david.smith@synopsys.com)
Date: Fri Dec 06 2002 - 11:18:53 PST
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
This archive was generated by hypermail 2b28 : Fri Dec 06 2002 - 11:19:01 PST