From owner-freebsd-questions Sun Nov 1 12:13:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA28885 for freebsd-questions-outgoing; Sun, 1 Nov 1998 12:13:14 -0800 (PST) (envelope-from owner-freebsd-questions@FreeBSD.ORG) Received: from dt053n18.san.rr.com (dt053n18.san.rr.com [204.210.34.24]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA28871 for ; Sun, 1 Nov 1998 12:13:12 -0800 (PST) (envelope-from Studded@gorean.org) Received: from gorean.org (Studded@localhost [127.0.0.1]) by dt053n18.san.rr.com (8.8.8/8.8.8) with ESMTP id MAA02097; Sun, 1 Nov 1998 12:13:03 -0800 (PST) (envelope-from Studded@gorean.org) Message-ID: <363CC0CF.D820FC6C@gorean.org> Date: Sun, 01 Nov 1998 12:13:03 -0800 From: Studded Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 2.2.7-STABLE-1101 i386) X-Accept-Language: en MIME-Version: 1.0 To: Dan Nelson CC: "questions@FreeBSD.ORG" Subject: Re: Cyrix 6x86 CPU References: <199810311552.KAA14228@laker.net> <19981031141836.B2302@emsphone.com> <363BA458.604FFB30@gorean.org> <19981031201855.A5808@emsphone.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dan Nelson wrote: > > In the last episode (Oct 31), Studded said: > > Dan Nelson wrote: > > > > > So for all but the most rabid performace freaks that can sense when > > > a branch is predicted wrong or when a pipeline stalls, including > > > all possible CPU types will make absolutely no difference. > > > > So if we know how to conditionalize this code, why is it still > > necessary to specify the cpu type? Why not have /usr/sbin/config detect > > the cpu type and DTRT? (Or whatever convenient/efficient mechanism is > > appropriate.) > > The machine I run /usr/sbin/config on may not be the machine I'm > compiling for. That's why it's desirable to have the *option* to specify cpu type. Right now it's not an option, and based on what you're saying I can't see any reason why it should be required in the case of someone building the kernel on the machine it will be used on. > What I was trying to say was that maybe the options should be removed, > or changed to NO_I386_SUPPORT, so that joe user wouldn't see the option > in GENERIC and wonder if he can remove it. There is a comment that SMP > users will need to remove 386 and 486 support, so the options will have > to exist in some form (or maybe options SMP should disable support > automatically) I agree that there will be special cases when the option is valuable. But at WORST in the case of something like the GENERIC kernel all of the code should be there but properly conditionalized so that it isn't a performance penalty (sounds like it's there/close to there already) and at best when compiling a new kernel with a config file that has no cpu options /usr/sbin/config should determine the cpu type and optimize appropriately. As you said, if the user doesn't see the option in the GENERIC kernel, they will be less likely to use it, therefore less likely to get it wrong. Obviously, the appropriate options should be in LINT for the special cases. Doug -- *** Chief Operations Officer, DALnet IRC network *** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message