From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by dsl2.external.hp.com (Postfix) with ESMTP id C0FA04829 for ; Tue, 12 Nov 2002 10:42:55 -0700 (MST) Reply-To: From: "Jim Hull" To: "'John David Anglin'" Cc: , , Subject: RE: [parisc-linux] glibc 2.3.1 - It's alive! - patches Date: Tue, 12 Nov 2002 09:42:51 -0800 Message-ID: <00fc01c28a72$ec50fa70$6763f40f@cup.hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" In-Reply-To: <200211121544.gACFi8Na004766@hiauly1.hia.nrc.ca> Sender: parisc-linux-admin@lists.parisc-linux.org Errors-To: parisc-linux-admin@lists.parisc-linux.org List-Help: List-Post: List-Subscribe: , List-Id: parisc-linux developers list List-Unsubscribe: , List-Archive: John David Anglin wrote: > 2) A fcpy insn should raise an exception if it depends on the > result of a pending trapping insn (the current code doesn't). > It would be best to not use register 0 or the source register > for the destination register since in theory the processor > would then know the operation is a nop. Then, the insn could > be reordered or discarded. The fcpy insn is nice since it > is non-arithmetic and doesn't cause an invalid operation > exception when a NaN is copied. The fcmp insn isn't quite > as nice since it will generate an invalid operation when one > of the values is a signaling NaN, or if the low-order bit > of the condition code is 1 and one of the values is an NaN. This isn't right. According to "Delayed Trapping" on p. 10-5 of the PA-RISC 2.0 book, an fcpy need not raise a pending exception, because it is not mentioned in the "delayed trap must occur" list. Now, it's possible that it might (usually) work on the processor implementations you're interested in, but it's not architecturally guaranteed. -- Jim HP PA-RISC (and IPF) Processor Architect