On Mon, Oct 19, 2009 at 08:23:11AM +0200, juha.riihim...@nokia.com 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 > >> <juha.riihim...@nokia.com>. 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 <ya...@vm-kernel.org> 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 aurel...@aurel32.net http://www.aurel32.net
