> On 27 June 2014 11:35, Pavel Dovgaluk <pavel.dovga...@ispras.ru> wrote: > > The major disadvantage of icount is that it's updated only on TB boundaries. > > When one instruction in the middle of the block uses virtual clock, it could > > have different values for different divisions of the code to TB. > > This is only true if the instruction is incorrectly not > marked as being "I/O". The idea behind icount is that in > general we update it on TB boundaries (it's much faster > than doing it once per insn) but for those places which > do turn out to need an exact icount we then retranslate > the block to get the instruction-to-icount-adjustment > mapping.
I see. But if we want virtual clock in "real" mode then we still should create new timer (based on icount code). > It wouldn't surprise me if this turned out to have some > bugs in corner cases, but fixing these issues seems to > me like a much better design than ignoring icount completely > and reimplementing a second instruction counter. When we started an implementation, we didn't have enough resources to fix all such bugs. That is why we selected such conservative approach. But I believe that in future we will adopt the icount for replay purposes. Pavel Dovgaluk
