qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Removing GCC dependency, was Re: [Qemu-devel] get_func() hangs with


From: Fabrice Bellard
Subject: Re: Removing GCC dependency, was Re: [Qemu-devel] get_func() hangs with gcc 3.4.2 on MinGW and WinXP host
Date: Tue, 21 Dec 2004 00:30:08 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]