Subject: Re: [sv-ec] Re: $sv-ec Re: SV 3.1 draft 1 LRM available
From: Kevin Cameron (sv-xx@grfx.com)
Date: Mon Dec 09 2002 - 01:16:44 PST
> From: "Arturo Salz" <Arturo.Salz@synopsys.com>
>
> 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.
It's very serious from my perspective, I think it's bad syntax. Direction and
being a reference are orthogonal for starters e.g. I could have:
input var foo
"var" is probably the most likely too clash of all the suggested new keywords,
and using '&' or '*" is easier, mirrors C and doesn't clash with anything.
> 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.
My point was that the syntax and semantics were not symmetric between class
references and array references.
- If a declared name can refer to different objects at different times then
it is a reference (which is functionally just a subclass of pointer).
> 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.
In general SV references are more like C pointers than C++ references - C++
references can't refer to dynamic objects other than for routine arguments, and
can't be reassigned. So in the limited case of routine arguments you may be
correct - but the 3.1 LRM doesn't say you can't reassign the reference (maybe
with new):
function foo (var int bar[*]);
...
bar = new[100];
C++ also doesn't let you call a routine without it or it's prototype being
seen first - which defines the passing mechanism in the calling context, SV
doesn't have that restriction.
> 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.
Eh? [*] doesn't remind me of anything but pointers, regexps and multiplication.
Since associative arrays are new they should have the odd syntax not the declarations
that users want to duplicate from C/C++.
Kev.
> 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 : Mon Dec 09 2002 - 01:20:34 PST