qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 00/18] target-arm cleanup


From: Aurelien Jarno
Subject: Re: [Qemu-devel] [PATCH 00/18] target-arm cleanup
Date: Mon, 19 Oct 2009 15:23:33 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

On Mon, Oct 19, 2009 at 08:23:11AM +0200, address@hidden wrote:
> >> Apart from the points you have raised about specific patches there
> >> were few more minor bugs in the series spotted by Juha Riihimäki
> >> <address@hidden>. A fix is available at
> >> http://repo.or.cz/w/qemu/navara.git?a=commit;h=2ce696baa6fc5d99522cf387b6a4913807fd43ed
> >
> > One of the fix was already in my branch (catched by Laurent  
> > Desnogues).
> > I have added the other fixes in my branch. The last to hunks are good
> > example why temp new/free should be done explicitly ;)
> 
> I think I have a couple of other fixes and patches on top of that as  
> well, but I'd rather wait until you get this bunch committed and then  
> format the patches against the new mainline so that they apply.

Thanks I have seen your patch, I'll have a closer look later today.

> On the subject of the new_tmp/dead_tmp, can you elaborate how critical  
> it is if there are resource leaks in the translator code, i.e. if some  
> of the temporary variables don't get marked dead? I suppose the  
> leakage would only affect the translation of the code block where it  
> appears? I found more leaks by introducing a new_tmp64/dead_tmp64 and  
> some other checkups to catch programming errors.

As long as they are not to many leaks by TB, it should not be a problem.
If there is a leak on a single instruction, and this instruction is used
a lot of times, the maximum number of temps (512) can be reached, which
causes qemu to stop.

> Some of the generated tcg code is not very optimal, for example a  
> single vld4.8 instruction can generate over 250 tcg ops. I did some  
> optimizations and got it under 200 but do you think it could be an  
> issue that a single instruction can expand to so many tcg ops? I mean  
> besides the fact that it causes TBs for only one or two guest  
> instructions to be generated.

According to Fabrice, an helper starts to be faster starting to 20 ops.
I think however it depends a lot on the host architecture, and therefore
it's difficult to give a limit. 200 looks high though.

> Perhaps this would also be a good place and time to also ask whether  
> you would be interested in integrating support for OMAP3 in the QEMU  
> mainline? We have been developing and using it for several months now,  
> it's based on the work done by Yajin <address@hidden> to support  
> the OMAP3 BeagleBoard hardware. We have added support for the Nokia  
> N900 system emulation as well. In my personal opinion the OMAP3  
> emulation is in functionality on par with the existing OMAP2  
> emulation, if not even more complete.

That would be very nice to have such an emulated board in mainstream
QEMU. I would be happy to review your patches.

Cheers,
Aurelien

-- 
Aurelien Jarno                          GPG: 1024D/F1BCDB73
address@hidden                 http://www.aurel32.net




reply via email to

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