Max Bell writes:
> 
> >From: "Alex R.N. Wetmore" <alexw+@andrew.cmu.edu>
> >Excerpts from internet.computing.netbsd.port-i386: 13-Dec-95 Re: should
> >we be using -m486?  by M. HeadCandy.com@HeadCan

This is getting rather silly.

Doesn't anybody bother to read the man pages?

chase@orac> man gcc
...
       -m486

       -mno-486
              Control whether or not code is optimized for a  486
              instead  of  an 386.  Code generated for a 486 will
              run on a 386 and vice versa.

That from gcc-2.7.2

Personally I would tend to believe the FSF over what appears to be
idle random speculation about who did what with a precompiled AFS
binary run on a friend's machine by so-and-so.

I even looked (very briefly) at the code.  It appears that the
differences are:
1: different alignment (to allow for burst mode memory systems
   and faster cache fills after a miss?)
2: slightly different choice of instuctions based on relative
   expectations of execution time e.g.:


chase@orac>fgrep 486 i386.md
;; "movl MEM,REG / testl REG,REG" is faster on a 486 than "cmpl $0,MEM".
;; On a 486, it is faster to move MEM to a REG and then push, rather than
;; On i486, incl reg is faster than movl $1,reg.
;; On i486, an incl and movl are both faster than incw and movw.
;; On i486, incb reg is faster than movb $1,reg.
;; On a 486, it is faster to do movl/addl than to do a single leal if
;; On i486, the "andl" is always faster than the "movzbl".
;; On both i386 and i486, a three operand AND is as fast with movzbl or
;; On i386 and i486, "addl reg,reg" is faster than "sall $1,reg"
;; On i486, movl/sall appears slightly faster than leal, but the leal
;; On i486, the shift & or/and code is faster than bts or btr.  If
;; i486, it is faster to copy a MEM to REG and then use bt, than to use

-- 
Craig Chase --- Assistant Professor
Electrical and Computer Engineering
The University of Texas at Austin
Austin, TX 78721   --- (512) 471-7457


-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2

mQCNAzCNf0YAAAEEANXpNKQilG9pAMd1OqXNteVYNaKoI7cXvBpl2nYpGNe/CZrS
U/Vebi1PfKy6eWqbgsUOo1yPzfBmh5GGA0TUcyalIN8Aur4w0LdWAFP5ihMQEQYh
g33Nfjq0xBFyxHDP76X+pq5idGYj9ZZKGDTeFwzKIAmKPvggohGN4hjScfM9AAUR
tCVDcmFpZyBNLiBDaGFzZSA8Y2hhc2VAZWNlLnV0ZXhhcy5lZHU+
=rjIy
-----END PGP PUBLIC KEY BLOCK-----