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

Reply via email to