From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HV5Tb-00048b-8J for qemu-devel@nongnu.org; Sat, 24 Mar 2007 08:36:07 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HV5Ta-00047f-LK for qemu-devel@nongnu.org; Sat, 24 Mar 2007 08:36:06 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HV5Ta-00047U-If for qemu-devel@nongnu.org; Sat, 24 Mar 2007 07:36:06 -0500 Received: from amsfep15-int.chello.nl ([62.179.120.10]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HV5RY-0008FH-SG for qemu-devel@nongnu.org; Sat, 24 Mar 2007 08:34:01 -0400 Received: from [192.168.1.120] (really [80.57.119.9]) by amsfep15-int.chello.nl (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20070324123357.QRWP7724.amsfep15-int.chello.nl@[192.168.1.120]> for ; Sat, 24 Mar 2007 13:33:57 +0100 Message-ID: <46051A67.6060300@gmail.com> Date: Sat, 24 Mar 2007 13:32:39 +0100 From: Sunil Amitkumar Janki MIME-Version: 1.0 Subject: Re: [Qemu-devel] 0.9.0 and svn don't build with -march=pentium2 etc.; was: Latest SVN fails to build on Fedora Core 6 (same with 0.9.0) References: <20070317143730.1befbf94@neuling> <20070323105825.0f2da762@neuling> <4603AA3A.7090101@gmail.com> <200703231545.49960.paul@codesourcery.com> <20070323211124.4d7d7b79@neuling> In-Reply-To: <20070323211124.4d7d7b79@neuling> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 Thomas Orgis wrote: > Am Fri, 23 Mar 2007 15:45:49 +0000 > schrieb Paul Brook : > > >>> I do not understand enough of QEMU yet, but I have checked out CVS and >>> am reading through its source. When I understand more I hope we can fix >>> this long-standing annoyance. >>> >> This is GCC PR16185 . >> > > Hm, I think I stumbled over this before... so it is still valid. > > >> There's no fundamental reason why some options trigger it, and others don't. >> It trigerrs fairly randomly depending on the code generation choices gcc >> happens to make. >> > > So it is indeed the case that nothing particular in qemu triggers it, > just the general grab on the registers. > And it is something that won't be fixed anytime soon (in gcc), apart > from ia32 going out of use... > Personally, I started using qemu with my Pentium-M 1.4GHz laptop... so > 32bit is the way there for a few years. > So I'll check for every new qemu release and gcc version if it perhaps > builds with normal optimization settings... or one identifies a spot to > release a register for x86 where it doesn't hurt qemu (since it's > always softmmu_template.h with helper.c). > > Anyway, this sounds more and more like a FAQ entry. > Perhaps it should be mentioned in qemu docs. > > >> The problem is that x86 is chronically short of registers. qemu makes this >> significantly worse by telling gcc it can't use most of them. gcc simply >> isn't designed to work in these extreme situations. >> > > Yep, x86 is chronically short of many things and loaded with others. > At work I secured two good old XP1000 alphas for myself... > they're not really as fast as my laptop, but register starvation is nothing > I expect to happen there. They got .. hm, what's the correct term... > a shitload of registers! ;-) > x86 really was the worst arch to become market leader for home computing. > On the other hand that leadership was what made the arch mutate in the > ways it did. > > > Thomas. > > > _______________________________________________ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel > > 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. In a certain sense i486 compatibility holds back the options you have for optimisation. 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. Anyhow, I expect 32-bit hardware to gradually die because of wear and tear in the next few years and the replacement will be 64-bit hardware so the problem will solve itself that way. Sunil.