From Keith.Bierman@Eng.Sun.COM Thu Aug 8 21:06:05 1996 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id VAA26211 for ; Thu, 8 Aug 1996 21:06:03 +0200 Received: by mercury.Sun.COM (Sun.COM) id MAA07433; Thu, 8 Aug 1996 12:04:49 -0700 Received: from chiba.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA10197; Thu, 8 Aug 1996 12:04:08 -0700 Received: from chiba by chiba.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA14365; Thu, 8 Aug 1996 12:04:05 -0700 Message-Id: <199608081904.MAA14365@chiba.eng.sun.com> To: Miles.Ellis@etrc.ox.ac.uk (Miles Ellis) cc: sc22wg5 Subject: N1213 Date: Thu, 08 Aug 1996 12:04:04 -0700 From: Keith Bierman QED Before this becomes the offical paper, it might be good to ensure that I recorded the votes correctly. N1213 My (khb) record of the decisions made in regard to the specific questions raised in N1195r1. The process was a two step one, in that a subgroup considered the various questions. Those questions that couldn't be resolved by subgroup were brought before a plenary session of WG5. In the end there was only one issues which resulted in change(s) to the TR, that is item 5 below. >1. Christian Weber and Wolfgang Walter think that it is processor >dependent whether IEEE overflow or IEEE invalid signals when a 12-6 WG5 voted that the result must be invalid (vs. may be invalid). This confirms the text of the TR. >2. ...in a sequence of statements.... 14-4 WG5 voted keep the text as is. >3. ... I/O Subgroup met and discussed the issue at length. It was noted that such conversions *can* be coded by users using facilities in the language. However it certainly would be desirable to have READ/WRITE behave the "right" way. That would be outside the scope of the TR. What would have been within the scope of the TR, new conversion routines was unnecessary, as they can be coded using facilities already in the language. During integration of the TR into F2K it is hoped that the issue of base conversion will be addressed. >4. ... change the name of some exceptions 10-7 to keep the names as they are. >5. The present wording of the rules for procedures .... 9-6 to require the processor to manipulate the flags accordingly. However it was noted that the precise text of the TR is wrong. See page 15 (section 15.2) last paragraph "If a flag is signaling on entry to a procedure, it shall be signaling on return. If a procedure accesses a flag with an invocation of IEEE_GET_FLAG, it shall have set the flag quiet in a prior invocation of IEEE_SET_FLAG in the scoping unit". This text, as written, disallowed the examples in the paper. >6. ...applicable to PURE only.... 13-5 to keep the text as is (applying to all not just PURE). The other questions were dealt with in subgroup, resulting in no changes to the TR.