Re: Dropping/splitting (proper) i386 support

[Jakob Bohm]

On Tue, May 06, 2003 at 03:05:21PM +0200, Guillem Jover wrote:
> Hi,
> 
> On Mon, May 05, 2003 at 06:27:05PM -0400, Nathanael Nerode wrote:
> > After the 486, Intel always provided a method to determine the CPU type and 
> > features available.  As far as I can tell, there's no easy programmatic way 
> > to tell the difference between a (old, no CPUID) 486 and an (old, no CPUID) 
> > 386 without risking an illegal instruction, which bites. :-(  (I could be 
> > wrong.)
> 
> They exist and are not so difficult. One is by issuing illegal
> instructions like you have commented, the only thing to do is to trap
> INT 6 (Invalid Opcode). The only problem you may find is that really old
> cpus don't support this INT (only 80186+).
> 
> The other is a little bit more fun, you have to test for cpu specific
> non-documented behaviour, like how many bits shift a shl in a 8088 or
> 80186+, when does the cpu increment the sp (stack pointer) when doing
> a push/pop, which flags can or cannot be set, etc. I did some years ago
> asm code that distinguished from 8088 to the new CPUID aware cpus,
> including the distinction from 8086 and 8088, or from NEC V20 among
> others. =P
> 
> And I've seen code that did more insight testing. (I can give
> code / pointers to anyone interested).
> 

Note: the CPU manuals from Intel include an official assembler
sequence which does not generate exceptions or anything.  The
16 bit version requires ring 0 privileges, the 32 bit version
does not.  Distinguishing amongst pre-CPUID submodels (like
386DX versus 386SX or Intel 386 versus AMD 386 takes more
tricks), but the code cleanly distinguishes 086 from 186 from
286 from 386 from 486-noCPUID from CPU-with-CPUID.

> regards,
> guillem
> 

-- 
This message is hastily written, please ignore any unpleasant wordings,
do not consider it a binding commitment, even if its phrasing may
indicate so. Its contents may be deliberately or accidentally untrue.
Trademarks and other things belong to their owners, if any.


pgpEav57ffy3R.pgp
Description: PGP signature

Re: Dropping/splitting (proper) i386 support

[Matthias Klose]

Neil Roeth writes:
> Nice summary.

> > * 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.
> 
> I am in favor of dropping the 386 altogether, but this is acceptable as an
> alternative.  If people would rather work on keeping 386 software up to date
> than just run woody forever, more power to them.  It doesn't seem like it
> would cost much on anyone else's part to enable this.

What are the steps to be taken to move to i486-linux? Has this to be
decided on debian-policy?

Would it be ok to drop i386-linux until somebody starts it again?


Matthias

Re: Dropping/splitting (proper) i386 support

[Matthias Klose]

Hamish Moffatt writes:
> 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?

No. I had to learn this as well. The new packages only have the
libstdc++ with the i486 atomicity implementation as gcc-3.2's
libstdc++ had it. The two implementations must not be mixed.

Re: Dropping/splitting (proper) i386 support

[Adrian 'Dagurashibanipal' von Bidder]

On Tuesday 29 April 2003 16:40, Hamish Moffatt wrote:
> On Sun, Apr 27, 2003 at 04:32:37PM -0400, Nathanael Nerode wrote:

> > * 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.ht
> >ml 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.

Just a guess: some error could occur between the first and second halfword on 
386SX, where a 32 bit access on all other machines is atomic - this might 
matter for some operations

-- vbi

-- 
OpenPGP encrypted mail welcome - my key: http://fortytwo.ch/gpg/92082481


pgpU8egeLppPV.pgp
Description: signature

Re: Dropping/splitting (proper) i386 support

[Hamish Moffatt]

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 <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Re: Dropping/splitting (proper) i386 support

