Subject: [sv-ec] Re: $sv-ec Re: SV 3.1 draft 1 LRM available
From: Arturo Salz (Arturo.Salz@synopsys.com)
Date: Sun Dec 08 2002 - 23:54:49 PST
Kevin,
You raise several issues on your message. I'll address each one separately.
1) Use of "var" keyword instead of an operator.
Using an operator to specify pass-by-reference is certainly an option, but
it would be inconsistent with Verilog in which parameters can be passed
as input, output, or inout (all three are keywords). The "var" keyword is
simply a fourth type of parameter passing that is unlike the other three.
Regarding the difficulty of parsing a keyword versus an operator, I don't
believe this is a serious issue.
2) Dynamic array semantics.
There seems to be some confusion here. Dynamic arrays are not pointers.
Although some underlying part of an implementation may contain code
like the shown in the message, the dynamic array is an array and it has a
lot more semantics than just a pointer. To name a few: Arrays perform
bounds checking, reading out of range element yields a "default" value,
arrays keep track of their size.
Also, array assignment (or pass by value) causes the array to be copied
not a pointer. This is consistent with existing fixed-size arrays in Verilog.
Finally, copying an array reference is not needed. In the C arrays you
show, one needs to reallocate the pointer, but in SV, users can modify the
array directly by passing it by reference. Also, the array can be declared
in a class and then use the class handle for that purpose.
3) SV versus C++ semantics.
The donation matches C++ reference conventions and semantics exactly.
C++ references also do not distinguish the parameter passing method at
the point of call.
C doesn't have references (only pointers), and SV supports references.
4) Use of "[*]" in dynamic array declaration versus "[]"
Dynamic arrays can't use the "[]" syntax because associative arrays indexed
by arbitrary size integers are declared using "[]". In this case the "[*]" is
intended to be reminiscent of the C pointer manipulation in order to remind
users that the array needs to be explicitly created.
Arturo
----- Original Message -----
From: "Kevin Cameron" <Kevin.Cameron@nsc.com>
To: "sv-ec" <sv-ec@eda.org>; "sv bc" <sv-bc@eda.org>
Sent: Tuesday, December 03, 2002 6:25 PM
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 : Sun Dec 08 2002 - 23:56:21 PST