|
![](/i/fill.gif) |
Warp <war### [at] tag povray org> wrote:
> Even if Intel does produce a new processor with no FPU, it would *still*
> not make sense for the OS'es to drop support. Why? Because the OS'es will
> be run in older processors for decades. Heck, even today there are 80386's
> running and used out there. Do you remember when the 80386 was first
> introduced? Something like 20 years ago?
And because they're that old, you'll have trouble running XP on them, and Vista
64 won't run on them at all. And you can compile a Linux kernel that doesn't
include support for them either.
> The way you "deprecate" it is by making newer compilers not use it.
That's already being done, as it seems.
> The OS plays no role in this process.
It does. As long as it invokes x87 FPU commands in an attempt to store their
contents for a task switch, you can't strip those commands from your CPU,
because it would break the OS.
> > We're not talking abount months here. We're talking about years. Lots of.
>
> And exactly how does the OS drop support for the FPU gradually, during
> the years?
Don't ask me. Ask Microsoft, Apple, the Linux community, and Intel and AMD. I'm
not a representative of said companies / communities.
I'd say: Deprecate x87 FPU use; encourage compiler vendors to default to not
using it; introduce new OS API calls that do no longer use x87 FPU registers
for parameter passing (if applicable); deprecate the old API calls; deprecate
x87 FPU use, deprecate it again and again - and then ultimately release a new
version that just doesn't support it anymore.
By that time - to mention it again - the percentage of software actually using
the x87 FPU will have diminished. That is the "gradual" part of this phasing
out.
Post a reply to this message
|
![](/i/fill.gif) |