From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1Cflxo-0003hi-8F for qemu-devel@nongnu.org; Sat, 18 Dec 2004 16:18:08 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1Cflxn-0003hA-7A for qemu-devel@nongnu.org; Sat, 18 Dec 2004 16:18:07 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Cflxn-0003h5-27 for qemu-devel@nongnu.org; Sat, 18 Dec 2004 16:18:07 -0500 Received: from [216.254.0.206] (helo=mail6.speakeasy.net) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1Cflma-0005Qm-UN for qemu-devel@nongnu.org; Sat, 18 Dec 2004 16:06:33 -0500 Received: from dsl081-088-222.lax1.dsl.speakeasy.net (HELO [192.168.111.2]) ([64.81.88.222]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 18 Dec 2004 21:06:31 -0000 Subject: Re: [Qemu-devel] get_func() hangs with gcc 3.4.2 on MinGW and WinXP host From: "John R. Hogerhuis" In-Reply-To: References: <20041215134754.GA28410@100tka.net> <20041215145903.GA29957@100tka.net> <20041215234503.GA12778@jbrown.mylinuxbox.org> <20041217195627.A38776@saturn.kn-bremen.de> <20041218040428.GA31934@jbrown.mylinuxbox.org> Content-Type: text/plain Message-Id: <1103404056.21895.83.camel@aragorn> Mime-Version: 1.0 Date: Sat, 18 Dec 2004 13:07:36 -0800 Content-Transfer-Encoding: 7bit Reply-To: jhoger@pobox.com, 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 Sat, 2004-12-18 at 06:59, Johannes Schindelin wrote: > What do new gcc's do? Why is it impossible to chain the code? Do you have > an example object file, or even better, an assembly snippet? The op.c primitives are, well, primitive... at some point consideration should be given to simply giving up. That is, code the primitives in native assembler for each target CPU. Certainly the C compiler is being well leveraged at present to do smart things like allocating registers, but a decent assembly programmer will make just as good or better decisions than gcc. The path of least resistance to get there would be to generate op.s files (using the necessary version of GCC) for all popular CPUs, and make them part of the build. Then those could be hand optimized over time as folks have the spare cycles to do it. This would remove specific gcc version dependencies from the build with little effort. Unless that's a GPL violation (distributing generated code under a non-GPL license)... don't know about that angle. If that were the case, the only option along this line would be coding from scratch unless GPL is acceptable for the core. [QEMU uses mixed licensing and I don't have it straight in my head, sorry.] -- John.