All of lore.kernel.org
 help / color / mirror / Atom feed
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
    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.

  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.