Date: Fri, 22 Oct 1999 13:16:55 -0700 From: Mike Smith <mike@smith.net.au> To: Stephen Roome <steveroo@mothra.bri.hp.com> Cc: Ville-Pertti Keinonen <will@iki.fi>, current@freebsd.org Subject: Re: Anyone adding "support" for Athlons. Message-ID: <199910222016.NAA00680@dingo.cdrom.com> In-Reply-To: Your message of "Fri, 22 Oct 1999 12:00:05 BST." <Pine.HPX.4.10.9910221153010.27283-100000@mothra.bri.hp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
*sigh* > > 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. You are, as always, welcome to contribute. > > > (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. CPU features are keyed off the CPUs feature codes, not surprisingly, not it's marketing name. > 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.) Page colouring has been shown to have little or no real effect; again, if you care, feel free to fix the code and submit same. > 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) Please read preceeding threads on this topic. > 3) Use of SIMD instructions, (MMX and 3DNow!). Are these used by anything ? Shouldn't you be answering this question yourself before demanding support? Do you even think that the kernel needs to be involved with "Multi Media eXtensions" or 3D graphics primitives? > 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 ?) Perhaps you should be talking to the egcs folks about this, since as you well know they're the ones responsible for this sort of work. > 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. Surprise, surprise. > But MMX and 3DNow! really could be used (better), It could? You could justify this claim better too. > 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. And you think that there's no reason at all for this? > If none of this is relevant, then I'd be interested to know why, but it seems > pretty relevant to me! You could try reading the many preceeding threads on this topic already. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com 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?199910222016.NAA00680>