From: Kjeld Borch Egevang <kjelde@mips.com>
To: <linux-mips@oss.sgi.com>
Subject: Re: ieee754_csr is the problem (Re: lazy fpu switch irrelavant to no-fpu case?
Date: Fri, 22 Feb 2002 18:08:51 +0100 [thread overview]
Message-ID: <200202221708.g1MH8pX13027@coplin19.mips.com> (raw)
In-Reply-To: <006701c1bb87$b2b6fb80$0deca8c0@Ulysses>
In mips.test, you wrote:
>This is what I get for processing my mail in-order.
>I just got done writing a message asking if the
>ieee_754_csr issue might be at the root of your
>problem.
>
>Anyway, rather than create an array of the damned
>things, I would think that the "best" thing to do would
>be to merge the "abstract" IEEE CSR with the
>simulated MIPS CSR (by adding the "noq" and
>"nod" bits in otherwise unused/reserved bit positions),
>and using the thread-local CSR copy for all of the
>ieee_754_csr manipulations, much as I did for
>the FP registers. That would be a bit more intrusive
>than your proposed hack, however, and only slightly
>more efficient.
I've been wondering: Why was the CSR copy made in the first place?
/Kjeld
--
_ _ ____ ___ Mailto:kjelde@mips.com
|\ /|||___)(___ MIPS Denmark Direct: +45 44 86 55 85
| \/ ||| ____) Lautrupvang 4 B Switch: +45 44 86 55 55
TECHNOLOGIES DK-2750 Ballerup Fax...: +45 44 86 55 56
Denmark http://www.mips.com/
WARNING: multiple messages have this Message-ID (diff)
From: Kjeld Borch Egevang <kjelde@mips.com>
To: linux-mips@oss.sgi.com
Subject: Re: ieee754_csr is the problem (Re: lazy fpu switch irrelavant to no-fpu case?
Date: Fri, 22 Feb 2002 18:08:51 +0100 [thread overview]
Message-ID: <200202221708.g1MH8pX13027@coplin19.mips.com> (raw)
Message-ID: <20020222170851.YshjT_QzCwUZF-bSuR2QvWqLiSzmjYR2PnyIcIzJitQ@z> (raw)
In-Reply-To: <006701c1bb87$b2b6fb80$0deca8c0@Ulysses>
In mips.test, you wrote:
>This is what I get for processing my mail in-order.
>I just got done writing a message asking if the
>ieee_754_csr issue might be at the root of your
>problem.
>
>Anyway, rather than create an array of the damned
>things, I would think that the "best" thing to do would
>be to merge the "abstract" IEEE CSR with the
>simulated MIPS CSR (by adding the "noq" and
>"nod" bits in otherwise unused/reserved bit positions),
>and using the thread-local CSR copy for all of the
>ieee_754_csr manipulations, much as I did for
>the FP registers. That would be a bit more intrusive
>than your proposed hack, however, and only slightly
>more efficient.
I've been wondering: Why was the CSR copy made in the first place?
/Kjeld
--
_ _ ____ ___ Mailto:kjelde@mips.com
|\ /|||___)(___ MIPS Denmark Direct: +45 44 86 55 85
| \/ ||| ____) Lautrupvang 4 B Switch: +45 44 86 55 55
TECHNOLOGIES DK-2750 Ballerup Fax...: +45 44 86 55 56
Denmark http://www.mips.com/
next prev parent reply other threads:[~2002-02-22 18:09 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-02-22 2:48 lazy fpu switch irrelavant to no-fpu case? Jun Sun
2002-02-22 3:57 ` ieee754_csr is the problem (Re: " Jun Sun
2002-02-22 3:57 ` Jun Sun
2002-02-22 9:59 ` Kevin D. Kissell
2002-02-22 9:59 ` Kevin D. Kissell
2002-02-22 17:08 ` Kjeld Borch Egevang [this message]
2002-02-22 17:08 ` Kjeld Borch Egevang
2002-02-22 9:45 ` Kevin D. Kissell
2002-02-22 9:45 ` Kevin D. Kissell
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=200202221708.g1MH8pX13027@coplin19.mips.com \
--to=kjelde@mips.com \
--cc=linux-mips@oss.sgi.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.