Re: [Qemu-devel] [RFC] reverse execution.

[Mark Burton]

On 19 May 2013, at 23:20, Peter Maydell <address@hidden> wrote:

> On 19 May 2013 21:09, Mark Burton <address@hidden> wrote:
>>        Note - what I understand by a basic block is something that ends in a
>> jump/branch of some description. Hence, one thing I think you can say about a
>> basic block is that each PC value within it is unique. Hence, if I know the
>> number of basic blocks executed, and the current PC, then I should be able to
>> re-run to there (assuming a deterministic system of course).
> 
> Assuming your rerun is strictly deterministic so you always exit
> the basic block the same way each time, then yes, this amounts
> to optimising the "instruction count" by doing it as "X basic
> blocks then Y instructions".

Yes that's exactly what I'm saying 
But....
I guess it's not quite so simple...

> You could actually have this
> really do the instruction count for you, if you track insns
> per block at translation time. (There is some fiddling necessary
> when we take an unexpected exception in the middle of a block
> due to a load/store fault.)


To be clear, we're talking about eg a memory exception that effectively causes 
an unexpected branch in the middle of a basic block.

The basic blocks used to execute the exception will be counted of course.

The issue is the instruction count of executed instructions as you enter the 
exception will be wrong.

However it will be consistent and deterministic, so long as the exception 
itself is deterministic... Which it should be.

The rule that the pc will be unique will be maintained.
Hence if we choose the 'count blocks' and then find the pc I believe we might 
'get away' with this case?
If we count the instructions themselves then we have some fixing to do, as you 
say.

> 
>> I'd be interested to know (a) if there is a sensible place for
>> adding a basic block counter, and (b) if people like this route
>> better or worse than an instruction counter?
> 
> I think you're probably best off getting the instruction counter
> working properly before trying to optimise it...
> 

I agree, 

The advantage of your approach is that the instruction counter may have other 
uses, and it's robust.

We can start, as you say, simply, and then use a basic block approach to 
optimise it if need be...

Still, if people see no use in an instruction count, and if people can point at 
a decent place to annotate basic blocks, then we can do without it....

Cheers

Mark
> thanks
> -- PMM