From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HV5qx-000644-Hg for qemu-devel@nongnu.org; Sat, 24 Mar 2007 09:00:15 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HV5qu-00063F-Se for qemu-devel@nongnu.org; Sat, 24 Mar 2007 09:00:13 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HV5qu-000632-AJ for qemu-devel@nongnu.org; Sat, 24 Mar 2007 08:00:12 -0500 Received: from mtaout02-winn.ispmail.ntl.com ([81.103.221.48]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HV5os-0003II-Gm for qemu-devel@nongnu.org; Sat, 24 Mar 2007 08:58:06 -0400 From: Julian Seward Subject: Re: [Qemu-devel] 0.9.0 and svn don't build with =?iso-8859-1?q?-march=3Dpentium2=09etc=2E=3B__was=3A_Latest_SVN_fails_to?= =?iso-8859-1?q?_build_on_Fedora_Core_6?= (same with 0.9.0) Date: Sat, 24 Mar 2007 12:55:16 +0000 References: <20070317143730.1befbf94@neuling> <20070323211124.4d7d7b79@neuling> <46051A67.6060300@gmail.com> In-Reply-To: <46051A67.6060300@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703241255.16524.jseward@acm.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 Cc: Sunil Amitkumar Janki > As far as X86 is concerned i386/i486/i586 are very different from later > generation > processors. I am wondering whether another host and target architecture > could be > created called i686 that makes use of something like MMX or other > registers in Intel > Pentium II/III/4 and AMD Athlon to negate the lack of general purpose > registers. I don't see how. MMX/SSE is suitable for SIMD processing of media data and to some extent for floating point, but is largely unusable for ad-hoc integer computation, especially anything that involves address calculations. > The fact that QEMU works and can be optimised on x86_64 is the only > saving grace > for the architecture, that is still suffering from a lack of registers > compared to any > other architecture. The lack of registers isn't ideal, but it's not a big deal, and in the grand scheme of things x86_64 has a lot going for it. The most important of which are that (from the software side) all the hard-won knowledge of how to compile good code for x86 carries across more or less directly to x86_64, and (from the hardware side) hardware people already know how to make fast, cheap x86s, so it's easy to move to making fast, cheap x86_64s. The problems of the gcc backend to qemu have already been discussed extensively on this list. Stealing 3+ registers from gcc on x86 really is asking for trouble, and I believe it is generally understood that the best long term solution is to move to a self-contained back end that does not use gcc for dynamic code generation. J