From synopsys!Synopsys.COM!crc@fernwood.mpk.ca.us Fri Nov 2 15:05:16 1990 Return-Path: Received: from suntan.viewlogic.com by twix (4.0/SMI-4.0) id AA15456; Fri, 2 Nov 90 15:05:13 EST Received: from uunet.uu.net by suntan.viewlogic.com (4.0/SMI-4.0) id AA00556; Fri, 2 Nov 90 15:04:56 EST Received: from clsi.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA03872; Fri, 2 Nov 90 15:02:49 -0500 Received: from uunet.UUCP by clsi.clsi.COM (4.0/SMI-4.0) id AA10393; Fri, 2 Nov 90 02:19:09 EST Received: from fernwood.mpk.ca.us by uunet.uu.net (5.61/1.14) with SMTP id AA20970; Thu, 1 Nov 90 20:06:46 -0500 Received: by fernwood.mpk.ca.us; id AA06843; Thu, 1 Nov 90 17:05:28 -0800 Received: from crc.Synopsys.COM by Synopsys.COM (4.0/SMI-4.0) id AA03826; Thu, 1 Nov 90 16:59:18 PST Received: by crc.Synopsys.COM (4.0/SMI-4.0) id AA28531; Thu, 1 Nov 90 16:55:07 PST Date: Thu, 1 Nov 90 16:55:07 PST From: crc@Synopsys.COM (Clive Charlwood) Message-Id: <9011020055.AA28531@crc.Synopsys.COM> To: !vasg_group@fernwood.mpk.ca.us Subject: IR 23 (pauls new physical type one) Status: RO I agree with Pauls IR. However, there is another point that we need to be considered. The Synopsys analyzer does not look for constraint errors when analyzing the secondary unit declaration. We do however verify that the position number of the secondary unit declaration does not overflow the integer bounds (-2147483647 to +2147483647). We consider that the following code would be legal on a system that had say 128 bit integers. But, on a 32 implementation we would reject the line "ms = 1000 us". Since there are more that 2147483647 fs in a ms. type TIME is range -2147483647 to +2147483647 units fs; -- femtosecond ps = 1000 fs; -- picosecond ns = 1000 ps; -- nanosecond us = 1000 ns; -- microsecond ms = 1000 us; -- millisecond sec = 1000 ms; -- second min = 60 sec; -- minute hr = 60 min; -- hour end units; Would anyone like to comment? From clsi!rtpuv1!mench@uunet.UU.NET Fri Nov 2 15:05:13 1990 Return-Path: Received: from suntan.viewlogic.com by twix (4.0/SMI-4.0) id AA15453; Fri, 2 Nov 90 15:05:06 EST Received: from uunet.uu.net by suntan.viewlogic.com (4.0/SMI-4.0) id AA00553; Fri, 2 Nov 90 15:04:47 EST Received: from clsi.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA03987; Fri, 2 Nov 90 15:03:02 -0500 Received: from rtpuv1.UUCP by clsi.clsi.COM (4.0/SMI-4.0) id AA10981; Fri, 2 Nov 90 10:24:01 EST Message-Id: <9011021524.AA10981@clsi.clsi.COM> Received: by rtpuv1 (DECUS UUCP w/Smail); Fri, 2 Nov 90 09:45:25 EST Date: Fri, 2 Nov 90 09:45:25 EST From: Paul Menchini To: clsi!vasg_group@uunet.UU.NET Subject: RE: Clive's comments on IR23 Status: RO I disagree with the notion that an analyzer should examine the position number of any units (base or secondary) for constraint errors. This is one of the things that I was attempting to discuss in the IR, but Clive said it much better than I did. (Clive, when the dust settles on this, I'd like to incorporate your language into the IR, if it's still germane.) As support for this position, I once again cite 3.1.3.1, which does not disallow the secondary units of Std.Standard.Time whose position numbers fall outside of the range -2**31-1 to 2**31-1. A weaker justification is the last sentence of paragraph 3 of Section 7.5: Furthermore, if a universal expression is a static expression, then the evaluation must be exact. True, we're dealing with physical types, but the calculation of the position number as specified in paragraph 7 of Section 3.1.3 appears to be a calculation involving only *universal integers*, which puts it in the domain of infinite- precision calculations. In any case, secondary units are merely scale factors; as such, 1E-10 hr is every bit as valid on a 32-bit system as it is on a 128-bit system. Moreover, 1 hr is valid on a 32-bit system if the resolution limit for a particular execution of a model is ms (Section 3.1.3.1, paragraph 2). Well, that's my two cents. Anyone want to up the ante? (Any of you guys play poker? That might be a real good way to relax one evening per ISAC meeting!) --Paul From synopsys!Synopsys.COM!crc@fernwood.mpk.ca.us Sat Nov 3 15:02:10 1990 Return-Path: Received: from suntan.viewlogic.com by twix (4.0/SMI-4.0) id AA15718; Sat, 3 Nov 90 15:02:09 EST Received: from uunet.uu.net by suntan.viewlogic.com (4.0/SMI-4.0) id AA02068; Sat, 3 Nov 90 15:01:49 EST Received: from clsi.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA04216; Sat, 3 Nov 90 15:01:48 -0500 Received: from uunet.UUCP by clsi.clsi.COM (4.0/SMI-4.0) id AA13944; Sat, 3 Nov 90 02:05:32 EST Received: from Fernwood.MPK.CA.US by uunet.uu.net (5.61/1.14) with SMTP id AA28993; Fri, 2 Nov 90 18:09:36 -0500 Received: by fernwood.mpk.ca.us; id AA06670; Fri, 2 Nov 90 15:05:17 -0800 Received: from crc.Synopsys.COM by Synopsys.COM (4.0/SMI-4.0) id AA20837; Fri, 2 Nov 90 14:49:20 PST Received: by crc.Synopsys.COM (4.0/SMI-4.0) id AA29689; Fri, 2 Nov 90 14:45:07 PST Date: Fri, 2 Nov 90 14:45:07 PST From: crc@Synopsys.COM (Clive Charlwood) Message-Id: <9011022245.AA29689@crc.Synopsys.COM> To: !vasg_group@fernwood.mpk.ca.us Subject: Re: pauls reply to Clive's comments on IR23 Status: RO 1. Why don't we discuss this at Vantage. 2. It would be better to (temporarily) ignore Std.Standard.Time. This is special case since a) the declaration is never analyzed, and therfore can not rejected. b) It has this odd *resolution limit* characteristic. 3. The concept of infinite-precision calculations is new to me. I saw the last paragraph that said "An implementation may restrict the bounds of the range constraint if integer types, other than type *universal_integer*." ------------------------------------ This seems to imply, as you said, that there is is no constraint on univeral_intergers. Does that make the following code legal? constant zero: integer := 10E50 - 10E50; Paragraph 4 of 3.1.2 states that "Integer literals are the literals of an anonymous type that is called *universal_integer* in this manual" From ogicse!mntgfx!dad.MENTOR.COM!cswart@decwrl.dec.com Mon Nov 5 02:12:28 1990 Return-Path: Received: from suntan.viewlogic.com by twix (4.0/SMI-4.0) id AA16434; Mon, 5 Nov 90 02:12:27 EST Received: from uunet.uu.net by suntan.viewlogic.com (4.0/SMI-4.0) id AA03202; Mon, 5 Nov 90 02:12:04 EST Received: from clsi.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA20806; Mon, 5 Nov 90 02:01:57 -0500 Received: from uunet.UUCP by clsi.clsi.COM (4.0/SMI-4.0) id AA14374; Sun, 4 Nov 90 02:01:28 EST Received: from DECWRL.DEC.COM by uunet.uu.net (5.61/1.14) with SMTP id AA25129; Sat, 3 Nov 90 18:55:33 -0500 Received: by decwrl.dec.com; id AA22096; Sat, 3 Nov 90 15:54:18 -0800 Received: by cse.ogi.edu (5.61+eap+OGI_1.1.named/IDA-1.2.8+OGI_1.12) id AA19287; Sat, 3 Nov 90 15:37:41 -0800 Received: by pdx.MENTOR.COM ( 5.52 (84)/smail2.5/09-24-87/Mentor) id AA22037; Sat, 3 Nov 90 15:01:31 PST Received: by dad.MENTOR.COM ( 5.52 (84)/smail2.5/09-24-87/Mentor) id AA05211; Sat, 3 Nov 90 15:01:51 PST Date: Sat, 3 Nov 90 15:01:51 PST From: ogicse!dad.MENTOR.COM!cswart@decwrl.dec.com (Chuck Swart) Message-Id: <9011032301.AA05211@dad.MENTOR.COM> To: ogicse!Synopsys.COM!crc@decwrl.dec.com Cc: ogicse!mntgfx!cswart@decwrl.dec.com, ogicse!clsi.com!vasg_group@decwrl.dec.com Subject: re: pauls reply to Clive's comments on IR23 Status: RO I have a comment on item 3. The code you mention probably is not legal for the following reason: the type of 10E50 - 10E50 must be integer to match the type of zero. Therefore the type of the operands to - must be integer (assuming only the standard - is visible.) Therefore, an implicit conversion of each of the literals 10E50 to integer must be performed, since "there is no legal interpretation of this context without this conversion." (LRM p7-13.) The conversion to integer will cause overflow under almost any reasonable representation of integers. So far you are safe. However, consider the following related example: constant zero: integer := integer'pos(10E50 - 10E50); Here you are stuck. The LRM forces you to evaluate this exactly. Similarly for constant real_zero: real := real(10.0E5000/10.0E5000); <> to: !vasg_group@fernwood.mpk.ca.us from: uunet!fernwood.mpk.ca.us!synopsys!Synopsys.COM!crc date: Fri, 2 Nov 90 14:45:07 PST subj: Re: pauls reply to Clive's comments on IR23 sender: uunet!Synopsys.COM!crc (Clive Charlwood) sent: 11/03/1990 1:33 pm (PDT) --------- **| 1. Why don't we discuss this at Vantage. 2. It would be better to (temporarily) ignore Std.Standard.Time. This is special case since a) the declaration is never analyzed, and therfore can not rejected. b) It has this odd *resolution limit* characteristic. 3. The concept of infinite-precision calculations is new to me. I saw the last paragraph that said "An implementation may restrict the bounds of the range constraint if integer types, other than type *universal_integer*." ------------------------------------ This seems to imply, as you said, that there is is no constraint on univeral_intergers. Does that make the following code legal? constant zero: integer := 10E50 - 10E50; Paragraph 4 of 3.1.2 states that "Integer literals are the literals of an anonymous type that is called *universal_integer* in this manual"