On 18 June 2015 at 08:12, Pavel Dovgaluk <pavel.dovga...@ispras.ru> wrote: >> From: Aurelien Jarno [mailto:aurel...@aurel32.net] >> Looking at how icount work, I see it's basically a variable in the CPU >> state (icount_decr.u16.low), which is already accessed from the TB. >> Couldn't we adjust it using additional code before generating an >> exception, when in icount mode. >> >> For example for MIPS, we can add some code before generate_exception >> which use the value from s->gen_opc_icount[j] to adjust >> the variable icount_decr.u16.low. > > It is possible, but it will incur additional overhead, because we will > have to update icount every time the exception might be generated. > We'll have to update icount value before and after every helper call, > that can cause an exception: > > icount -= n > ... > instr_k > icount += n - k > helper > icount -= n - k > ... > > And this overhead will slowdown the code even if no exception occur.
Right, this is a tradeoff: in some cases it's faster to assume no exception and handle state resync by doing a retranslate. In some cases it's faster to assume there will be an exception and do a manual sync. Guest load/store is obviously in the first category. Guest doing an instruction which always takes an exception (like syscall insns) is in the second category. For other cases there's a choice. We need to support both approaches; obviously you can argue for any particular case whether it should be approach 1 or approach 2. thanks -- PMM