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

Dropping/splitting (proper) i386 support

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 

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.).
Not sure if there's anyone programming to the data bus. :-)
* 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.
* i486 has the BSWAP, XADD, and CMPXCHG instructions (and possibly 
others -- I haven't found a complete list).
* OpenSSL is *much* faster on i486+ than on i386.  The improvements for 
going to i586, i686, etc. are not that great.
* The kernel is markedly faster compiled for i486+ than on i386.  
Again, the improvements for subsequent chips are not as impressive.
This is at least partly *not* a tuning issue; for 386, the kernel needs 
extra code whenever it writes to user pages
has to clear the whole page table rather than using INVLPG,
and uses less efficient options rather than CMPXCHG,XADD, and 
BSWAP in heavily-used code paths (including read-write semaphores).

Other instances I've seen show a really sharp performance improvement 
with i486-specific code rather than i386-specific code, and declining 
benefits for each subsequent model.  I'm not sure how much is tuning and
how much is architecture-specific, of course.  Oddly, it looks like 
GCC doesn't currently ever generate 486-specific instructions; they are
only (currently) of benefit to assembly programmers.  (Hmm... maybe I 
should see if there's an enhancement opportunity to GCC there.)

3. How much impact will this have on users?

* Two people have reported live 386 systems (not clear if they're using 
Being used for ISDN logger and for DNS server:
Being used for ADSL firewall:

* Lots of people have reported live 486 systems using Debian.  

* 486s are still being sold.

* Supposedly, i386 was never as popular as i486.
This matches my recollection that until the 486 came out, software was
generally targeted at the 286 (IBM AT).

4. Conclusion.
The i386 support is marginal, there are very few users of it, and it's 
significantly impeding the rest of the distribution.

There are several ways to deal with this.

* Split into a full 'i386' architecture and a full 'i486' 
architecture.  Causes massive wasteful archive bloat... unless
someone enhances the architecture system, so that binary packages can
identify themselves as being the same for 386 and 486 (or different 
and incompatible with ABI breakage...), and so that source packages can
identify themselves as building in the appropriate manner, and so that 
dependencies are handled correctly,...  This is quite difficult and 
seems unlikely to happen in the near future, if ever.

* Drop i386 support entirely; 'i386' architecture becomes 'i486'.
The most dramatic option. 

* Drop i386 support mostly.  'i386' architecture becomes 'i486'.
Start a 'Debian-real-i386' subproject, with a 'real-i386' architecture,
but don't require that any packages build on it in order to go into 
testing or to release Debian; it would be a bonus architecture, with
a limited number of packages avaiable.

This seems to be the most immediately feasible option.  Several people 
have already indicated their approval of this idea.  I wouldn't wait for 
sarge to release, but do it ASAP. (Since C++ is already semi-broken on 
386s, this would likely make things better for i386 in fact; at least 
it would have a specific functioning project.)

This is assuming someone with a real i386 is willing to lead a
'Debian-real-i386' project (which wouldn't be a huge amount of work, 
really; upstream support is usually pretty good, you don't have to 
actually compile packages on your slow 386, just test them there, and 
you don't have to worry about ABI compatibility with anyone much).  If nobody 
is willing then I'd say there just isn't enough support and 386 should be 
dropped outright.


Reply to: