From: Jun Sun <jsun@mvista.com>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: "Kevin D. Kissell" <kevink@mips.com>, linux-mips@oss.sgi.com
Subject: Re: config option vs. run-time detection (the debate continues ...)
Date: Fri, 09 Feb 2001 13:31:07 -0800 [thread overview]
Message-ID: <3A84619B.94224C30@mvista.com> (raw)
In-Reply-To: Pine.GSO.3.96.1010209212607.13007B-100000@delta.ds2.pg.gda.pl
"Maciej W. Rozycki" wrote:
>
> On Fri, 9 Feb 2001, Jun Sun wrote:
>
> > Do you like run-time detection better because it allows a kernel to run on
> > CPUs both with a FPU and without a FPU? Or there is something else to it?
>
> Nope. There are certain explicit actions that are to be performed by the
> kernel if a real FPU is present, such as saving and restoring its
> registers or setting the control register. Therefore the kernel has to
> know if a real part is present and act accordingly. Maintaining a table
> of all CPU ids ever manufactured and manually setting the FPU presence bit
> is unreliable, especially as there are chips which cannot be classified
> this way, e.g. knowing your CPU is an R3000A you don't know if an R3010A
> FPU is soldered as well or not.
>
Apparently you did not read my first email on this thread. :-)
I agree "Maintaining a table of all CPU ids ever manufactured and manually
setting the FPU presence bit is unreliable ...".
I was debating about how we let kernel know if there is a real FPU:
a) an explicit config option, CONFIG_HAS_FPU, (which is not associated with
PrID), plus "#ifdef CONFIG_HAS_FPU ..." code. Or
b) have run-time detection and many "if .. then .." code.
I listed some pro's and con's for both of them in my first email. Right now,
I found myself not having a strong preference but still biased towards config
option approach ( - as if that really matters. :-0)
> > Another question. I know with mips32 and mips64 we can do run-time detection
> > reliably. What about other existing processors?
>
> I've sent a quote from an IDT manual recently. It recommended to use the
> FPU implementation ID to check if an FP hw is present. I believe it
> should work for any sane implementation of a MIPS CPU. See the mail for
> details.
>
I actually don't understand your IDT quote. It requires one to call mfc1 to
get FCR0. On many CPUs without a FPU, this will generate an exception. Are
you suggesting that we should catch the exception and from that we conclude
there is no FPU present?
Jun
next prev parent reply other threads:[~2001-02-09 21:33 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-02-08 20:27 config option vs. run-time detection (the debate continues ...) Jun Sun
2001-02-08 22:06 ` Kevin D. Kissell
2001-02-08 22:06 ` Kevin D. Kissell
2001-02-08 22:58 ` Jun Sun
2001-02-09 0:25 ` Kevin D. Kissell
2001-02-09 0:25 ` Kevin D. Kissell
2001-02-09 11:48 ` Maciej W. Rozycki
2001-02-09 12:56 ` Kevin D. Kissell
2001-02-09 12:56 ` Kevin D. Kissell
2001-02-09 13:06 ` Maciej W. Rozycki
2001-02-09 19:59 ` Jun Sun
2001-02-09 20:39 ` Maciej W. Rozycki
2001-02-09 21:31 ` Jun Sun [this message]
2001-02-10 9:01 ` Maciej W. Rozycki
2001-02-12 18:21 ` Jun Sun
2001-02-13 18:31 ` Maciej W. Rozycki
2001-02-09 22:12 ` Kevin D. Kissell
2001-02-09 22:12 ` Kevin D. Kissell
2001-02-10 9:05 ` Maciej W. Rozycki
2001-02-09 19:58 ` Florian Lohoff
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=3A84619B.94224C30@mvista.com \
--to=jsun@mvista.com \
--cc=kevink@mips.com \
--cc=linux-mips@oss.sgi.com \
--cc=macro@ds2.pg.gda.pl \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox