Slashdot Mirror
Hindsight: Reversible Computing
One of the more interesting tech pieces that came out this week has been Hindsight [PDF]. Hindsight is made by Virtutech and is billed as the "the first complete, general-purpose tool for reverse execution and debugging of arbitrary electronic systems." The demos were received extremely well and it just looks cool.
Therefore, I can't see their approach being foolproof, and the over-obvious advertisement (this is what normal debugging toolbars look like, but they don't have a nifty step-one-back feature) seems too bright to be withot caveat. At $5,000 a seat I'd say buyer beware.
Hindsight is a service within their platform emulator. While it sounds nifty, and I'm all for it... emulators never behaive the same as the real platform... especially in embedded environments. The timing of peripherals is never the same on the emulator as the platform. The result is that lots of time is spent debugging the emulator environment that bares little fruit for the platform environment.
What would be far more useful, would be to write tools that took advantage of many of the onboard hardware debugging capabilities of some of the common embedded chip architectures.
Someone you trust is one of us.
The only way to "back up" execution is to save your state as you go. In Computational Theory, this amounts to the fact that, given a particular UTM in a particular state (state, position on the tape, values on the tape) an infinite number of UTMs exist which, at some point in their execution, arrive at a state equal to that particular state. (we leave the proof to the reader)
Thus the only way to "back up" computation is to know the past of that machine, i.e. a state log of the execution of the program.
BTW, I wrote a Rules Engine for the State of Texas and the Texas TIERS project. I logged each state change as the decision tables are executed, and then wrote a tool that uses this log to wind forward and backward the state of the rules engine. This does exactly for policy what these guys are claiming for program development.
I provided a tree view of the execution through the decision tables, and a state view that allows you to "jump" to the the place in execution where a particular variable was last set (from the perspective of where you happen to be in the execution of your program). I'd expect they also provide such features.
Execution logs (especially very complete logs) are make the implementation of very wonderful and magical debugging tools possible.
BTW, I don't know if they have attempted to patent the use of execution logs in the implemenation of such tools, but if so my TIERS work is quite clearly documented in a Federal/state project, and clearly uses these techniques and dates back to 2002 or so. I've used the technique to do this far before that, but I'm not sure if it is publicly documented.
Paul
the state of a computer is not the state of the memory. it includes the hard disk as well. to give one tiny example: the vvirtual memory. to give a better example, if a program overwrites a file you have to check point back over that too. to give an even better example, if you were debuggin a disk defragmenting program every bit on the disk could move.
Some drink at the fountain of knowledge. Others just gargle.
Not only that, just try to undo a "i += rand()" type of statement... or user input... or a network call. Most network protocols do not support "forget the last three statements and roll back in state". :)
Wrong.
Basically any code that moves any data is crunching some other data. Given that RISC and CISC processors are Load/Store based architectures, that makes for pretty much a majority of cases.