[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Dropping/splitting (proper) i386 support



On Sun, Apr 27, 2003 at 04:32:37PM -0400, Nathanael Nerode wrote:
> This is an attempt to summarize some points.
>
> 1. Why do we have a problem, other than performance issues?
>
> * To maintain binary compatibility with other distributions for C++
> packages, Debian needs to use the i486+ version of atomicity.h supplied
> by GCC.
> * This version is significantly faster than the i386 version.
> * GCC 3.2 doesn't even supply a working i386 version (GCC 3.3 does).
> * This is exposed ABI (currently) and therefore cannot be solved by
> multilibbing.
 
I notice that we already have /usr/lib/i486/libstdc++.so.5 etc. Does this
mean we can have different versions of the library for i386, i486 etc?

Can we use the 486+ atomicity.h on everything other than i386, and use
the 386 version on i386? Then we'd have binary compatibility everywhere
except on i386, which would be better than dropping it completely.

> 2. What performance benefits do we get as side effects of dropping 386?
> 
> * i486 guarantees a 32-bit external data bus (386SX has a 16-bit bus.).
> http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg02043.html
> Not sure if there's anyone programming to the data bus. :-)

This is simply an advantage of the 386DX or 486+; it shouldn't affect
compiled code.

> * i486 has a cache, and accordingly an 'invalidate cache' instruction. 
> * i486 has an 'invalidate TLB entry' instruction (INVLPG).  386 requires
> the flushing of the entire page table.

Does this affect compiled user-space code? Or only the kernel? Or
neither?

> * i486 has the BSWAP, XADD, and CMPXCHG instructions (and possibly 
> others -- I haven't found a complete list).

OK.

> * OpenSSL is *much* faster on i486+ than on i386.  The improvements for 
> going to i586, i686, etc. are not that great.
>  http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg02031.html

OpenSSL already has 486, 586 and 686 versions; we don't need to
sacrifice i386 to get those benefits. (Is that correct?)

> * The kernel is markedly faster compiled for i486+ than on i386.  

But we already have seperate kernel packages for 386, 586tsc, 686, k6,
k7... We don't have to drop i386 support to improve performance on the
others.

Can you make a list of performance benefits that we only get by dropping
i386 support?



Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>



Reply to: