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