From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JErBh-0007fz-Rm for qemu-devel@nongnu.org; Tue, 15 Jan 2008 14:11:05 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JErBg-0007fc-9y for qemu-devel@nongnu.org; Tue, 15 Jan 2008 14:11:05 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JErBg-0007fZ-71 for qemu-devel@nongnu.org; Tue, 15 Jan 2008 14:11:04 -0500 Received: from fmmailgate01.web.de ([217.72.192.221]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JErBf-0006V8-Ni for qemu-devel@nongnu.org; Tue, 15 Jan 2008 14:11:04 -0500 Received: from smtp08.web.de (fmsmtp08.dlan.cinetic.de [172.20.5.216]) by fmmailgate01.web.de (Postfix) with ESMTP id 870F2CA3CE7F for ; Tue, 15 Jan 2008 20:11:02 +0100 (CET) Received: from [91.18.124.99] (helo=[10.0.1.1]) by smtp08.web.de with asmtp (TLSv1:AES128-SHA:128) (WEB.DE 4.109 #226) id 1JErBd-0004p1-00 for qemu-devel@nongnu.org; Tue, 15 Jan 2008 20:11:01 +0100 Message-Id: <8149F563-74D1-4BAF-B9BA-9AFDCF3324FE@web.de> From: =?ISO-8859-1?Q?Andreas_F=E4rber?= In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [Qemu-devel] [PATCH] OSX x86_32 host support Date: Tue, 15 Jan 2008 20:10:39 +0100 References: <7BE93927-F16C-4CA5-86DC-F17955A0A67C@kberg.ch> <20080115131359.GC11941@shareable.org> <478CE001.4000907@csgraf.de> Sender: andreas.faerber@web.de 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 Am 15.01.2008 um 18:50 schrieb Alexander Graf: > > On Jan 15, 2008, at 6:30 PM, Andreas F=E4rber wrote: > >> >> Am 15.01.2008 um 17:32 schrieb Alexander Graf: >> >>> Jamie Lokier wrote: >>>> Alexander Graf wrote: >>>> >>>>> I believe the 5% performance hit >>>>> that goes with them is no real problem, as most people should be =20= >>>>> using >>>>> x86_64 nowadays anyway. >>>>> >>>> >>>> *Boggle*! x86_64 is only a few years old, and cheap low-power =20 >>>> x86_64 >>>> laptops are relatively recent. >>>> >>>> -- Jamie >>>> >>>> >>> So you really want to do dynamic retranslation on ancient =20 >>> hardware? To >>> me emulated systems already feel slow on really recent machines, I >>> don't want to go back to something even slower. >>> If you use kqemu there even is near no performance hit at all, =20 >>> which I >>> believe is the main use of qemu on i386 anyway. Furthermore x86_64 =20= >>> is >>> _way_ faster, as it provides a lot more registers. >>> >>> I think the benefit you get from cutting the gcc3 dependency is =20 >>> way more >>> important than a major performance hit that people will usually =20 >>> only see >>> on the next release of qemu, by which time things have shifted =20 >>> towards >>> x86_64 even more. >> >> One thing you don't seem to understand is that QEMU releases don't =20= >> upgrade our hardware, especially not from Apple. An x86_64 Mac Pro =20= >> is more than double the price for my PowerMac G5 back then. Don't =20 >> think about what people "should" be using in your opinion, look at =20= >> what they are actually using. > > What I am actually talking about is that the only real gcc4 breakage =20= > I am aware of is on i386. I just built x86_64-softmmu on a POWER6 =20 > host with gcc4.1.2 and it "simply worked". Please tell me if there =20 > is anything broken for you on gcc4. I believe there isn't (please =20 > use gcc4.2+). > >> >> People want to run software, including Q or QEMU, on their hard- =20 >> and software, which may include ppc hardware as well as Panther/=20 >> Tiger operating systems ... both much more "ancient" than Intel =20 >> Core 2 Duo based Macs. And yes, it's "slow". Does that stop me? No. =20= >> And you likely don't have a kqemu on your Mac either. Occasionally =20= >> trying an image does not justify buying VMware Fusion, and such =20 >> commercial products only do virtualization anyway and are incapable =20= >> of emulating different hardware. Just in case you forgot, Open =20 >> Source software in general usually has the benefit of not being =20 >> tied to the support lifetimes of commercial vendors, forcing users =20= >> to upgrade their (e.g. Windows) OS - but pushing us to upgrade our =20= >> hardware as soon as something faster is out would be doing exactly =20= >> that hardware-wise, without substantial reason. > > I wasn't talking about PowerPC. I am really sorry if it looked that =20= > way, but it was neither my intention nor my belief to say anything =20 > against any platform but i386. I didn't get you wrong. You repeatedly said that virtually no-one were =20= using i386 Macs any longer and that they were ancient. This implies =20 that ppc Macs are pre-ancient by linearity of time. I am not feeling personally insulted as a ppc and i386 user. I am =20 simply trying to show that there are in fact even older things still =20 in quite common use than what you called "ancient". The important point to note here is that those i386 Macs need GCC4 =20 anyway, so there is no other option than some working GCC4 solution =20 for i386 and x86_64 on Intel Macs. This seems to go missing when =20 discussing availability of chips and PC laptops, where gcc3 is an =20 option. What we seem to agree on is that a performance hit on i386 Macs is =20 better than not being able to run on Intel Macs at all - which is the =20= current CVS situation. To me as a relative outsider it appears (maybe that's wrong) that the =20= core developers, who wrote the original code affected by GCC3/4 ABI =20 changes don't know how to or don't see a pressing need to do the =20 change. Then occasionally someone comes along presenting an all-new =20 GCC4 patch in a hit-and-run manner, not leading to their patches =20 applied or the problem solved... Andreas=