From owner-svn-src-head@freebsd.org Sat Mar 4 22:58:29 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8D678CF82EE; Sat, 4 Mar 2017 22:58:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 62D181CF0; Sat, 4 Mar 2017 22:58:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id 1B66010A791; Sat, 4 Mar 2017 17:58:22 -0500 (EST) From: John Baldwin To: Bruce Evans Cc: Pedro Giffuni , Slawa Olhovchenkov , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r314669 - head/sys/i386/conf Date: Sat, 04 Mar 2017 14:57:47 -0800 Message-ID: <8173144.jrBJ3AIVVW@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-STABLE; KDE/4.14.10; amd64; ; ) In-Reply-To: <20170305075947.K914@besplex.bde.org> References: <201703041504.v24F4HMh023937@repo.freebsd.org> <2368011.hGEX4V32U5@ralph.baldwin.cx> <20170305075947.K914@besplex.bde.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Sat, 04 Mar 2017 17:58:22 -0500 (EST) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2017 22:58:29 -0000 On Sunday, March 05, 2017 09:13:05 AM Bruce Evans wrote: > On Sat, 4 Mar 2017, John Baldwin wrote: > I think all the removal does on a plain 486 is move a runtime test so that > 486 CPUs no longer pass it, causing a panic for an "unsupported" CPU that > would work except the panic, and prevent reaching a single 486 optimization. > in bocpy(). The special support in initcpu() seems to be only to work > around bugs in incompatible 486 variants. The last time I looked at initcpu.c it wasn't clear how much of those old workarounds were for CPUs we don't support that could just be axed. > Fixes in this area should go the other way and remove the panics and the > cpu class stuff to implement them. The cpu class stuff used to mainly > give panics for newer CPUs that are backwards compatible but unknown. > Feature tests prevent that happening. All new x86 are 686s with optional > features. Plain 486 should work if it were classified as a 686 without > any features. I recently removed cpu_class from amd64 entirely. Removing it from i386 and just replying on cpu_feature* the way amd64 does would be fine with me. I'd probably remove all the I?86_CPU options in that case and just compile them all in. In regards to the TSC, that is one thing I've wondered if we should require for i386 to avoid some runtime checks and simplify the i386 code. There were 486's with a TSC even. -- John Baldwin