From owner-freebsd-current Fri Oct 22 4: 2:10 1999 Delivered-To: freebsd-current@freebsd.org Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202]) by hub.freebsd.org (Postfix) with ESMTP id 57CF014D39 for ; Fri, 22 Oct 1999 04:01:34 -0700 (PDT) (envelope-from steveroo@mothra.bri.hp.com) Received: from mothra.bri.hp.com (steveroo@mothra.bri.hp.com [15.144.1.185]) by atlrel2.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id HAA27732 for ; Fri, 22 Oct 1999 07:00:32 -0400 (EDT) Received: from localhost (steveroo@localhost) by mothra.bri.hp.com with ESMTP (8.8.6 (PHNE_17135)/8.7.1) id MAA28060; Fri, 22 Oct 1999 12:00:06 +0100 (BST) Date: Fri, 22 Oct 1999 12:00:05 +0100 (BST) From: Stephen Roome To: Ville-Pertti Keinonen Cc: current@freebsd.org Subject: Re: Anyone adding "support" for Athlons. In-Reply-To: <86zoxd19yl.fsf@not.demophon.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 21 Oct 1999, Ville-Pertti Keinonen wrote: > Stephen Roome 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