RE: Simics & reverse execution

["Jakob Engblom" <jakob at virtutech dot com>]

> currently are (to allow e.g. a graphical frontend to implement a
> slide-bar to show where in the record log we are).  The former is
> precise to instruction count (and signals, etc); the latter may not be
> depending on the details of the target.  Actually, percentage is the
> wrong term -- better would be what fraction of the way are we through
> history, e.g. in 1/(2^64) increments, such that half way through
> recorded history would be represented as 2^63.

I can see one big problem with this: you are assuming a bounded recording. 

In our case, it is unbounded (except for the current 64 bit counter of
picoseconds used to coordinate all processors and other time-dependent parts in
a simulation system, which bounds execution at an annoying 280 days of time).
In Simics, you can always just continue past the end of the previously seen
execution, and you extend the size of the reversible window.  I believe VMWare
does the same from my experiemtns with Workstation 6.5. 

I honestly think binary chop is best put into the backend for this reason... the
times I have seen it applied it relied on large state-checking scripts running
that had far better insight into the target system than you get with gdb (such
as doing global consistency checks on the state of file systems on various
boards in a fault-tolerant redundant cluster). 

/jakob