Warp <war### [at] tagpovrayorg> wrote:
>   What you are talking is completely different. It's a total cut from
> software older than a certain age.

No, because software older than a certain age is 32-bit software.

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   How many times do I have to repeat myself? It doesn't make any sense.

How long do I have to repeat myself: They're gonna do it some day.

Maybe that'll be the day when they introduce a whole new generation of CPUs
which is no longer compatible to x86 at all, but the day will come.

And they're pondering the idea (or at least have pondered it some time like
beginning of 2008) of dropping the x87 FPU support earlier. I have no idea why
(except wild guesses), but it must have went through their heads.

So all I'm saying here is: Make your software ready for it if it doesn't really
need the FPU. And if AMD is right in that it's not a loss but actually even a
gain, then all the more reason to do so.

That's the bottom line of it. No more, and no less.

All I can give you regarding the "why" is some wild guesses, and they *do* make
*some* sense. It's not *total* bullshit.

>   Even if there's 0 new software which uses the FPU, if the OS is run on
> a computer with an FPU, it makes absolutely no sense not supporting it and
> actively boycotting any software which tries to use it.

I repeat, it *does* make *some* sense (I'm not saying it makes *enough* sense):

- There *may* be reasons for chip manufacturers to want to get rid of the x87
FPU in their CPU design. It's complex, and may be in the way for optimizations
of other components. So holding on to the FPU may actually be a performace
problem for *all* software that *does* fine without it or at least *could*
(which I bet is the vast majority).

- You can't strip the x87 FPU off the CPU unless the OS are ready for it, for
about the same reason that you (to some degree undoubtly righteously) argue
that you can't just strip FPU support off the OS.

- The OS *may* not be ready for it unless it itself has totally dropped the x87
FPU support (e.g. due to FPU commands that it may have to issue during task
switching, which may cause a mess on a CPU that doesn't support the x87 FPU)

So we *may* be talking about a way to achieve some significant additional
speedup for 99% of the software that will be out there in, say, 5 years.

If that is the case, I would see that as enough reason to break a few other
pieces of software.


BTW, your claim that you can get every old stuff to run on Vista is BS. Think
for example about the numerous DOS games, which are being "actively boycotted"
and denied direct access to hardware when run under modern OS. And other
software suffered the same issues. Why? Because there was a benefit to be
gained - in that case in terms of stability. Would you say that was a wrong
move?

I'm glad Windows is as stable as it is. (Which is not to say that I praise it
for exceptional stability, but stability back then was far worse.)

Post a reply to this message

clipka wrote:
>> Actually, it is not more complex than integer addition and multiplication.
<snip>
> - Normalize the smaller number to match the larger one's exponent
<snip>

This is a simple shifting operation. The other operations you mentioned are 
bit-tests and other simple logic on a few bits.

	Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> >> Actually, it is not more complex than integer addition and multiplication.
> <snip>
> > - Normalize the smaller number to match the larger one's exponent
> <snip>
>
> This is a simple shifting operation. The other operations you mentioned are
> bit-tests and other simple logic on a few bits.

And yet it doesnt change the fact that it *IS* more complex than integer
addition: It is not just an elementary operation, but a combination of multiple
such ops.

Well, maybe not much more complex than the int multiplication, but that wasn't
my initial point anyway. I'd call integer multiplication non-trivial in that
sense as well.

Post a reply to this message

clipka <nomail@nomail> wrote:
> Warp <war### [at] tagpovrayorg> wrote:
> >   How many times do I have to repeat myself? It doesn't make any sense.

> How long do I have to repeat myself: They're gonna do it some day.

  Can you give me a reference to, for example, an online linux community
where they are discussing this?

  Or are you, too, making a claim with absolutely no proof?

  (In fact, with linux it even *might* be plausible because 99.9% of the
software for it is open source and it's more or less trivial for every
distro to just recompile *everything* for the new system. With Windows,
which is plagued with old, closed source software, I don't think so.)

> Maybe that'll be the day when they introduce a whole new generation of CPUs
> which is no longer compatible to x86 at all, but the day will come.

  Did I say something different? No.

  What I said that making an OS which works on a PC with an FPU so that it
deliberately stops programs from using the FPU makes absolutely no sense.

> - There *may* be reasons for chip manufacturers to want to get rid of the x87
> FPU in their CPU design.

  Which has nothing to do with the OS dropping support even in CPUs with
a FPU.

> - You can't strip the x87 FPU off the CPU unless the OS are ready for it, for
> about the same reason that you (to some degree undoubtly righteously) argue
> that you can't just strip FPU support off the OS.

  And the OS cannot drop support because 99% of software uses it. So they
are rather locked.

> - The OS *may* not be ready for it unless it itself has totally dropped the x87
> FPU support (e.g. due to FPU commands that it may have to issue during task
> switching, which may cause a mess on a CPU that doesn't support the x87 FPU)

  I'm pretty sure it's very easy for them to compile a special version of
the OS for a platform with no FPU. I would be surprised if you couldn't do
that eg. with the Linux kernel.

  It's not a question of difficulty. It's a question of allowing software
to run.

> So we *may* be talking about a way to achieve some significant additional
> speedup for 99% of the software that will be out there in, say, 5 years.

  Software speeding up by using SSE has nothing to do with whether the OS
supports the FPU or not.

> BTW, your claim that you can get every old stuff to run on Vista is BS. Think
> for example about the numerous DOS games, which are being "actively boycotted"
> and denied direct access to hardware when run under modern OS.

  Vista doesn't boycott old DOS software any more than eg. Linux does.
They are basically completely different operating systems. (Well, DOS is
*not* an operating system at all.)

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> clipka <nomail@nomail> wrote:
>> Warp <war### [at] tagpovrayorg> wrote:
>>>   How many times do I have to repeat myself? It doesn't make any sense.
> 
>> How long do I have to repeat myself: They're gonna do it some day.
> 
>   Can you give me a reference to, for example, an online linux community
> where they are discussing this?

Maybe they are not as argumentative as you about things they cannot change? :-P

As I said before, the x86-64 ABI requires passing of floating-point 
arguments in SSE registers on Windows, Linux and Mac OS X. You are free to 
Google for gcc's implementation of the x86-64 ABI, which does exactly that. 
Maybe try <http://www.google.com/search?q=site%3Agcc.gnu.org+x87+deprecated>

And no, I don't want to get into an argument over what search results this 
query returns!!!

	Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> As I said before, the x86-64 ABI requires passing of floating-point 
> arguments in SSE registers on Windows, Linux and Mac OS X. You are free to 
> Google for gcc's implementation of the x86-64 ABI, which does exactly that. 
> Maybe try <http://www.google.com/search?q=site%3Agcc.gnu.org+x87+deprecated>

  I think that you both are confusing two things with each other.

  Compilers and software out there (including operating systems) are slowly
migrating to use SSE instead of the FPU, at least in the new 64-bit systems
(which is non-problematic because all amd/intel-based 64-bit systems do
have full SSE support).

  However, that is, for the umpteeth time, not what I'm objecting against.

  What I'm objecting against is the claim that operating systems running
on hardware *with* FPU are going to simply deliberately deny software
working access to the FPU.

  For the umpteeth time, that doesn't make any freaking sense. Is, for
example, the linux project going to say: "Sorry, you can't run the newest
kernel in a Pentium4 because we decided to drop support for programs using
the FPU"?

  It may be that in the future the kernel itself may not use the FPU at
all. That's, however, a completely different thing for it to drop support
for processors with an FPU and all software using it. It would, in fact,
completely go against one of the design principles of linux: To be as
portable as possible. Linux is one of the most portable systems out there
(only netbsd rivals it). Are they going to drop support for 90% of the
hardware out there for no good reason? I don't think so.

  When I ask about any concrete evidence that any operating system out
there is planning to actively deny access to the FPU, all I get is
material which talks about compilers migrating to SSE in 64-bit systems,
which has nothing to do with the issue.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   When I ask about any concrete evidence that any operating system out
> there is planning to actively deny access to the FPU, all I get is
> material which talks about compilers migrating to SSE in 64-bit systems,
> which has nothing to do with the issue.

Guess what ABI you need to use to call your operating system functions that 
take floating-point arguments on x86-64? Hmm, you guess right: You put them 
in SSE registers. And you cannot copy directly between SSE and x87 registers 
(you need to go through memory). That is called "deprecated by an operating 
system".

And maybe you ought to look up the word "deprecated" in the dictionary. It 
is *not* a synonym for "deny"...

	Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> And maybe you ought to look up the word "deprecated" in the dictionary. It 
> is *not* a synonym for "deny"...

  So OS'es are *not* going to drop support for programs using the FPU.
They will still run older software which uses the FPU (at least on platforms
which *have* a FPU). It's just that software written for newer 64-bit
processors should not use it.

  That's all I wanted to agree with.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> > How long do I have to repeat myself: They're gonna do it some day.
>
>   Can you give me a reference to, for example, an online linux community
> where they are discussing this?
>
>   Or are you, too, making a claim with absolutely no proof?

The proof is in my argument: The x87 will not live eternally, one way or the
other.

>   (In fact, with linux it even *might* be plausible because 99.9% of the
> software for it is open source and it's more or less trivial for every
> distro to just recompile *everything* for the new system. With Windows,
> which is plagued with old, closed source software, I don't think so.)

Even Windows software occasionally sees new versions of itself - or at least so
I heard tell.

> > - There *may* be reasons for chip manufacturers to want to get rid of the x87
> > FPU in their CPU design.
>
>   Which has nothing to do with the OS dropping support even in CPUs with
> a FPU.

Warp, why don't you get this one of my points, now once and for all: The desire
of chip manufacturers *may* be the reason for OS manufacturers to go into that
direction.

May, can be, possibly. I'm saying nothing more. But that *IS*, for heaven's
sake, a possible reason, and it *HAS*, for heaven's sake, something to do with
it.

If you don't get this, sorry, your problem.

> > - You can't strip the x87 FPU off the CPU unless the OS are ready for it, for
> > about the same reason that you (to some degree undoubtly righteously) argue
> > that you can't just strip FPU support off the OS.
>
>   And the OS cannot drop support because 99% of software uses it. So they
> are rather locked.

That statement of yours is BS for reasons I keep trying to explain to you, but
it seems you don't listen - you just dismiss my points with some circular kind
of argument.

> > - The OS *may* not be ready for it unless it itself has totally dropped the x87
> > FPU support (e.g. due to FPU commands that it may have to issue during task
> > switching, which may cause a mess on a CPU that doesn't support the x87 FPU)
>
>   I'm pretty sure it's very easy for them to compile a special version of
> the OS for a platform with no FPU. I would be surprised if you couldn't do
> that eg. with the Linux kernel.

With the Linux kernel - pretty well sure. But with a closed-source OS like
Windows? You just mentioned above that users can't just re-compile
closed-source software.

So the mainstream software would have to do the right thing off-the-shelf.

>   It's not a question of difficulty. It's a question of allowing software
> to run.

Yah yah yah... heard that long enough from you.


> > So we *may* be talking about a way to achieve some significant additional
> > speedup for 99% of the software that will be out there in, say, 5 years.
>
>   Software speeding up by using SSE has nothing to do with whether the OS
> supports the FPU or not.

But speedup *OF SSE ITSELF* may have...

.... (geez, you're having me close to shouting out loud "dummo!" right here...)


> > BTW, your claim that you can get every old stuff to run on Vista is BS. Think
> > for example about the numerous DOS games, which are being "actively boycotted"
> > and denied direct access to hardware when run under modern OS.
>
>   Vista doesn't boycott old DOS software any more than eg. Linux does.
> They are basically completely different operating systems.

There's a difference here: Many DOS console software *DOES* run on Vista (at
least I guess so - it does on XP), because Windows has always been *designed*
to still be able to run DOS software. If it doesn't make use of direct hardware
access or 32-bit mode, that is.

Linux has never run DOS executables "natively". There may be add-ons to do so,
which may even be included in typical distributions, but they're not part of
the OS as such.


> (Well, DOS is *not* an operating system at all.)

Then what do you think it's named for? "Disk Ohjesushelpme System"?

Your definition of an operating system may be somewhat biased by the times of
scheduled multitasking and multicore systems.


Now, 'nuff said. If you are not willing to get my points, then forget about it.

Post a reply to this message