Re: [sv-cc] 'Scalar' term for SV function results, etc.

From: Neil Korpusik <Neil.Korpusik_at_.....>
Date: Mon Jun 04 2007 - 17:36:55 PDT
I believe that Shalom is correct in suggesting the term "singular". The
following is from Draft 3 of the LRM.

6.4 Singular and aggregate types

   Data types are categorized as either singular or aggregate. A singular type
   shall be any data type except an unpacked structure, unpacked union, or
   unpacked array (see 7.4 on arrays). An aggregate type shall be any unpacked
   structure, unpacked union, or unpacked array data type. A singular variable
   or expression represents a single value, symbol, or handle. Aggregate
   expressions and variables represent a set or collection of singular values.
   Integral types (see 6.11.1) are always singular even though they can be
   sliced into multiple singular values.

   These categories are defined so that operators and functions can simply
   refer to these data types as a collective group. For example, some functions
   recursively descend into an aggregate variable until reaching a singular
   value and then perform an operation on each singular value.

   Although a class is a type, there are no variables or expressions of class
   type directly, only class object handles that are singular. Therefore,
   classes need not be categorized in this manner (see Clause 8 on classes).



Ralph Duncan wrote On 06/04/07 08:50,:
> Shalom,
>  
> 1. The intent certainly is to distinguish a single value from
> aggregate/composite values.
> 2. Despite the original, non-vector meaning, common use of 'scalar' does
> seem to mean single value:
>         http://en.wikipedia.org/wiki/Scalar_%28computing%29
> 3. The SV definition of 'scalar' as 1-bit wide is in 6.8.
> 4. String appears to be included because we are indicating the pointer
> to the string, rather than the string, itself.
> 5. 'Singular' seems reasonable; the only obvious alternative is to spell
> out that it's not 
>     an aggregate or composite (e.g., array, vector, structure).
>  
> Does anyone some memorable and snappy alternative?
>  
> Ralph 
> 
>     -----Original Message-----
>     *From:* owner-sv-cc@server.eda.org
>     [mailto:owner-sv-cc@server.eda.org]*On Behalf Of *Bresticker, Shalom
>     *Sent:* Monday, June 04, 2007 7:09 AM
>     *To:* Stickley, John; SV-CC
>     *Subject:* RE: [sv-cc] import/export function result types
> 
>     In SV, a scalar is a one-bit value. “Singular” would be closer.
> 
>      
> 
>     Shalom
> 
>      
> 
>     ------------------------------------------------------------------------
> 
>     *From:* Stickley, John [mailto:john_stickley@mentor.com]
>     *Sent:* Monday, June 04, 2007 5:03 PM
>     *To:* Bresticker, Shalom; SV-CC
>     *Subject:* RE: [sv-cc] import/export function result types
> 
>      
> 
>     A possible replacement for this term is "scalar values".
> 
>     That is the term used in VHDL and is probably less vague.
> 
>     -- johnS
> 
> 
>     -----Original Message-----
>     From: owner-sv-cc@server.eda.org on behalf of Bresticker, Shalom
>     Sent: Mon 6/4/2007 5:30 AM
>     To: SV-CC
>     Subject: [sv-cc] import/export function result types
> 
>      
> 
>     Hi,
> 
>     In Draft 3, 34.2.2 says,
> 
>     A rich subset of SystemVerilog data types is allowed
> 
>     for formal arguments of import and export functions, although with some
>     restrictions and with some notational
> 
>     extensions. Function result types are restricted to small values,
>     however (see 34.5.5).
> 
>     and 34.5.5 has a similar statement and details the exact restrictions.
> 
>     However the phrase "small values" sounds strange.
> 
>     In what way are real, longint, and string 'small', for example?
> 
>     Thanks,
> 
>     Shalom
> 
> 
> 
>     Shalom Bresticker
> 
>     Intel Jerusalem LAD DA
> 
>     +972 2 589-6852
> 
>     +972 54 721-1033
> 
> 
> 
> 
>     --
>     This message has been scanned for viruses and
>     dangerous content by MailScanner, and is
>     believed to be clean.
> 
> 
>     -- 
>     This message has been scanned for viruses and
>     dangerous content by *MailScanner* <http://www.mailscanner.info/>*,
>     and is
>     believed to be clean. *
> 
> *
> -- 
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean. *

-- 
---------------------------------------------------------------------
Neil Korpusik                                     Tel: 408-276-6385
Frontend Technologies (FTAP)                      Fax: 408-276-5092
Sun Microsystems                       email: neil.korpusik@sun.com
---------------------------------------------------------------------



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Mon Jun 4 17:41:29 2007

This archive was generated by hypermail 2.1.8 : Mon Jun 04 2007 - 17:41:42 PDT