From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ipu55-00053R-Rg for qemu-devel@nongnu.org; Wed, 07 Nov 2007 18:13:08 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ipu54-00052Z-CH for qemu-devel@nongnu.org; Wed, 07 Nov 2007 18:13:07 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ipu54-00052W-42 for qemu-devel@nongnu.org; Wed, 07 Nov 2007 18:13:06 -0500 Received: from mx19.lb01.inode.at ([62.99.145.21] helo=mx.inode.at) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Ipu53-0006m7-Mo for qemu-devel@nongnu.org; Wed, 07 Nov 2007 18:13:05 -0500 Received: from [85.127.17.49] (port=12183 helo=s37.loc) by smartmx-19.inode.at with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1Ipu4v-0008TQ-7x for qemu-devel@nongnu.org; Thu, 08 Nov 2007 00:12:57 +0100 Received: from cow by s37.loc with local (Exim 4.67) (envelope-from ) id 1Ipu4u-0000VT-Qw for qemu-devel@nongnu.org; Thu, 08 Nov 2007 00:12:56 +0100 Date: Thu, 8 Nov 2007 00:12:56 +0100 From: Bernhard Fischer Subject: Re: [Qemu-devel] Removal of some target CPU macros Message-ID: <20071107231256.GG6510@aon.at> References: <473204A2.3030208@bellard.org> <1194463004.855.41.camel@jma4.dev.netgem.com> <4732346D.9060304@bellard.org> <1194474495.21588.9.camel@rapid> <4732425E.20601@bellard.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4732425E.20601@bellard.org> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Wed, Nov 07, 2007 at 11:55:26PM +0100, Fabrice Bellard wrote: >Why not adding a new CPU type such as "PPC970 with hypervisor" and keep >the current PPC970 implementation as it is without the hypervisor mode. >I don't see the problem in replacing the ifdefs with a new CPU model ! >You cannot reasonnably tell that it is uglier than the current code. IMHO same for i386sx. Without an FPU there is just no FPU. Without 486-specific instructions (or i586 etc. for that matter), the machine is just constrained to the one requested by the user. The fact that usually too many non ISA-imposed features are available without explicit user choice is very, very unfortunate, IMO. As always, features are or may be nice, iff and only if you are not forced to have or use them..