> -----Original Message-----
> From: Warp [mailto:war### [at] tagpovrayorg]
>   And as long as the OS is run on a system with FPU and with programs
> using
> the FPU, the OS cannot drop support. It's that simple.

Minor nitpick... it's not about dropping the FPU, because it's the same
FPU that runs x87 as well as SSE/2/3/4.  They're the same transistors.

What's being deprecated is the instruction set, not the component of the
CPU.

...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

> -----Original Message-----
> From: Warp [mailto:war### [at] tagpovrayorg]
>   So the hardware would be perfectly able to run the software, but the
> OS deliberately stops the software from being run if it uses the FPU.
> And this makes sense?

They don't deliberately stop it from working.  What's being considered
(although not implemented yet) is simply not doing the work to make it
keep working.

...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

> -----Original Message-----
> From: Warp [mailto:war### [at] tagpovrayorg]
>   At least in the past Intel processors had the strange rule that you
> cannot
> use the FPU and the SSE unit at the same time. I don't know if they
> have
> fixed that limitation later.

No, you had to switch modes (and deal with saving state et al).  Mainly
because... wait for it...  it's the same unit!

X87 and SSE both use the same units on the processor.  Even MMX shared
the same units (to some extremely limited extent).  You can't use them
both at the same time, because of the operating mode (like 16bit and
32bit code, you can't run them both at the same time, though you *could*
switch between them).

...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

> -----Original Message-----
> From: Warp [mailto:war### [at] tagpovrayorg]
>   Maybe it's different in a x86-64 architecture, but at least in my
P4,

Please use a modern processor when discussing future plans for
processors.

That's like basing your claims for Windows 7 on what Windows 2000 looked
like.

...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

Chambers <ben### [at] pacificwebguycom> wrote:
> > -----Original Message-----
> > From: Warp [mailto:war### [at] tagpovrayorg]
> >   Maybe it's different in a x86-64 architecture, but at least in my
> P4,

> Please use a modern processor when discussing future plans for
> processors.

  I was not talking about plans for processors. I was talking about the
claim that *operating systems* (including linux) are going to drop support
for the FPU even on architectures which do have a perfectly good FPU (ie.
every single current Intel and AMD processor). I find this claim ludicrous,
especially for linux (which aims for maximal portability).

-- 
                                                          - Warp

Post a reply to this message

> -----Original Message-----
> From: Warp [mailto:war### [at] tagpovrayorg]
>   I was not talking about plans for processors. I was talking about
the
> claim that *operating systems* (including linux) are going to drop
> support
> for the FPU even on architectures which do have a perfectly good FPU
> (ie.
> every single current Intel and AMD processor). I find this claim
> ludicrous,
> especially for linux (which aims for maximal portability).

Oh, it definitely is ludicrous.

The Wikipedia article on x87 clearly states that "The x87 unit is
largely deprecated on the 64-bit x86-64 architecture and associated
64-bit implementations of operating systems such as Microsoft Windows,
Mac OS X, Solaris, and Linux though it is still well supported for full
compatibility with older applications."

...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   I was not talking about plans for processors. I was talking about the
> claim that *operating systems* (including linux) are going to drop support
> for the FPU even on architectures which do have a perfectly good FPU (ie.
> every single current Intel and AMD processor). I find this claim ludicrous,
> especially for linux (which aims for maximal portability).

Actually, I found this claim on the German Wikipedia article on






darauf in der Version 3.1 zu einer weiteren Umstellung, die wiederum bald



letzte ABI Wechsel erfolgte mit Version 3.4, welche auch in der aktuellen 4.x
Reihe des GCC Verwendung findet. Da die eingesetzte GCC Version von


entweder im Quelltext oder in mehreren ABI-Versionen ausgeliefert werden."

which roughly tranlsates to:


therefore it happens rather seldom. A more recent opposite example however is
the C++ ABI for the GNU C++ compiler, that first changed from version 2.95 to
version 3.0; due to errors in this new ABI it was soon followed up by another
change in version 3.1, which in turn was superseded soon after by the ABI of
version 3.2, to be compatible to other compilers like that from Intel. As it is
almost impossible to migrate the system smoothly to a new ABI, this rapid change
caused a lot of disgruntlement. The last ABI change occurred with version 3.4,
which is also used with the current 4.x versions of the GCC. As the version of
GCC employed can differ from Linux distribution to Linux distribution, C++
programs for Linux which mainly build on the GNU compiler must be distributed
either as source code or in multiple ABI versions."

So much for binary compatibility in the (x86) Linux world...


This makes sense insofar as *binary* compatibility has never been that much of
an issue in the Unix world anyway: Software has always been *expected* to need
recompiling on different machines anyway. It was only the success of "IBM
compatible (!) PCs" that started the whole binary compatibility thing anyway.

In fact, Linux runs on many, many more platforms than just x86 - maybe more than
Windows will ever dream of running on - and has been doing so almost ever since
it came to existence; so the portability in Linux always had to be achieved at
a non-binary level anyway. (And strictly speaking, portability actually only
begins where binary compatibility comes to an end.)

So all in all, thinking it over again, I don't find it too surprising to
actually see more emphasis on binary compatibility in Windows than in Linux.

Post a reply to this message

clipka wrote:
> So much for binary compatibility in the (x86) Linux world...

Isn't that more a C++ thing than a x86 ABI thing? Is it the calling 
conventions to the OS, the stack frame format, or the C++ name mangling and 
structure layout that changed?

> It was only the success of "IBM
> compatible (!) PCs" that started the whole binary compatibility thing anyway.

Nah. CP/M before that, and lots of mainframe stuff before that, SPARC 
stations too, etc.  People have wanted binary compatibility since core 
memory days.

-- 
   Darren New, San Diego CA, USA (PST)
   Why is there a chainsaw in DOOM?
   There aren't any trees on Mars.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Isn't that more a C++ thing than a x86 ABI thing? Is it the calling
> conventions to the OS, the stack frame format, or the C++ name mangling and
> structure layout that changed?

Don't know details - I'm just quoting. But it's a GNU thing in any case, and
although "GNU's Not Unix", GNU's Linux. (Well, that's not perfectly true, but
anyway...)

> > It was only the success of "IBM
> > compatible (!) PCs" that started the whole binary compatibility thing anyway.
>
> Nah. CP/M before that, and lots of mainframe stuff before that, SPARC
> stations too, etc.  People have wanted binary compatibility since core
> memory days.

I don't know about SPARC, but successors of CP/M threw binary compatibility
overboard (had to, because they switched from 8080 to something else). MS-DOS
for instance, which in its very core was "heavily inspired" by CP/M, and
included some data structures just for the sake of compatibility with it.

And if I remember correctly, there were even things like CP/M for 68k systems,
which is definitely bye-bye to binary compatibility.


Sure, people have *wanted* binary compatibility since core memory days, but
since when did people get *used* to it?

Post a reply to this message

clipka wrote:
> MS-DOS for instance, which in its very core was "heavily inspired" by CP/M, and
> included some data structures just for the sake of compatibility with it.

You are correct - in fact, it was designed to allow machine-translated 8080
CP/M programs to run directly. That is, basically, all that needed to be
done was translate the instructions - the translator did not need to worry
about trying to understand what the instructions where *doing*, and hence
did not need to fix up operating system calls etc. They just worked. Even
the MS-DOS '.com' file format was dictated by the way CP/M worked (the
first 256 bytes of a com file replicate the first 256 bytes of memory in a
CP/M system).

-- Chris

Post a reply to this message