Re: SN constants

From: Michael (Mac) McNamara <mcnamara_at_.....>
Date: Wed Dec 16 2009 - 01:09:03 PST
I am ok with MAX_INT instead of IEEE_1648_MAX_INT.  My problem was with the P1647 prefix, as the 'P' is only appropriate with the proposed nature of a standard. 

After all, I am a three fingered typist (and I knew - the Blackberry is EXACTLY why I did not waste time learning to be a touch typist back in 1972) so fewer characters to type is a good thing!

Mac

----- Original Message -----
From: Matan Vax
To: Andrew Piziali <andy@piziali.dv.org>; Michael (Mac) McNamara
Cc: darren.galpin@infineon.com <darren.galpin@infineon.com>; Mike.Bartley@infineon.com <Mike.Bartley@infineon.com>; Serrie.Chapman@infineon.com <Serrie.Chapman@infineon.com>; ieee1647@eda.org <ieee1647@eda.org>
Sent: Wed Dec 16 00:01:54 2009Subject: RE: SN constants

Guys,

I tend to agree that SN_ prefix is connoted with Specman, and we should probably get rid of it. But this IEEE_1647_ prefix is seems awkward and redundant to me. Why not prefix every name in the standard this way? In particular, do you think MAX_INT should be renamed IEEE_1647_MAX_INT? Would anyone need to define his own SQRT2? And if someone did, isn't it reasonable to expect that he would prefix his own constant, rather than make everyone use such an unreadable name? I'd rather leave all these constants outside the standard than have such strange names to them.

Matan.

>-----Original Message-----
>From: Andrew Piziali [mailto:andy@piziali.dv.org]
>Sent: Wednesday, December 16, 2009 1:50 AM
>To: Michael (Mac) McNamara
>Cc: darren.galpin@infineon.com; Matan Vax; Mike.Bartley@infineon.com;
>Serrie.Chapman@infineon.com; ieee1647@eda.org; Andrew Piziali
>Subject: Re: SN constants
>
>Mac,
>
>I agree that "IEEE1647" would be a more appropriate prefix for these
>built in macros.  Perhaps "IEEE_1647" would be more readable, at the
>expense of an extra character.
>
>Thanks.
>
>-----------------------------------
>Mac wrote:
>
>> "P1647" is the official name for the work product of an open PAR,
>> which would consist of proposed enhancements, changes et cetera for
>> the standard 1647.  As such things qualified with P1647 mean something
>> that is coming, but is not yet here.
>
>> So we should use something other than P1647 as the prefix for these
>> macros.  As macros need to start with an alphabetic character, I would
>> suggest something like: IEEE1647_M_E
>
>> -----Original Message-----
>> From: owner-ieee1647@eda.org [mailto:owner-ieee1647@eda.org] On Behalf
>> Of Andrew Piziali
>> Sent: Thursday, October 22, 2009 3:48 PM
>> To: darren.galpin@infineon.com
>> Cc: Matan Vax; Mike.Bartley@infineon.com; Serrie.Chapman@infineon.com;
>> ieee1647@eda.org
>> Subject: Re: SN constants
>
>> Darren, you wrote:
>
>>> In the donation for real types, there exists two tables, 17-2
>>> Mathematical constants, and 17-3 Physical constants.  Note that all
>>> of the constants defined are prefixed with SN_.
>
>>> Having looked through the LRM, there are no constants there defined
>>> starting with SN_, and SN_ would indicate that it was Specman
>>> specific.  Should such constants actually be deleted from the
>>> standard, and be left to be tool specific?  What are your thoughts?
>
>> The standard currently includes a list of predefined constants in
>> table 6 of chapter 4.  As expected, none of these use the SN_ prefix.
>> I suggest we consider adding these constants to the standard,
>> substituting a new prefix for the SN_ prefix.  The prefix serves the
>> purpose of preventing collisions in the constant name space of the
>> environment.  A prefix such as "P1647_" would so nicely:
>
>>     Table 17-2
>
>>     Donated         Standard
>>     Constant        Constant
>>     Value           Value
>>     -----------     --------------
>>     SN_M_E          P1647_M_E
>>     SN_M_LOG2E      P1647_M_LOG2E
>>     SN_M_LOG10E     P1647_M_LOG10E
>>     SN_M_LN2        P1647_M_LN2
>>     SN_M_LN10       P1647_M_LN10
>>     SN_M_PI         P1647_M_PI
>>     SN_M_TWO_PI     P1647_M_TWO_PI
>>     SN_M_PI_2       P1647_M_PI_2
>>     SN_M_PI_4       P1647_M_PI_4
>>     SN_M_1_PI       P1647_M_1_PI
>>     SN_M_2_PI       P1647_M_2_PI
>>     SN_M_2_SQRTPI   P1647_M_2_SQRTPI
>>     SN_M_SQRT2      P1647_M_SQRT2
>>     SN_M_SQRT1_2    P1647_M_SQRT1_2
>
>
>>     Table 17-3
>
>>     Donated         Standard
>>     Constant        Constant
>>     Value           Value
>>     -----------     --------------
>>     SN_P_Q          P1647_P_Q
>>     SN_P_C          P1647_P_C
>>     SN_P_K          P1647_P_K
>>     SN_P_H          P1647_P_H
>>     SN_P_EPS0       P1647_P_EPS0
>>     SN_P_U0         P1647_P_U0
>>     SN_P_CELSIUS0   P1647_P_CELSIUS0
>
>
>--
>                                                        |
>    Andy@Piziali.dv.org                   ________------+------________
>                                                       / \
>    PGP Key:                                          *---*
>    http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6F66CA9F

-- This message has been scanned for viruses anddangerous content by MailScanner, and isbelieved to be clean.
Received on Wed Dec 16 01:10:03 2009

This archive was generated by hypermail 2.1.8 : Wed Dec 16 2009 - 01:10:12 PST