From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailserv2.iuinc.com (IDENT:qmailr@mailserv2.iuinc.com [206.245.164.55]) by puffin.external.hp.com (8.9.3/8.9.3) with SMTP id NAA11661 for ; Fri, 29 Sep 2000 13:40:59 -0600 Received: from ottawa.linuxcare.com (HELO tarwebok) (216.208.98.2) by mailserv2.iuinc.com with SMTP; 29 Sep 2000 19:41:46 -0000 Received: from dhd by tarwebok with local (Exim 3.12 #1 (Debian)) id 13f62g-00019B-00 for ; Fri, 29 Sep 2000 15:41:58 -0400 To: parisc-linux@thepuffingroup.com Subject: Re: [parisc-linux] floating point exception error References: <20000927195500.57241381CD@carmen.fc.hp.com> <873dilo9dp.fsf@tarwebok.i-did-not-set--mail-host-address--so-shoot-me> <87snqk1q2o.fsf@linuxcare.com> <87hf6znjc7.fsf@ottawa.linuxcare.com> <87bsx7nhji.fsf@ottawa.linuxcare.com> From: David Huggins-Daines Date: 29 Sep 2000 15:41:58 -0400 In-Reply-To: David Huggins-Daines's message of "29 Sep 2000 15:07:29 -0400" Message-ID: <8766nfnfy1.fsf@ottawa.linuxcare.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 List-ID: Ah, well, on further study, the documentation (http://puffin.external.hp.com/docs/pcxl2_ers.pdf) explains all, for the 7300LC at least. However, if we intend to support PA2.0, then we will need to have some kind of documentation on what parts of the FPU architecture the various PA2.0 chips implement. > So, are unordered comparisons just not handled by the 7300LC? Which According to the docs: 4.3 Unimplemented Exception/Trap The only kind of exception generated by the PA7300LC floating point is the unimplemented exception. It is always signaled with a delayed floating­point exception trap. The unimplemented trap is raised instead of the overflow, un- derflow, division by zero, invalid and inexact traps. Well, that's just great :P > I have no idea why the exception shows up in FR1L instead of in FR0R According to the docs: 4.3.6 Exception Registers The excepting flop will be in exception register 2. PA­RISC 1.1 exception codes are used. Exception registers 1, 3, 4, 5, 6, and 7 may be loaded or stored, but hardware will never place an excepting flop in them. Exception register 2 is guaranteed to retain its contents as long as the T bit remains set and continuing thereafter until a flop is executed, or until it is explicitly cleared by software with a load. Okay, that makes life easier, at least. I'm really fearful of what the 8500/8600 will do though. You'd think that since they execute out of order they'd be able to provide some sort of precise trapping.. > It looks like we are going to need some floating-point completion > support in the kernel, which evidently is going to involve walking the > trap shadow and other fun things I thought you only had to do on DEC > machines ;) Well, I guess not on 7300LC at least, given that only FR1L (except2) is used. So that's a relief. I'll see if I can write a rudimentary completion handler today that should at least enable us to build awk and so forth. -- dhd@linuxcare.com, http://www.linuxcare.com/ Linuxcare. Support for the revolution.