From: David Huggins-Daines <dhd@linuxcare.com>
To: parisc-linux@thepuffingroup.com
Subject: Re: [parisc-linux] floating point exception error
Date: 29 Sep 2000 15:41:58 -0400 [thread overview]
Message-ID: <8766nfnfy1.fsf@ottawa.linuxcare.com> (raw)
In-Reply-To: David Huggins-Daines's message of "29 Sep 2000 15:07:29 -0400"
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
floatingpoint 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. PARISC 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.
next prev parent reply other threads:[~2000-09-29 19:40 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-09-27 19:55 [parisc-linux] floating point exception error Matt Taggart
2000-09-27 20:41 ` David Huggins-Daines
2000-09-28 15:41 ` David Huggins-Daines
2000-09-29 18:28 ` David Huggins-Daines
2000-09-29 18:56 ` John David Anglin
2000-09-29 19:07 ` David Huggins-Daines
2000-09-29 19:41 ` David Huggins-Daines [this message]
2000-10-02 0:33 ` John David Anglin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8766nfnfy1.fsf@ottawa.linuxcare.com \
--to=dhd@linuxcare.com \
--cc=parisc-linux@thepuffingroup.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.