Subject: Fwd: BOUNCE sv-bc@eda.org: Non-member submission from ["Arturo Salz"
>Date: Sun, 8 Dec 2002 23:55:42 -0800 (PST)
This archive was generated by hypermail 2b28
: Mon Dec 09 2002 - 16:20:36 PST
From: Karen Pieper (Karen.Pieper@synopsys.com)
Date: Mon Dec 09 2002 - 16:17:41 PST
>From: owner-sv-bc@eda.org
>To: owner-sv-bc@eda.org
>Subject: BOUNCE sv-bc@eda.org: Non-member submission from ["Arturo
>Salz" <Arturo.Salz@synopsys.com>]
>
> >From owner-sv-bc Sun Dec 8 23:55:23 2002
>Received: from boden.synopsys.com (boden.synopsys.com [204.176.20.19])
> by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id
> gB97tJuk019554;
> Sun, 8 Dec 2002 23:55:21 -0800 (PST)
>Received: from maiden.synopsys.com (maiden.synopsys.com [146.225.100.170])
> by boden.synopsys.com (Postfix) with ESMTP
> id EFE1BE401; Sun, 8 Dec 2002 23:55:17 -0800 (PST)
>Received: from ca11.synopsys.com.synopsys.com (localhost [127.0.0.1])
> by maiden.synopsys.com (8.9.1/8.9.1) with ESMTP id XAA13443;
> Sun, 8 Dec 2002 23:55:23 -0800 (PST)
>Received: from salzhome by ca11.synopsys.com.synopsys.com (8.8.8/SNPS-Sol2)
> id XAA11692; Sun, 8 Dec 2002 23:55:15 -0800 (PST)
>Message-ID: <016b01c29f58$4b19b6b0$bcba42ab@synopsys.com>
>From: "Arturo Salz" <Arturo.Salz@synopsys.com>
>To: "Kevin Cameron" <Kevin.Cameron@nsc.com>, "sv-ec" <sv-ec@server.eda.org>,
> "sv bc" <sv-bc@server.eda.org>
>References: <3DED6795.C4CA73DA@nsc.com>
>Subject: Re: $sv-ec Re: SV 3.1 draft 1 LRM available
>Date: Sun, 8 Dec 2002 23:54:49 -0800
>MIME-Version: 1.0
>Content-Type: text/plain;
> charset="iso-8859-1"
>Content-Transfer-Encoding: 7bit
>X-Priority: 3
>X-MSMail-Priority: Normal
>X-Mailer: Microsoft Outlook Express 5.50.4807.1700
>X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
>
>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