[Richard Braakman]

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.
> 
> 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. :-)
> * 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.
>  http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg02031.html
> * 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
> (http://www.cs.helsinki.fi/linux/linux-kernel/2002-13/0445.html),
> 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.

Note that  uses asm statements to do byte swapping,
and it has separate cases for i386 and i486.  This file is used
by  which defines htonl() and friends, and by 
which defines bswap_32() and friends.  Compiling for the i486 will
make a difference here even if GCC doesn't care itself.

Richard Braakman

Re: Dropping/splitting (proper) i386 support

[Dagfinn Ilmari Mannsåker]

Bas Zoetekouw <[EMAIL PROTECTED]> writes:

> BTW: do you have any quantative numbers on the i386/i486 performance
> issues (e.g. for openssl)?

I hacked up a quick script () that compares
two 'openssl speed' outputs and gives you the ratio, here's the output
for i386 vs i486 on a P-III Mobile:

type 16 bytes 64 bytes256 bytes   1024 bytes   8192 bytes
md2 1.0091.0220.9920.9941.000
md4 1.1821.0741.1521.0701.018
md5 1.3511.5962.0792.9023.443
hmac(md5)   1.3851.4991.8342.5323.318
sha11.1571.5201.5531.6071.608
rmd160  1.1721.2761.3981.4951.552
rc4 1.3871.3661.3781.3621.352
des cbc 1.9801.9611.9581.9571.991
des ede32.0572.0632.0962.0832.089
rc2 cbc 0.9960.9890.9980.9980.991
blowfish cbc1.2461.2361.2441.2481.246
cast cbc0.9810.9931.0081.0120.995
aes-128 cbc 0.9971.0151.0151.0060.999
aes-192 cbc 1.0281.0091.0101.0211.010
aes-256 cbc 1.0211.0171.0231.0161.015
  signverifysign/s verify/s
rsa  512 bits0.5590.6671.7721.759
rsa 1024 bits0.4950.5562.0131.900
rsa 2048 bits0.4890.5162.0561.950
rsa 4096 bits0.4960.5142.0001.944
  signverifysign/s verify/s
dsa  512 bits0.5330.5141.9181.991
dsa 1024 bits0.4890.4952.0262.031
dsa 2048 bits0.4950.4832.0152.071

For i486 vs i686/cmov the results are less impressive:

type 16 bytes 64 bytes256 bytes   1024 bytes   8192 bytes
md2 1.0421.0171.0501.0451.047
md4 1.0421.0350.9420.9720.997
md5 1.1551.1411.1001.0230.989
hmac(md5)   1.2681.2431.2061.1101.030
sha11.0321.0401.0261.0061.006
rmd160  1.0321.0141.0111.0141.011
rc4 1.0021.0010.9900.9881.003
des cbc 1.0001.0030.9951.0000.987
des ede30.9911.0060.9921.0021.001
rc2 cbc 1.0041.0081.0111.0081.011
blowfish cbc1.0010.9941.0051.0011.010
cast cbc0.9830.9910.9790.9850.995
aes-128 cbc 1.0061.0071.0131.0181.021
aes-192 cbc 1.0101.0081.0141.0001.012
aes-256 cbc 1.0061.0100.9961.0031.007
  signverifysign/s verify/s
rsa  512 bits1.0001.0000.9901.002
rsa 1024 bits1.0001.0000.9991.004
rsa 2048 bits0.9961.0001.0050.998
rsa 4096 bits1.0021.0000.9641.000
  signverifysign/s verify/s
dsa  512 bits1.0001.0001.0031.008
dsa 1024 bits1.0001.0001.0021.002
dsa 2048 bits1.0001.0280.9980.977

-- 
ilmari

Re: Dropping/splitting (proper) i386 support

[Bas Zoetekouw]

Hi Nathanael!

You wrote:

> * 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.

Sounds reasonable.  I'd rather not drop i386 at all, but I guess
something needs to be done.

BTW: do you have any quantative numbers on the i386/i486 performance
issues (e.g. for openssl)?

-- 
Kind regards,
++
| Bas Zoetekouw  | GPG key: 0644fab7 |
|| Fingerprint: c1f5 f24c d514 3fec 8bf6 |
| [EMAIL PROTECTED], [EMAIL PROTECTED] |  a2b1 2bae e41f 0644 fab7 |
++ 

Re: Dropping/splitting (proper) i386 support

[Falk Hueffner]

Nathanael Nerode <[EMAIL PROTECTED]> writes:

> 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.)

I have a patch floating around here that adds a __builtin_bswap32/64,
which could generate bswap on i486, if anybody is interested. I was
planning to recognize bswaps from C Code too, but I'm not sure that
will work out... I think it would be quite useful, though, since byte
swapping often occurs in performance-critical code like emulators.

-- 
Falk