Re: Removing GCC dependency, was Re: [Qemu-devel] get_func() hangs with gcc 3.4.2 on MinGW and WinXP host

[Fabrice Bellard <fabrice@bellard.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.