Re: [Fwd: Re: [Qemu-devel] RFC: Code fetch optimisation]

[J. Mayer]

On Sat, 2007-10-13 at 20:07 +0100, Thiemo Seufer wrote:
> J. Mayer wrote:
> [snip]
> > > My idea of always using the ldx_code_p function is that we may have the
> > > occasion to make it more cleaver and make the slow case handle code
> > > execution in mmio areas, when it will be possible.
> > 
> > Here's an updated patch. I added a definition TARGET_HAS_VLE_INSNS which
> > is defined is the cris, i386, m68k and ppcemb cases. Arm already has an
> > explicit support for 32 bits thumb instructions spanning 2 pages, so it
> > should not need this define. When this define is not set, the
> > ldxxx_code_p function just does ldxxx_raw(phys_pc) in the softmmu case
> > and ldxxx_raw(pc) in the user-mode only case. This is optimal for pure
> > RISC architectures and does not need the #ifdef CONFIG_USER_ONLY you
> > added for Sparc in your patch version. I also added a provision for a
> > TARGET_MMIO_CODE define which may be used later when this will really be
> > supported by Qemu.
> > I also took your fixes for Sparc phys_pc computation, but reversed your
> > patch to use ldl_raw as it should not be needed anymore.
> > I did test PowerPC in user-mode only and softmmu mode and i386 in
> > softmmu successfully using this new version of the patch.
> 
> Works ok for MIPS. There's no obvious change in performance, I guess
> the slow TLB emulation drowns out any possible improvement.

Great !
Yes, the optimisation we got here is more a 'don't waste our time doing
unneeded things' than a great performance boost. Running a long test
program in linux user mode seems to indicate it spend a little less time
in user-mode when the patch is applied, but this is not very significant
compared to the total time spent in execution. Maybe gprof would show us
if we really spend less time in the translation process...

-- 
J. Mayer <address@hidden>
Never organized