Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 22 Oct 1999 12:00:05 +0100 (BST)
From:      Stephen Roome <steveroo@mothra.bri.hp.com>
To:        Ville-Pertti Keinonen <will@iki.fi>
Cc:        current@freebsd.org
Subject:   Re: Anyone adding "support" for Athlons.
Message-ID:  <Pine.HPX.4.10.9910221153010.27283-100000@mothra.bri.hp.com>
In-Reply-To: <86zoxd19yl.fsf@not.demophon.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 21 Oct 1999, Ville-Pertti Keinonen wrote:
> Stephen Roome <steveroo@mothra.bri.hp.com> writes:
> 
> > As the title says, is anyone working on support for Athlons, and when can we
> > expect it to arrive back in -stable ?
> 
> Athlons don't need any special support, they are fully compatible with
> Intel's latest processors.

I realise that special support is not required, but better optimised support
would be nice.

> > (I can't find anything in the latest versions of sys/i386/i386/identcpu.c)
> 
> The identification for AMD processors models that can report their
> name using cpuid is redundant, even for cpus that are currently listed
> there.

Yup, I noticed this, I was concerned not just that the name came up properly,
but that the identification would then cause the chip to be utilised
differently.

Anyway...

To this, and all those that have responded to me with regards to specific
Athlon support, I should probably rephrase my question:

The issues I was trying to raise were really about better optimization for
Athlons, and later generations of CPU's, as follows :

1) Cache size changes are already accounted for in the case of 1Mb or 512k L2
cache, however the Athlon can have up to 8M cache.

Although there's no Athlons shipping at the moment with more than 512k cache
this will apparently change, and the vm system ought to know about this,
perhaps instead of using the PQ_****CACHE definitions we ought to consider
having PQ_L1CACHESIZE and PQ_L2CACHESIZE definitions instead. (The currently
Athlons have L1/L2 of 128k/512K, also, depending on the bios the clock speeds
and ratios for these are different to what can be assumed from a 486 or 386 or
even a PIII.)

2) Alignment. By default if code is compiled without -m486 we end up with
different alignment strategies taken by gcc. Should the 386 strategy still be
the default ? (i.e. Should 386 still be considered the expected hardware for
FreeBSD)

3) Use of SIMD instructions, (MMX and 3DNow!). Are these used by anything ?


4) Treating different CPU's differently by the compiler : Addition of
scheduling parameters for Pentium and Pentium Pro wasn't added to gcc until
2.8. 3.2-RELEASE is 2.7.2.1 (what's the version in other releases ?)

Overall, it looks very much to me like a PII, PIII or Athlon is generally
treated as quicker 486, and at worst as a quick 386. Although there's kernel
code to say do bzero/copy differently, the general case, it's a quick 386.

But MMX and 3DNow! really could be used (better), and CPU architecture has
changed a lot. There was a time when people were using pentium optimised gcc
for a while, but I still don't see a -mpentium or -mppro, or -arch= option to
our version of gcc.

If none of this is relevant, then I'd be interested to know why, but it seems
pretty relevant to me!

Thanks for all the feedback so far,

	Steve

The Athlon code optimization guide can be found here :
http://www.amd.com/products/cpg/athlon/techdocs/pdf/22007.pdf




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.HPX.4.10.9910221153010.27283-100000>