From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CgXQ6-0006Vq-81 for qemu-devel@nongnu.org; Mon, 20 Dec 2004 18:58:30 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CgXQ5-0006Vd-Uh for qemu-devel@nongnu.org; Mon, 20 Dec 2004 18:58:29 -0500 Received: from [129.104.30.34] (helo=mx1.polytechnique.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CgWyF-0005Nz-6f for qemu-devel@nongnu.org; Mon, 20 Dec 2004 18:29:43 -0500 Message-ID: <41C76080.3000707@bellard.org> Date: Tue, 21 Dec 2004 00:30:08 +0100 From: Fabrice Bellard MIME-Version: 1.0 Subject: Re: Removing GCC dependency, was Re: [Qemu-devel] get_func() hangs with gcc 3.4.2 on MinGW and WinXP host 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> <1103404056.21895.83.camel@aragorn> <1103524011.18528.834.camel@aragorn> <1103565756.18531.838.camel@aragorn> In-Reply-To: <1103565756.18531.838.camel@aragorn> Content-Type: text/plain; charset=us-ascii; 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: jhoger@pobox.com, qemu-devel@nongnu.org John R. Hogerhuis wrote: > On Mon, 2004-12-20 at 07:16, Johannes Schindelin wrote: > >>Hi, >> >>Wow, that was a detailed explanation. I do understand your points now. I >>guess that the path QEmu takes will be the path that the first one writing >>a proof-of-concept takes... > > > Well I thought I'd put the idea out there for discussion. The path QEMU > takes will be whichever one Fabrice decides is best, of course. I made tests with QEMU and gcc 3.4.2 and I saw no problems (the macro FORCE_RET() in op.c is there to ensure that gcc does not generate ret inside a micro op. Moreover, -fno-reorder-blocks is used). Can someone give precise examples of bugs with gcc 3.4.2 ? If we really cannot find a way to trick the next gcc versions, then progressively switching to a hand coded code generator is the solution I suggest. Using '.s' sources will be more complicated. I always thought the current 'dyngen' solution as a temporary one because it enabled a fast developpement of QEMU as the expense of performance (this is relative of course, QEMU is already quite fast and usable). But if we want better performances and better... portability (in the sense that we are not tied to a specific GCC version), then a hand coded code generator is the only way to go. The priority for the hand coded code generation should be: 1) helper calls with constant parameters or temporary parameters. It is very important to get better performances because on some archs (e.g. ppc), the current scheme is not efficient at all. 2) conditionnal jumps. These are the points that newer gccs may not compile correctly. 3) constant loads. 4) simple operations (all arithmetic and logic between temporaries) 5) memory accesses. Those points are easy to implement and would give a good speed up. The important point is that such a transition can be made progressively by using specific micro operations indexes. Fabrice.