Slashdot Mirror

← Back to Stories (view on slashdot.org)

Hindsight: Reversible Computing

Posted by Hemos on from the step-back-into-the-past dept.

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.

178 comments

  1. Sounds good - but expensive. by bigtallmofo · · Score: 4, Informative

    From reading about this earlier, it is a very exciting technology for embedded systems. It does seem a bit expensive though:

    Hindsight will go into beta sites in May, with production slated for July. Incremental cost over Simics is around $5,000 per seat, but Hindsight won't target single seats. A typical engagement, including Simics, Hindsight and some initial model development, is estimated at $200,000 to $300,000 for a software development group with 10 to 20 seats.

    --
    I'm a big tall mofo.
    1. Re:Sounds good - but expensive. by blair1q · · Score: 1

      $5k per seat isn't expensive.

      Especially when it turns two $100k/year engineers into one $50k/year engineer.

    2. Re:Sounds good - but expensive. by sledd_1 · · Score: 1

      Err... don't you mean the opposite:
      "Especially when it turns one $50k/year engineer into two $100k/year engineers"
      ?

      --
      I know a little sig that's just ten words long
    3. Re:Sounds good - but expensive. by Anonymous Coward · · Score: 0

      No. You are replacing two highly payed engineers with one cheap one, because the software makes the skills for which the original two engineers were being payed for obsolete.

  2. That's just nutty... by The+Desert+Palooka · · Score: 3, Informative

    With Simics Hindsight it is now possible to step back just before the error and then run forward again, providing another opportunity to reproduce the error and look more closely at what occurs in detail, without having to re-launch the program. Simics Hindsight can even unboot an operating system, running the code backwards until it reaches the initial hardware launch instruction after a hardware reset.

    That would be quite nice... It almost seems like a shuttle head or what not for programmers... Rewind, play, slow motion and so on... I know they said it's the first complete one, but is there anything else out there like this?

    1. Re:That's just nutty... by frobnoid · · Score: 2, Interesting

      Take a look at
      http://www.lambdacs.com/debugger/debugger.html I'm sure a Hindsight sales person would (correctly) say this isn't a complete solution, but its the closest thing I've seen before this article.

    2. Re:That's just nutty... by tagish · · Score: 1

      It's just reminded me of a 6502 debugger I wrote over 20 years ago that could step back as well as forwards. It was a bit slow because it actually did store the state of anything that changed during the execution of any instruction. It also didn't handle changes to hardware state or calls to OS functions that had side effects. Oh, and it needed tons of memory :)

      In spite of all those things it was still extremely useful. As they say though, the devil's in the detail. Getting it to work in a general purpose way and reasonably quickly is a hell of an achievement.

      --
      Andy Armstrong
    3. Re:That's just nutty... by CortoMaltese · · Score: 1

      I had to code a visual debugger for a small embedded system some 5+ years back. The debugging data was fetched from the system via some I/O, so I did what seemed obvious to me: logged all the data (relatively small amounts of it anyway), and gave the debugger ability to go back in the log. Of course, when not at current PC, the information was view-only, but the feature was awesome. No more of those "oops, one step too many, start over, dang!" Although the debugger itself was quite low-end, I still miss that feature a lot in other debuggers.

    4. Re:That's just nutty... by paulsnx2 · · Score: 3, Insightful

      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

    5. Re:That's just nutty... by zootm · · Score: 2, Informative

      There's an academically interesting (I'm assured :)) Java system similar to this called Bdbj. I'm not sure if it's useful in a real context, but I assume it is to some degree.

    6. Re:That's just nutty... by VAXman · · Score: 3, Interesting

      The only way to "back up" execution is to save your state as you go.

      At first I wasn't sure that your statement was true, but after thinking about it for 30 seconds or so, I realized it definitely was. Every instruction produces a deterministic calculation and can be reversed, right? If we have "ADD EAX, EBX", and know the current values of EAX and EBX, going backwards is easy, right?

      Well, one really difficult case is jumps. How do you know what the previous instruction executed was? On X86 this would be pretty difficult since the encodings are non-regular, but even on an ISA with regular encodings it would be non-trivial because it would be difficult to figure whether you got to the instruction via a jump (which could be anywhere in memory), or from the previous instruction.

      Add things such as Self-Modifying Code, and you have a real headache. Yes, you definitely need to track state as you go, though I'm not sure you'd need to save anything more than just the Instruction Pointer (which X86 does have a mechanism for). If you know what instructions were executed, it should be pretty easy to backtrack in time. I think.

    7. Re:That's just nutty... by matman · · Score: 2, Insightful

      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". :)

    8. Re:That's just nutty... by froody · · Score: 1

      I'm aware of two products (there must be others):

      The ocaml debugger does exactly what Simics describes here.

      Green Hills Software has a tool called TimeMachine which will take trace data from a real running system (ie not simulated) and allow you run back and forth through the time frame for which trace data was collected. Going back through time and then forward again is all simulated.

      Tim

    9. Re:That's just nutty... by Hynee · · Score: 3, Interesting
      The only way to "back up" execution is to save your state as you go.
      At first I wasn't sure that your statement was true, but after thinking about it for 30 seconds or so, I realized it definitely was. Every instruction produces a deterministic calculation and can be reversed, right? If we have "ADD EAX, EBX", and know the current values of EAX and EBX, going backwards is easy, right?

      Try this UTM program:

      Set A and B to the values 1 and 2
      Add values of A and B and put them in C
      Put value x1 and y1 into A and B

      Now, what UTM's could leave a machine in this state? Remember the states of the Universal Turing Machine are A, B, C, not what's written on the tape, i.e., the instructions.

      The answer is, of course, a whole lot, but one simple subset of programs that can leave C in this state is any program like the above one, except the first instruction is Set A and B to values x0 and y0, where x0+y0=1+2=3, which is infinitely many, eg, 2+1=3,3+0=3,4+-1=3, etc. So that's infinitely many programs with the same form as the actual program, but with only a couple of constants changed.

      (Note: true Turing Machines states aren't limited to a fixed set, like 0-255 etc, they use an encoding like 0100,1100,110100,111100, which can accomodate any size of number.)

      That doesn't quite answer why it's generally complex to run a computer backwards, but you can put any number of instructions in between step 2 and 3, and as long as they don't touch A and B, once you've gone past that last instruction, you have no clue what states A and B were in until you go all the way back to the start of that program.

      I guess a good checkpointing algorithm would be to save the states of any registers that are overwritten.

      --
      Damn, I already moderated this topic. Now I'll have to log in with my sock puppet to comment.
    10. Re:That's just nutty... by weierstrass · · Score: 1

      The only way to "back up" execution is to save your state as you go.
      This is only true in as much as it is tautological: ie if your computing device is reversible then by definition you have an effective way of recovering all previous states, ie they are 'saved'.
      In fact, Richard P Feynman, in his Lectures on Computation, talks a lot about reversible computation. the way to do this is to use reversible logic gates: instead of AND and NOT, there are 3 gates, NOT, CONTROLLED NOT, and CONTROLLED CONTROLLED NOT. These 3 can perform any logic operation that can be done using AND and NOT. The difference is that they each have the same number of input and output lines; CONTROLLED NOT has two of each, CONTROLLED CONTROLLED NOT has 3 of each. Their effects are all reversible: if you know the 2 outputs of CONTROLLED NOT, you can recreate the unique possible inputs, in the same way that if the output from a NOT gate is 1, you know the input was 0.
      If you use these, rather than conventional logic gates to build a computer, then you automatically can recreate its past states. There's no need to have 'save' data about the current state of the machine to external output
      This is apparently being done (or at least researched) at the University of G(h)ent

      --
      my password really is 'stinkypants'
    11. Re:That's just nutty... by foobsr · · Score: 2, Informative

      but is there anything else out there like this?

      Yes, in the museum.

      The debugger that came with BS3 on the TR440 had an option that enabled you to step back a defined (small due to lack of space for saving) number of steps if you set the appropriate switch when compiling. Very cool feature - 30 years ago !

      CC.

      --
      TaijiQuan (Huang, 5 loosenings)
    12. Re:That's just nutty... by pVoid · · Score: 2, Insightful
      Every instruction produces a deterministic calculation and can be reversed, right?

      Wrong.

      mov eax, 0
      mov eax, [eax]
      xor eax, eax
      jmp eax
      imul eax , 0
      ...
      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.
    13. Re:That's just nutty... by PingPongBoy · · Score: 1

      It's implementable.

      As an analogy consider the P4's lookahead. If the execution will not enter the branch that does an i+=rand(), the value of i must still be unchanged.

      --
      Know your pads. One time pad: good for cryptography. Two timing pad: where to take your mistress.
    14. Re:That's just nutty... by richardpotsdam · · Score: 1

      Green Hills Time Machine works with a Green Hills board. It's trace probing limited by the hardware. It can only do as much as the board allows it to do. Virtutech's product is based on models so it can do anything you want it to do. Plus, Time Machine can only step back so far -at least in what I've seen- whereas this simics platform supposedely can reverse back as far as you want. I talked with the Virtutech engineers and they simulate models of multiple-processor systems (they say they can simulate any system)... even complete networks of multi-processor systems with simulated traffic.

    15. Re:That's just nutty... by froody · · Score: 1

      TimeMachine is not limited to Green Hills boards (GHS doesn't make boards), but it does require that trace is designed into the CPU and the board that it is on. Most cores that support trace will give TimeMachine enough data to fully reconstruct registers values at most points in time.

      Other than that, you've nailed the difference between the two. The main advantage of TimeMachine is that you run on real hardware, with all of its quirks (even if they're not known yet). The main advantage of simulating is that you don't need real hardware, and you get unlimited visibility into the system.

      Tim

    16. Re:That's just nutty... by Xyrus · · Score: 1

      There are instances where knowing the instructions will not help you back track, such as certain encryption algorithms.

      You're also not taking into acount all the data and sates a piece of software may have traveled through, which is not as simple as just back-traking through the execution.

      There are also other fun little things like interrupts, threads, processes, etc. It can get quite complicated very quickly.

      In some instances you'd be able to get away with an IP back-trace, but with the complexity of modern software you'd need a lot more than that to reverse execution.

      ~X~

      --
      ~X~
    17. Re:That's just nutty... by Corngood · · Score: 1

      Also, so many instructions are not deterministic because they throw away data. Shifts, divides, add/mult when overflow occurs, etc. There are really only a small set of cases which are deterministic.

    18. Re:That's just nutty... by DanShearer · · Score: 1

      You'll see in the whitepaper referred to in the original posting that the principle involves the entire machine state being preserved and replayed. So it doesn't matter what instructions are executed or in what order. Simics (and therefore Hindsight, a feature of Simics 3.0) is all about creating and controlling an entire universe of machines and networks. I'm part of the Hindsight product team and run backwards all day :-)

      --
      Dan Shearer
  3. hrmmm by Dimentox · · Score: 0

    Very nice for debugging but i am curious how it works in practicality

    --
    string sig = llGetSig("dimentox"); llSay(0,sig);
    1. Re:hrmmm by Anonymous Coward · · Score: 1, Interesting

      Uhh, ladebug on Tru64 has this `snapshot` and rewind feature..this isnt new. Congrats on getting an x86 version going, but lets not pretend you invented the concept.

    2. Re:hrmmm by Anonymous Coward · · Score: 0

      Debugging is "practicality," douchenuts.

  4. Demos? by mordors9 · · Score: 0

    At least they admit the Democrats are behind this obvious power grab.... what... oh demonstration.. never mind.

  5. Remember When by Anonymous Coward · · Score: 0

    ..you could get a freeware disassembler for the 8088 which put labels in for you to make it easier to work out what was going on?

    1. Re:Remember When by UESMark · · Score: 1

      No, I don't.

  6. UI by GigsVT · · Score: 5, Interesting

    They say the way they accomplish this is running the program in some sort of sandbox and taking checkpoints every so often and then when you step back, it actually runs forward from the closest checkpoint and stops one instruction short.

    My question is how UI interactions are handled. If the execution between the checkpoint and current-1 instruction includes a UI interaction, it might be very confusing to the programmer to know what or how many UI interactions need to be carried out to accomplish the backstep.

    --
    I've had enough abrasive sigs. Kittens are cute and fuzzy.
    1. Re:UI by lazer_nm · · Score: 1, Interesting

      well, i dont know, i am embedded programmer, and as the flyer says, finding what happened when is a crucial part of our life. I always use Lauterbach debugger with ETM (enhanced Trace Module) to do my set of debugging, and ofcourse, I can reset what ever I want and step as much back i need to, without the "reverse gear"

    2. Re:UI by hrieke · · Score: 1

      A big honking emulator with state saving in a memory buffer. I'm sure they've already accounted for recursive loops and interactions, just they've improved the ability to load / save states.

      Don't the video game emulators already do this?

      --
      III.IIVIVIXIIVIVIIIVVIIIIXVIIIXIIIIIIIIVIIIIVVIIIV IIVIIIIIIVIII...
    3. Re:UI by TuringTest · · Score: 2, Interesting

      Furthermore, this won't work for finding bugs on concurrent programs due to race conditions or parallel threads corrupting a shared resource.

      Those bugs might be catched if the environment would record instructions one-by-one, but as is you may find a bug in your execution, roll back to the checkpoint and find that the bug is gone in the replay. Hey, that would be funny if it happened on a TV football game...

      --
      Singularity: a belief in the "God" idea with the "demiurge" relation inverted.
    4. Re:UI by dtfinch · · Score: 1

      Don't the video game emulators already do this?

      Yeah. To create a movie they save the state and log the following input, so the game can be replayed exactly. ZSNES also has a rewind key, but I haven't messed with it.

    5. Re:UI by Anonymous Coward · · Score: 0

      Don't the video game emulators already do this?

      Sort've.. The only ones I have used allow you to pause execution, and save the current state data("Registers", "Cache", "Ram" etc..) to disk, and load that all up at a later point, and either quit the emulator, or continue execution. Nothing UI related in the save, I believe.

    6. Re:UI by philci52 · · Score: 1

      Why not? Did you read the article? This sounds like it emulates the entire x86 layer, not just one process. If that's true, then you could certainly find bugs in concurrent programs. In fact the article specifically mentions stuff like that. This also answers the granparent post about UI interaction.

      To make a fully practical solution, there supporting multiple processors, multiple clock domains, managing breakpoints and watchpoints, handling large I/O operations, and so on. Efficiently handling all these challenges is where various patented secret sauces come into play. As with many things, the idea seems simple but the devil is in the details.

      The idea is that it would look to the developer as if the program really is running backwards. Of course, I could be wrong... Is there anyone who's actually tried this thing?

    7. Re:UI by MurkyWater · · Score: 1

      It would not be hard. A very simple solution would be, in addition to taking checkpoints at regular intervals, take another checkpoint every time a UI interaction occurs. This would increase the amount of total checkpoints taken and therefore increase memory/disk usage, but that could be alleviated if you then remove any checkpoints within a certain amount of instructions. While probably not the most elegant, it is a solution to the problem you mentioned.

    8. Re:UI by Anonymous Coward · · Score: 0

      You dont to create checkpoint at each UI intreaction.
      You log it with time diffrentials between UI events, were the time from the last checkpoint to the first UI event since checkpoint is the first time diff.

      How hard can it be? Saw that in a diffrent post that SNES and other emulators do that if you are recording a movie.

    9. Re:UI by DanShearer · · Score: 2, Interesting

      The beauty of full systems simulation is that you are simulating the full system :-) So UI interactions also take place in the simulated world.

      The trick is to have a simulator fast enough so that you can do UI interactions, because the user isn't in the simulated world. As it happens Simics is fast enough and this is exactly how it works. I'm on the Simics product team, and one way we have of proving the point is to run operating systems and their applications backwards for which we cannot have the source code, eg Microsoft Windows. If someone still thinks we've inserted magic tricks after seeing CLOCK.EXE launched, run backwards and then unlaunch, well, there's not a lot more we can do. That also illustrates the point of the whole computer plus OS running backwards, not just a particular application.

      You can get humorously stuck actually with UI interactions... if you run forward to a certain point going point click etc, and then have an animated discussion with somebody for five minutes having forgotten to pause the simulation... unless you do something clever when you engage the reverse gear you have to sit and wait for nothing to un-happen for five minutes until you see the UI get reversed!

      --
      Dan Shearer
    10. Re:UI by GigsVT · · Score: 1

      I still don't understand, you say you checkpoint and run forward, what if a UI (or any external input) operation has happened after N but before N+1. In that case, running forward from N to the beginning of checkpoint N+1 would not show the UI interaction or external event happening until the beginning of N+1 checkpoint, when it really happened in the middle.

      Unless you also save state also whenever a UI interaction occurs, it's not clear how this would work.

      --
      I've had enough abrasive sigs. Kittens are cute and fuzzy.
  7. Not necessarily by spookymonster · · Score: 4, Informative

    From their website, you can get a free academic version of the software as well. At least, that's what the site says (I didn't register to download it, so I can't confirm).

    --
    - Despite popular opinion, I am not perfect.
    1. Re:Not necessarily by subrabbit · · Score: 1

      But note that this does not include Hindsight, since it hasn't been released yet.

  8. Mirror by tabkey12 · · Score: 4, Informative
    Mirror of the PDF

    Never underestimate the Slashdot Effect!

    --
    Get a free iPod Nano 4GB!
    1. Re:Mirror by yason · · Score: 1

      Yes, never underestimate the Slashdot Effect. Our chief weapon is a flock of nerds.. and globally distributed bandwidth. The best two of our weapons are a flock of nerds and distributed bandwidth ...and the element of dupes, they hit you twice! Our THREE main weapons are a flock of nerds, dupes, distributed bandwidth and ...dupes! The.. Among the four elements of dupes, we have a flock of nerds, distributed bandwidth, dupes and the Slashdot Effect, and our weapons of mass HTTP GETs...

  9. Virtualization layer for checkpointing and steppin by jaxdahl · · Score: 4, Informative

    This seems to create a virtualization layer where checkpoints are saved periodically, then instructions are single stepped through. So to step back, it goes to the first checkpoint before the instruction you want to step back to, then it single steps up to that point. This would aid in kernel-level debugging where data structures might be overwritten from almost anywhere in the computer that can access the kernel space -- no need to set a watchpoint then reboot and wait for the next error to occur.

  10. "Last Technical Hurdles"? by Catiline · · Score: 1, Interesting

    Yeah, I can see some technical hurdles here ... like storing all old variable/register contents, jump addresses, etc.

    How in the world did they pull this off?

    --
    Do you like Japanese imports?
    1. Re:"Last Technical Hurdles"? by Anonymous Coward · · Score: 0

      It wouldn't be entirely impossible to identify processes that aren't reversible (such as OR, or anything that overwrites another value) and save the affected values for those, while simply calculating the values for the rest of the operations (like most of the math).

    2. Re:"Last Technical Hurdles"? by shish · · Score: 1, Troll
      It's in the article, the section labelled "how it works".

      Assuming most slashdotters are lazy f*cks, a condensed explanation: it takes a snapshot every couple of seconds, then when you want to go backwards it moves all the way to the previous snapshot, then runs forwards ignoring sleep() to appear instant.

      --
      I mod down anyone who says "I will be modded down for this", regardless of the rest of their comment
  11. But what about external events by bangzilla · · Score: 4, Interesting

    It's all very well to be able to run code backwards/forwards/slo-mo/etc, but how to handle non deterministic external events coming in from the network? Does this tool presume that all applications to which it will be applied live in isolation?

    --
    Rich people are eccentric. Poor people are strange. Me, I'd be happy with odd.
    1. Re:But what about external events by tesmako · · Score: 5, Informative

      Since it is based on the whole-system simulator Simics -- Yes, it does assume that the app runs in isolation, since all external stuff is just simics simulations.

    2. Re:But what about external events by LiquidCoooled · · Score: 4, Funny

      No, you got it all wrong.

      This product is a cleverly disguised time machine.
      You can actually rollback and reverse to actually see the initial "First post!" remark, and undo the slashdot effect.

      If you look closely, you can also see the cognative response from Hemos as he clicked Accept on this submission.

      --
      liqbase :: faster than paper
    3. Re:But what about external events by Anonymous Coward · · Score: 0

      8-)

    4. Re:But what about external events by G.+W.+Bush+Junior · · Score: 2, Interesting

      Then the example in TFA is pretty bad.
      It's exactly an example of an external packet containing a wrong checksum.

      If the system is in isolation, you would have to come up with the idea of sending a malformed packet yourself instead of just letting it run until it crashed. that doesn't seem a very likely thing to try.

      --
      "I don't know that Atheists should be considered as citizens, nor should they be considered patriots." -George H.W. Bush
    5. Re:But what about external events by martyros · · Score: 1
      All it has to do is log all non-deterministic external input during the initial run, and re-play the results from the log during the replay run.

      So, if it does a virtual DMA to get the network packet the first time, copy the data from that DMA into a log. When you're re-executing, copy the DMA from the log instead of from the NIC.

      It's similar ReVirt (my project), which was slashdotted here.

      The downside, of course, is that you need to log *all* network data; so if you actually need that 1Gb ethernet, you're going to need some serious disk space to be able to used this feature.

      --

      TCP: Why the Internet is full of SYN.

    6. Re:But what about external events by c4miles · · Score: 1

      If you are working in embedded systems, and you have just spent ~$30,000 on a development suite, then you will be testing your code with every possible combination of inputs. This is exactly what a simulation suite such as this is for.

    7. Re:But what about external events by DanShearer · · Score: 1

      Good point. A Virtutechie here, I'm on the product team... if you are running Ethereal externally on the real host monitoring simulated ethernets inside Simics then it gets rather confused when the simulated ethernet starts running backwards (or rather, as per the white paper, running forwards in small reverse increments.)

      What I recommend is that if a monitoring tool does not have too much overhead and if there is no special reason for it to be running on the host then the tool itself can be run inside the simulated universe. Say you pick tcpdump... when the simulated universe goes backwards so does tcpdump. This approach has limitations of course, a more general solution involves communicating the stops and starts to the external monitor. If the monitor understands clock ticks (eg some profiling tool monitoring a simulated embedded board) then that's perfect, because Simics counts that way too. If the monitor is at another level such as ethereal then that's a more difficult discussion.

      You make a very good point. Simics can run an arbitary electronic device in reverse so there are a lot of applications yet to be explored.

      --
      Dan Shearer
  12. better be by promantek · · Score: 0, Funny

    20/20 ... *ducks a tomato* i'll be here all week

  13. Too good to be true... by Leadhyena · · Score: 5, Insightful
    I can see how this software can come in real handy, but it won't work in every situation. It states in TFA that Hindsight doesn't do the naive approach of recording every instrction, but rather takes snapshots and tries to fill in the gaps. There are many types of calculations out there (think The Game of Life or other CAs) that by their nature cannot be reversed, so all of those states would have to be stored or it would be mathematically impossible to calculate the reverse steps.

    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.

    1. Re:Too good to be true... by ysachlandil · · Score: 1

      Except that it forward-fills the gaps, and that is easy.

      It stores a snapshot every now and then, and when you want to go back it actually goes forward from the first snapshot before the time index you want.

      If you make snapshots 10 times a second and can forward-fill in a tenth of a second, the programmer will not notice this. (And if he does, make more snapshots)

      HTH
      --Blerik

    2. Re:Too good to be true... by Anonymous Coward · · Score: 1, Informative

      There are not doing "reverse steps". They go back to a previous checkpoint, and reexecute code (forward) until they reach the desired point.

      For example, if you're at point t=10, your previous checkpoint is at t=0, and you want to go back to t=9, their system first go back to t=0 and then reexecute the code until t=9.

      The thing is that you have to log everything non reversible (I/O, interrupts, syscalls, etc.) and use the logged value when reexecuting.

    3. Re:Too good to be true... by CausticPuppy · · Score: 3, Informative

      There are many types of calculations out there (think The Game of Life or other CAs) that by their nature cannot be reversed, so all of those states would have to be stored or it would be mathematically impossible to calculate the reverse steps.

      It also says in TFA that it doesn't actually calculate the reverse steps, so it doesn't matter if it's mathematically impossible.

      What it does do is take complete snapshots every (for example) 100 steps. In order to move "backwards" a step, it returns to the previous breakpoint (a known state) and goes forward 99 steps.
      Then it returns to the same breakpoint and goes forward 98 steps. And so on. So from your perspective, you see the 99th step, 98th, 97th, and on down. It only LOOKS like it's running backwards.

      This would even work for the game of life.

      So the performance tradeoff would be this:
      More frequent breakpoints causes forward execution to be slower because it's spending more time saving data at regular intervals for breakpoints, but "reverse" execution would be faster because it has to iterate fewer steps from the previous breakpoint.

      --
      -CausticPuppy "Of all the people I know, you're certainly one of them." -Somebody I don't know
    4. Re:Too good to be true... by reversible+physicist · · Score: 1

      Exactly the same technique (running backwards by restarting from a checkpoint and running forwards) was used in a reversible debugger about 30 years ago at MIT. I think that Ed Fredkin wrote it.

    5. Re:Too good to be true... by tricorn · · Score: 1

      Even more efficient, when "running backwards", go back to the checkpoint and re-execute everything while logging each instruction (log an instruction: record the previous value of anything this instruction overwrites, including the program counter if not the next instruction). Then you can do a direct "go backwards" mode. You still need to log each memory location that gets overwritten between snapshots (and use those values when re-executing).

      Instead of snapshots, you could record state at the beginning of each basic block (any location in the code that can be reached from a location not immediately preceding it, i.e. after any branch instruction or interrupt/exception).

      For dealing with devices, you could log all interactions with I/O ports (record both read and write values), and either log all DMA activity by the device or log all memory reads from memory used by the I/O device. For multi-processor, you have to emulate all the processors in a deterministic way (preferably as close to the original timing as possible, but since programs shouldn't be sensitive to timing that way, it would be helpful to be able to vary the timing as well - as long as it can be repeated during the re-execution).

      There still might be bugs that can't be found this way - things that are highly timing dependent, either with the exact timing between multiple CPUs or with I/O devices.

    6. Re:Too good to be true... by DanShearer · · Score: 1

      Just a correction... Simics doesn't fill in any gaps. Hindsight keeps a lot of snapshots, and then after the user picks a particular snapshot the simulated computer runs forward in time doing whatever the software tells the processor to do (eg, lock solid.) There is no guesswork here.

      Think of it like "if you had your life all over again". You probably wouldn't start with being born, you'd pick that point when you were fifteen and said the wrong thing at a critical time. So with Hindsight, you can back up to five minutes of time as experienced in the simulated world before an error occured (let's pick a trivial, very human-oriented case!) and very quickly you type the commands to grow your raid array. Now, when the database program gets to the critical point it won't run out of space . A more typical case is replacing a binary that is about to be run with one that doesn't have a critical bug -- or maybe just modifying a value in machine memory. Here on the Simics product team we find one of the greatest benefits is that Simics controls the machine from outside, so changing a memory value is hopefully not going to create a Heisenbug the way it can if you modify values through gdb running inside the machine.

      Does that help?

      --
      Dan Shearer
  14. Wow ! by Digital+Warfare · · Score: 2, Funny

    Now when I'm playing online, when I die I can rewind.

    I can hear it now, "Godlike!"

    --
    "Sweet llamas of the Bahamas !"
    1. Re:Wow ! by Anonymous Coward · · Score: 0

      But now you can dodge bullets like Neo. It takes a little practice, but after the first 10-15 bullet extractions and rewinding, you'll get the hang of it!

  15. The Omniscient Debugger? by Anonymous Coward · · Score: 3, Informative


    http://www.lambdacs.com/debugger/debugger.html/

    Seems like this has been done before, at least for java apps...

  16. BSOL? by bunyip · · Score: 3, Funny

    So, would reversible computing let me have a Blue Screen Of Life?

    That would be so cool...

    Alan.

    1. Re:BSOL? by Thuktun · · Score: 1

      So, would reversible computing let me have a Blue Screen Of Life?

      Since it would be occurring backwards, wouldn't it be red?

  17. Problems with platform emulalators by selectspec · · Score: 2, Insightful

    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.

    1. Re:Problems with platform emulalators by WolfWithoutAClause · · Score: 1
      That's true, but often the real equipment is the first few off the production line, and hence is quite expensive and in limited supply, and even buggy, whereas the emulators can be duplicated as many times as you want.

      Also, you have better control of what goes on in an emulation, and that can help you find mysterious bugs that are very opaque on the real hardware.

      Finally, there's certain situations where emulators are probably the only way to go- for example Space Shuttle software validation is done on the emulator, they *really* didn't want to use the real thing for that ;-)

      --

      -WolfWithoutAClause

      "Gravity is only a theory, not a fact!"
    2. Re:Problems with platform emulalators by selectspec · · Score: 1

      I agree that life would suck with emulators. However, despite my support for the Hindsight vendor, I don't believe they "will change debugging as we know it" which they claim on their website.

      But you are absolutely right. In my own experience with embedded developement, emulators were often all you hand until the eval boards showed up and those were usually hogged by the bootstrap teams who could careless about emulation and were only interested in real hardware. Same deal with the prototype boards.

      That said, I know of nobody who ever prefered to run anything on an emulator. Everyone was stoked to get access to the real deal.

      In the cases of the mysterious bugs, again I think the solution is to use the often overlooked and unused builtin debugging facilities on most embedded processors and chipsets today. Often these require some proprietary assembly programming and fun compilers (I wish the chip vendors would just do this). However, the results are clear debugging/tracing of activities in real hardware environments.

      In the case of the space shuttle and other similar systems like real flight simulators, I doubt software emulation is the solution for the code. Instead you would use the actual hardware, but emulate the I/O (the sensors, motors, etc). That way you are really testing the real platform, but you are generating a fake environment in order to limit risking life, limb, and expensive equipment.

      --

      Someone you trust is one of us.

    3. Re:Problems with platform emulalators by WolfWithoutAClause · · Score: 1

      I actually prefer to run about half my test cases on an emulator. Indeed I don't believe that good testing can be performed without isolating from the real hardware (but there are exceptions, clearly if the hardware is dirt cheap or something, and the debugging hooks are excellent...)

      --

      -WolfWithoutAClause

      "Gravity is only a theory, not a fact!"
  18. The trick... by Professor+S.+Brown · · Score: 2, Funny

    If you read the article carefully, it does actually say. Basically they've optimised the printf() and scanf() functions, from the standard C libraries, to a very high degree. Using these optimised functions allows them to literally run the processor backwards, with a little help from Euler Integration to approximate the execution path. Its very clever indeed.

    --
    Shitram Brown, PhD
    Professor of Mathematics
  19. Thats simple... by Anonymous Coward · · Score: 3, Funny

    just invert the micro clock signal so everything runs backwards :)

    1. Re:Thats simple... by Stevyn · · Score: 1

      Na, that won't do it. You'd have to decrement the program counter instead of incrementing it.

  20. Not by a decade. by Murmer · · Score: 5, Interesting
    This technology has existed, in GPL form, for ten years. It's just had exactly zero uptake.

    I read this usenet post every now and then when I'm trying to fix something, and it makes me want to cry every time I do.

    --
    Mike Hoye
    1. Re:Not by a decade. by zogger · · Score: 1

      Why is this not used? Seems valuable for all those beta releases out there that non devs run, to help in development. If it was easier to get back *useful* information to the devs side, fixes would be faster and just perhaps we could start to see true extremely stable and clean releases.

      And how does this compare to suns dtrace?

      forgive my ignorance if this is apples and oranges, I'm not a coder

    2. Re:Not by a decade. by Mitchell+Mebane · · Score: 1

      Just... wow. Ten years? It could've been the most awesome debugging tool ever, and nobody wanted it? Why?

      --

      The roots of education are bitter, but the fruit is sweet.
      --Aristotle
    3. Re:Not by a decade. by Auxon · · Score: 1

      You have to develop some marketing skills. I'd say at least now, after all this time you have to get this as a story followup on Slashdot (not just a comment) and get an interview on O'Reilly or something ... it's important. Push this stuff. Good work too!

    4. Re:Not by a decade. by skubeedooo · · Score: 1

      Never underestimate the power of good marketing. You can't just hope that if you make a good product everyone is going to find out about it. As much as OS people loathe it, it is a necessary thing. Marketing isn't just about making bad stuff look good, it's also about making good stuff get noticed.

    5. Re:Not by a decade. by Jeff+Mahoney · · Score: 1

      The links you posted aren't anywhere close to the level of sophistication that this software appears to be. While being able to use ptrace to intercept system calls in this manner is a cool hack, I don't think it's on the same level. The idea of reverse execution doesn't appear to be a new one, but the usability of this package appears to be far beyond that offered by mec.

      Maybe I'm misreading the information, but the impression I got is that it has the capability to setup a virtual machine so that you can do kernel-level debugging. It talks of being able to reverse step an OS-boot to the hardware initialization and handling SMP, device I/O, etc.

      Yes, the kernel has a kgdb patch available, but it requires a certain level of infrastructure to be available before you can use it. The kernel needs to be able to do serial I/O (potentially after it took a head shot) and errors may occur before then. Having something *completely outside* the machine is quite nice. UML isn't interesting in this aspect either because it's not a true hardware environment and trying to debug a UML instance can be.. interesting at times.

      That said, it may be possible to integrate existing open source technologies such as bochs and gdb (a separate child post indicated that gdb has had reverse stepping capability for some time) to create a similar package.

    6. Re:Not by a decade. by mec · · Score: 2, Informative

      Wow, what to say?!

      First, it was kind of silly to name the program the same as my user name, but I never found a better name for it than "my trace-and-replay debugger".

      My original plan was to write this for Solaris and sell it, hence the insistence on tracing and replaying without modifying the target program or the operating system, and that's why the replay controller messes with gdb's mind, so that it can work with a stock gdb rather than needing gdb extensions.

      I developed a Linux version first because it was so cheap and simple to throw Slackware on my computer. And, well, it turns out that I'll probably never need a Solaris version, because Linux sure has become big enough and rewarding enough for me.

      Versions 0.1, 0.2, and 0.3 took 15 months of full-time work, living on my savings and writing code on a little Linux box.

      After version 0.3, several bad things happened:

      Technical butterfly-chasing: the tracer needs to know about all possible ioctl calls that the target program makes, and Linux was adding and changing ioctls faster than I could check the patch diffs to update them. (That's how I came to write the kernel change summaries for a while). The obvious solution is to trace about 20 common ioctl's and throw all the rest in a big worst-case box that says "this ioctl might touch all of memory". One of the problems of working alone: nobody else around to notice the obvious solution.

      Moving up the management chain: anybody who runs a one-person operation knows about this. It's one thing to write a proof-of-concept program. It's another thing to push it out, start a community, market it, manage all the communication with users and co-developers. I failed at that.

      Fade-out: after the proof-of-concept worked, I noticed I'd spent 15 months full time, and I did make the milestone of seeing test programs run. I lost some interest and went and did something else.

      Version 0.3 still has one good use: to help defend against anybody else that files a patent for technology like this. I released in November 1995.

      Some responses:

      Zogger and Animats, that's exactly the use case, the user in the field runs the tracer, then mails a big log back to the developer. This gets very useful when the user has unique resources that the developer doesn't, for a program like a network server. I don't know much about dtrace, but I think dtrace is just more comprehensive kernel reporting information, not fundamentally "video-taping the user process".

      Mebane, I think the answer is: in 1995, I sucked at explaining things to people. Specifically, back then, I was into the "macho flash" school of communication: "this debugger is the best thing since breakpoint debugging, it will solve problems you didn't even think could be solved, etc". I should have just done a very simple demo walkthrough of printf("%d\n", gettimeofday()).

      Auxon and Skubeedooo, yeah, it was a lot about marketing.

      Jeff Mahoney: I agree, Hindsight looks much more powerful. But Hindsight is also more resource-intensive: they have to simulate a whole CPU.

      MenTaLguY: I would be happy to chat with anybody who wants to do a revival. The mec@shout.net contact address still works.

      And the whatever-happened-to-mec line: I worked for Cygnus/Red Hat for several years on gdb. My current job is with Google.

  21. Bash VB all you want.... by Anonymous Coward · · Score: 1, Informative
    Bash VB all you want, but it's had a (more limited) version of this feature for years. It's a gigantic help when debugging. In my experience the error occurs, or is detectable within a few lines of the crash/exception. So you don't necessarily need to back up the entire call stack, just enough to see what's broken immediately before the crash/exception occurs.

    Coupled with fix and continue, you have not only a more productive development environment, but an environment where you can press a prototype into limited production use long before it's ready. Everyone in their right mind thinks that's a retarded idea; even so, it becomes necessary once in awhile. Getting that prototype into production as soon as possible can be the difference between the company surviving or failing. I know because I've been there. These two features saved a company I used to work for. Thank you, Microsoft!

  22. Reverse Execution of Code? Haha! Oh wait... by AceJohnny · · Score: 2, Interesting
    We've seen a few april fools claiming to be able to run code backwards. This is impossible, at the lowest level. For example, take the logical OR: C = A + B (excuse the layout, the top line is the value of B, the first column the value of A)
    A\B | 0 | 1 |
    0 | 0 | 1 |
    1 | 1 | 1 |
    We know the result, C. How do we know if A, B, or both was 1? We lost information (2 bits of info became 1), and cannot get it back. So at first I dismissed any ridiculous claims of reverse execution. But we aren't the 1st of April...

    Hindsight seems to work based on a checkpoint mode when running backwards, it goes back to a checkpoint then runs forwards to the expected point. However how does it work with hardware?
    Anybody tried this out for real?
    --
    Misleading titles? Inflammatory blurbs? Keep in mind that Slashdot is a tabloid.
    1. Re:Reverse Execution of Code? Haha! Oh wait... by BradleyUffner · · Score: 1

      "However how does it work with hardware?"
      It doesn't. It works inside a virtual machine.
    2. Re:Reverse Execution of Code? Haha! Oh wait... by 0x461FAB0BD7D2 · · Score: 2, Interesting
      How do we know if A, B, or both was 1?

      There is a way to do this, although it is a bit ugly. The reverse-runner forks the program into 3, one for each of the possibilities. It then continues this until values have been solved.

      It would produce a decision tree, and the debugger could work backwards.

      Of course, this is purely theoretical. If A and B were strings, the number of processes would be infinite, in which case heuristics would be required, and it wouldn't be perfect.

    3. Re:Reverse Execution of Code? Haha! Oh wait... by HidingMyName · · Score: 2, Informative

      Reverse execution is possible at the source level, but it requires generation of extra data structures to handle operations that don't correspond to invertible functions. This approach has been applied with some success to high performance simulations to give a "lightweight rollback", by Peters and Carothers in An Algorithm for Fully Reversible Optimistic Parallel Simulation.

    4. Re:Reverse Execution of Code? Haha! Oh wait... by Anonymous Coward · · Score: 0

      NO!!! You come to the code through a certain path. At some point you mark the path, like breadcrumbs in a maze. Then when you "reverse step", you go back to the previous breadcrumb (where you stored all the state: registers, memory changed before previous delta position) etc. and walk towards the actual position.

      It's clever, but not rocket science. Start state, delta, delta, delta is more efficient than Start state, 2nd state, 3rd state, etc.

  23. Microsloth by TimeTraveler1884 · · Score: 0, Offtopic
    ...running the code [ass] backwards...
    Funny, the way Windows runs sometimes, I thought this was Microsoft's idea.

    1. Re:Microsloth by smittyoneeach · · Score: 0, Offtopic

      I think you can say their choice of path separator character was an
      a:\rguably
      b:\ad
      c:\all

      --
      Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
  24. Reversible Computing != Reversible Execution by Anonymous Coward · · Score: 5, Informative

    Reversible computing is a way of computing without (permenantly) consuming energy. Look it up if you're not familiar, because it's pretty interesting.

    Anyway, the headline is misleading.

    1. Re:Reversible Computing != Reversible Execution by dmanny · · Score: 1

      You mean that if all the gamers would simply unplay their games after they get fragged it would solve the energy crisis?

      --
      All my previous sigs now look like this one, I wish they were permanetly recorded when used. :-(
  25. OCaml anyone? by fab13n · · Score: 4, Interesting
    OCaml as been offering timestamps and backward debugging for years, in addition of a great programming language (backward debugger's implementation is based on Unix's forking and copy-on-write, so running it on windows requires cygwin). Simply compile your stuff to byte-code rather than with the native optimizing compiler, run the debugger and use backstep/backward just as you used to do with step/forward. Breakpoints block execution in both directions.

    And what about GUI and other side effects? Debugging a program in which such side-effects are deeply interleaved with algorithmics can be tricky indeed, although smart timestamping from the debugger will reduce glitches. But if you don't know better than randomly mixing algo and front-end in the first place, then you'd better fix the programmer than the program...

  26. Coding C in Eclipse? by Laz10 · · Score: 1

    I can see from the screenshots that they provide the debugger as an eclipse plugin.

    Does that include a C programming environment for eclipse or do they use the CPE project? I didn't know that was at a usable state yet.

    I use eclipse for java and it is excellent.

    1. Re:Coding C in Eclipse? by jbrocklin · · Score: 1

      I've been using the C++ eclipse plugin for a while now. Its useable, but I don't know how the build system works, because we wrote up our own makefiles (I'm sure there's some way of telling it to use those makefiles, but I just haven't taken the time to find it). Autocompletion works pretty well most of the time - I'm using it mostly for the cvs integration!

    2. Re:Coding C in Eclipse? by Anonymous Coward · · Score: 0

      That would be a sweet feature to have in Eclipse for Java... What a fantastic idea.

      In Eclipse for Java, you can make a change to code at a breakpoint and it restarts the program counter at the beginning of the modified routine.. Maybe reverse debugging will be in Eclipse's future... I sure hope so.

      One thing I don't get is how if it executes from a checkpoint each time a reverse step is issued, what happens if there is any physical I/O, like write to disk or add new record?

  27. Worth it if it works... by kclittle · · Score: 1
    This is *very* intaresting^g^n^i^t^s^e^r^aersting technology.

    Seriously, if this really works, the $5K/seat could well be worth it. Now, if they could convince Intel/AMD/IBM to somehow provide advanced support in the hardware...

    -k

    --
    Generally, bash is superior to python in those environments where python is not installed.
    1. Re:Worth it if it works... by badmammajamma · · Score: 1

      Nobody is gonna pay $5k a seat for this. Companies are too cheap to even consider it. The vast majority of bugs just don't require this level of debugging sophistication to solve in short order. The few that do are rare enough to cancel out the benefit of this software. However, some people truely suck at debugging, in which case they can probably justify the 5k.

      If this company was smart, they'd sell it for $500 and sell 100 times more copies.

      --
      Any man who afflicts the human race with ideas must be prepared to see them misunderstood. -- H. L. Mencken
    2. Re:Worth it if it works... by Anonymous Coward · · Score: 0

      "intersting"

      Doesn't look like it worked for you.

    3. Re:Worth it if it works... by kclittle · · Score: 1
      Would I buy a seat for everyone of my 100 engineers? Of course not. Would I buy 1 or 2 floating licenses to use when those *really* nasty, hard-to-catch bugs pop up one week before scheduled release? Yes, absolutely -- IF IT WORKS.

      --
      Generally, bash is superior to python in those environments where python is not installed.
  28. Visual Basic by keird · · Score: 1

    I know this won't be popular, but the lowly Visual Basic has had this feature forever. Of course, this will be very useful for real (compiled) languages and has to be better than the piece of crap "Edit and Continue".

  29. Any relation to ReVirt? by eddy · · Score: 4, Interesting

    ReVirt:

    The ability to replay the execution of a virtual machine is useful in many ways besides intrusion analysis. For example, it enables one to replay and debug any portion of a prior execution. We have built an extension to gdb that uses virtual-machine replay to provide the illusion of time travel. In particular, we provide the ability to do reverse debugging, though commands such as reverse watchpoint and reverse breakpoint. graph. See our paper in USENIX 2005 for details.

    --
    Belief is the currency of delusion.
  30. Elephants never forget by same_old_story · · Score: 5, Interesting
    John McCarthy has been talking about giving programming langues the notion of time for quite some time (no pun intended).

    In this paper, he proposes the Elephant language that can refer to the past in computer programs.

    Pretty cool stuff!

  31. Call Stack by sparkhead · · Score: 1

    I can back up easily enough with a call stack. I can see some situations where this approach might be better than a simple stack, but those instances would seem to be few and far between.

    1. Re:Call Stack by Anonymous Coward · · Score: 0
      I can back up easily enough with a call stack. I can see some situations where this approach might be better than a simple stack, but those instances would seem to be few and far between.
      Few and far between?? I am not sure how long you have been programming, but first any moderately complex program will, during development, have many bugs where the call stack does not allow you to see where the error first crept into the program. But, more importantly, any problem that you can see on the call stack will probably only take you 10 minutes to debug. This technology is an attempt to help with all the OTHER bugs, those that are so intermittent, or so far removed from where the program eventually dies, that it takes you days, weeks, or months to correctly debug. Reading their examples from the article you could have seen that.
    2. Re:Call Stack by p3d0 · · Score: 1

      Then you haven't done any really challenging debugging yet.

      --
      Patrick Doyle
      I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
    3. Re:Call Stack by sparkhead · · Score: 1

      Oh please. Refute the statement, don't attack the messenger. I stand by it.

    4. Re:Call Stack by p3d0 · · Score: 1
      Sorry, I didn't mean to attack you. To say that you don't encounter hard bugs was not meant as a personal insult. But what is there to say? If most of your bugs have an execution history that is captured on the call stack, then most of your bugs are pretty simple.

      For instance, all it takes is for an object to get corrupted by one function, then that function returns, and now your call stack can't tell you where the corruption occurred.

      --
      Patrick Doyle
      I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
    5. Re:Call Stack by cakoose · · Score: 1
      Oh please. Refute the statement, don't attack the messenger. I stand by it.

      Give me a break. The assertion of your original post (that a call stack is usually enough) was based entirely upon your personal experience. There was absolutely no deductive arguments or additional premises to support your conclusion. The only thing that could be refuted was your implicit assertion that you have the necessary experience to make such a decision.

      While some people do have enough karma capital to get away with an "in my experience", there's no evidence that you are one of them.

      Personally, I was fine with stack traces until I started doing embedded work. There are times where the ability to go backwards would *really* speed up the debugging process. Unfortunately, the boards I'm currently dealing with have a lot of custom hardware on it...not sure how easy it would be to get all the necessary specs into the simulator.

    6. Re:Call Stack by sparkhead · · Score: 1

      Actually that's not what I was saying. A problem can usually be tracked down by backing up until you do reach a point where you will be near the call that causes the corruption. More breakpoints, more monitoring, etc, will accomplish this. I don't see this environment having any great advantage - most of the time.

    7. Re:Call Stack by p3d0 · · Score: 1
      Oh are you talking about a kind of binary search for the bug? That works pretty well (for bugs that aren't intermittent) but that still requires you to re-run the program log(n) times from the beginning. At least this one only requires you to re-run it log(n) times from the last checkpoint. From that point of view, it doesn't sound very revolutionary.

      The real revolutionary part is if it's somuch faster than re-running the program from the start that you can forget about the binary search and just effectively run the program backward until you see exactly where the bug happened. They claim that this is the case.

      --
      Patrick Doyle
      I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
  32. Is This Really New? by Ginnungagap42 · · Score: 3, Interesting

    I remember that several of the older compilers like Borland's Turbo Pascal, Turbo C and Microsoft C and MASM could run reverse execution through the debugger. They also had the "animate" feature that let you step through the code automatically, but slowly so you could watch each line of code as it was executed. I remember setting my PC up with two video cards: a monochrome Hercules card and an EGA card. A lot of the compilers from those days supported mutiple graphics card output - the code would appear on the monochrome monitor and the running executable would appear on the color monitor.

    Being able to trace backwards ware extraordinarily useful, and it's one thing I miss in modern compilers. I always assumed that this capability was taken out with the advent of event-driven (GUI) programming. That's when a lot of this kind of functionality seemed to disappear.

  33. Re:!tsop tsrif by Anonymous Coward · · Score: 0

    Oh, come on! +1 Funny at least.

  34. Re:Doesn't work for multi-threaded programs by subrabbit · · Score: 1

    Yes it does. It works with any program, including operating systems.

  35. Obligotory jwz reversible gdb link by Anonymous Coward · · Score: 1, Interesting

    A while ago there was a jwz post about being able to run a debugger backwards (for some reason I thought this needed kernel patches). If the checkpointing happened at "machine" level this would be possible regardless of the language...

    (Actually someone has already posted the links jwz was talking about)

  36. Hmm... by thed00d · · Score: 2, Funny

    Interesting, but will it work on a dead badger running GNU/Linux? Cause thats where do all my development work.

    --
    http://www.accelerateglobalwarming.com
  37. My thesis by Urusai · · Score: 0, Offtopic

    that I'm currently (in theory) working on is about inverting Turing machines...now this comes out. Creepy. Time to change the tinfoil.

  38. Isn't this cheating??? by YodaToo · · Score: 0, Troll

    It seems there are people out there trying to make our jobs easier & easier to do, removing all of the mystery that surrounds us. With all of these fancy IDE's, debugging tools, etc. we are making ourselves less and less valuable. Before you know it, your grandmother will be an application developer and you'll be making minimum wage!

    --
    This way to the egress...
    1. Re:Isn't this cheating??? by Anonymous Coward · · Score: 0

      Not if you learn assembly :)

    2. Re:Isn't this cheating??? by t_allardyce · · Score: 1

      This is why we should thank Microsoft, for years they have consistently produced API's and architectures that are both confusing and full of bugs and special cases, not only that, they have also pioneered the area of rolling out new technologies that do little but serve to confuse. Although the *nix world has managed to gain respect as a 'master craft' of computing wizards making magic with vi and other 2 letter commands, more often than not unix architecture is to the point and sometimes stands for decades, Microsoft on the other hand have created literally millions of jobs, and interfacing windows and *nix based systems has created millions more, i solute you.

      trace/printf/cout is enough debugging for anyone.
      now on a side note does anyone know where i can get the c/c++ equivelent of php's print_r function?

      --
      This comment does not represent the views or opinions of the user.
    3. Re:Isn't this cheating??? by LionKimbro · · Score: 1

      Wha-? You didn't know about the AI's?

      We're not even going to be making minimum wage!

      But since we'll all be cyborgs, we'll probably get some renumeration for the tiny amount of computer power we are able to contribute to the hive from our own e-brain and attention.

      Then again, consider: Just how much does a 3'x3'x3' cube for housing your brain cost?

      Nice to think we'll all be vegan, finally, consuming our diet of proteins. Somehow, I don't think the present day vegans will be happy with this arrangement, though.

  39. Re:+1 Interesting by xilet · · Score: 0

    That was exactly the same thought I had, I just used the rest of my mod points 4 mins ago.

  40. Exec-8 (1968) - remember ? by tuomoks · · Score: 1

    Univac, EXEC 8 and TSO terminal, debugger that was able to do this and more - so the time goes..
    "Univac 1108, 36-bit SMP.
    Good, easy-to-use interactive mainframe OS.
    DMA-speed terminals, with local command history.
    ``Master Catalogue'' on drum.
    ``Roll-in/Roll-out'' reduced disk-space requirements.
    Files ``automatically'' copied from tape to disk on open.
    Files automatically copied to tape when space needed, based on file usage.
    Most OS code reentrant, shared between CPUs.
    Single kernel data structure, work queues."

  41. Refering to the past would be really handy by NotQuiteReal · · Score: 1
    Especially in a stock buying program!

    I didn't follow the link, but I imagine new constructs such as do over and go back - closely related to the just kidding clause.

    And what about memory leaks? Programs that can't remember their past are doomed to loop forever!

    --
    This issue is a bit more complicated than you think.
  42. Re:Oh Dear by HidingMyName · · Score: 1

    Some classes of errors are pretty hard to solve, in particular timing, synchronization, and some clases of hardware related failures can appear to be sporadic and very difficult to reproduce and analyze. When I'm up against one of those problems, I'll take all the help I can get. Particularly for timing dependent stuff, where instrumentation chan change the timing characteristics.

  43. Time saving estimates.. by lunadog · · Score: 1
    It is then necessary to restart the program from the beginning, and re-run it to just before that procedure call, which might only take a few seconds, but in many instances can take several hours.

    ....particularly on my Longhorn system.

    ....running on my C64.

  44. reversible computing == low energy computing by peter303 · · Score: 1

    The term "reversible computing" has also been used for a type of circuit that does not consume energy, other than entropy, for computation. The trick is run a computation in parallel that goes in the opposite direction. Theoretically, this would mean really long-lived laptops and space probes, but I haven't heard of anyone testing this on more than a few gates.

    1. Re:reversible computing == low energy computing by TeknoHog · · Score: 2, Informative
      The term "reversible computing" has also been used for a type of circuit that does not consume energy, other than entropy, for computation.

      I think you got it just the wrong way.

      Traditional computers generate entropy because of the information destroyed. Entropy created is necessarily associated with heat. With reversible computing there is no entropy increase, which in theory means less heat produced and less energy consumption.

      --
      Escher was the first MC and Giger invented the HR department.
  45. Where do they store the entropy? by goombah99 · · Score: 2, Interesting
    If computing is reversable then the system is not losing information. All that entropy has to go somewhere. while built up heat can radiate away on the fan, the entropy must keep building up. At some point its going to explode!

    more seriously, that would mean that there is no crypto on these machines since all encoding would be reversible.

    --
    Some drink at the fountain of knowledge. Others just gargle.
    1. Re:Where do they store the entropy? by Anonymous Coward · · Score: 0

      You're stupid, and whoever modded you interesting is almost as stupid. If you had a machine that automatically logged everything before it was encrypted, would there be no crypto on those machines either? What a stupid thing to say.

    2. Re:Where do they store the entropy? by tepples · · Score: 1

      more seriously, that would mean that there is no crypto on these machines since all encoding would be reversible.

      Even on true reversible computing machines (which this isn't; it's just a simulator that takes periodic snapshots), crypto is possible. The reverse of ciphertext = encrypt(key, plaintext) is plaintext = decrypt(key, ciphertext). No key, no reversibility.

  46. checkpoint the hard disk too? by goombah99 · · Score: 3, Insightful

    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.
    1. Re:checkpoint the hard disk too? by Anonymous Coward · · Score: 0

      And? Simics checkpoints the COMPLETE system, i.e. disks, networks, all the processors, the works. The whole reason that Hindsight works is that Simics already has complete system control thanks to it being a full-system simulator.

    2. Re:checkpoint the hard disk too? by DanShearer · · Score: 1

      Exactly! So this is full system simulation, and if whatever "the system" you care about is simulated then it can run backwards. I'm on the Simics product development team and this is what I do: pick the architecture (say, PPC32 with 4 network cards, 1 serial port and no video card); install an OS (say, Debian); configure my new simulated router. But you can't test a router in isolation, so I get pre-installed images of Linux, Solaris and Windows clients and servers and configure their networking to match my new router, and run them in the same simulated universe. Then I watch the client-server traffic happening across my router. This is one of the demos we ran at the ESC conference last week in San Francisco.

      Whoops! Something went wrong. So I hit reverse... that means that all clients and servers, all networking and in fact the global system clock all go backwards at the same rate and to the same point. I can then make some configuration change on my new router and then restart the simulated universe from that point. This is what we call "alternate futures". There's many other ways to achieve similar ends, but this is the least painful one I know.

      --
      Dan Shearer
  47. The title threw me off a bit by SomeoneGotMyNick · · Score: 1

    Although the summary cleared things up.

    At first glance, I thought I'd eventually take an "upgrade" path to a VIC-20 via "Reversible Computing"

  48. Re:!tsop tsrif by gorjusborg · · Score: 2, Funny

    C'mon, this is funny!

    It's friday people, lighten up :)

    --
    If it's not one thing, it's Steve's Mother
  49. Damn misleading articles. by PxM · · Score: 2, Informative

    I was getting excited since I thought they had actually created a practical reversible computing hardware system. The idea behind true reversible computing is that information flow in computation is linked to the energy lost as heat during computing. Von Neumann showed that there was a hard limit on the amount of energy needed everytime a bit of information is lost dependent on Boltzmann's constant and temperature of the system. The ultimate goal is to have a computer that looks a lot like particle physics where the rules are completely time-symmetric. I.e. if I reverse the flow of time, the laws of physics will still run properly and allow me to reconstruct all the previous states from the present one. While the principle of quantum reversibility (sometimes called the "conservation of information law") you can't do the same with most binary operations since all the common ones except NOT take in 2 bits and output 1 bit. Thus, it is impossible to run the system in reverse and reconstruct those two bits from that one bit. This has the adverse effect of wasting energy as heat into the environment.

    It's and interesting field that's going to take off as Moore's Law slows down due to wasted heat. A good starting page with links for the interested is here.

    --
    Free iPod? Try a free Mac Mini
    Or a free Nintendo DS, GC, PS2, Xbox
    Wired article as proof

    1. Re:Damn misleading articles. by fraudrogic · · Score: 2, Interesting

      ...you can't do the same with most binary operations since all the common ones except NOT...

      I'm not trying to be an ass here, but isn't that why they call NOT a unary operation, because of one operand?

      --
      I only mod up parents of "mod parent up" posts...
    2. Re:Damn misleading articles. by njh · · Score: 1

      I too was disappointed with the headline choice.

      Actually, you can solve the 2->1 folding problem quite easily. You just need to find gates that output as much information as they use. For example, an xor gate produces a single output, but if you invent the gate 'a,b' -> 'a, a^b' (xor*) then it is fully reversible and it is its own inverse.

      The trick is to make the electronics themselves fully reversible, rather than emulating xor* using a standard xor and a wire. I don't know how this is done. My basic physics understanding is that it is impossible to do real computation without any energy input as you are creating order, but the amount of energy required for computation is bounded by the change in entropy of the information, which is a very small amount!

      There are prototypes, I believe the real problem is size, not existence. As each operation does not destroy information, lots of spare bits pile up when you perform a calculation, and these all need to be stored. Operations tend to be exponential chip size from bits computed IIRC. This means that even relatively simple operations require far more chip size (means more error prone to make) than their inefficient lossy cousins.

      (dear sibling,)
      Not is an unary binary operation. unary refers to the single argument, binary refers to the domain (takes a true or a false as its single input). And is a binary binary operation :)

    3. Re:Damn misleading articles. by onemorechip · · Score: 1

      That's right, one binary operand.

      --
      But, I wanted socialized health insurance!
    4. Re:Damn misleading articles. by roie_m · · Score: 1

      Not is an unary binary operation. unary refers to the single argument, binary refers to the domain
      Are you sure you don't mean "boolean"? I've never heard the word "binary" used in that context. Not is a unary boolean operation, certainly, but I've never heard it called a binary operation.

    5. Re:Damn misleading articles. by arkanes · · Score: 1

      He may have avoided the use of boolean because it's usually used when referring to logical operations rather than bitwise ones. Although in the pure logical context they're the same thing.

    6. Re:Damn misleading articles. by njh · · Score: 1

      As in BCD, Boolean Coded Decimal? ;) I spose technically Boolean refers to the logic and binary refers to the encoding of numbers, but I've heard the terms used interchangably.

      Who cares anyway, it's just bit picking. (nit picking is base e :)

  50. Turbo Debugger by xbytor · · Score: 1

    I seem to remember being able to step backwards in Borland's Turbo Debugger. I don't remember details but I do remember trying it out a few times.

    TD was a great debugger for its time. They got the UI just right.

    1. Re:Turbo Debugger by Monkelectric · · Score: 1

      Sure did do that... I spent hours staring at that screen :) I do believe however there were limits to how far you could step back -- and not over call/ret boundaries IIRC.

      --

      Religion is a gateway psychosis. -- Dave Foley

  51. Last Post by Anonymous Coward · · Score: 1, Funny

    Last Post

  52. Come from? by AJWM · · Score: 3, Funny

    Reverse execution? Are we finally going to see an implementation of the COME FROM statement?

    (See also the entry in the jargon file.)

    --
    -- Alastair
    1. Re:Come from? by Tablizer · · Score: 2, Funny

      Personally, I like Evangelical Fortran. It has a GOTO HELL statement.

      --
      Table-ized A.I.
  53. RTFA by p3d0 · · Score: 2, Informative
    There are many types of calculations out there (think The Game of Life or other CAs) that by their nature cannot be reversed, so all of those states would have to be stored or it would be mathematically impossible to calculate the reverse steps.
    They take periodic system checkpoints and then work forward to the instruction preceeding the one you started from. There's no reason the Game of Life wouldn't be amenable to this.
    --
    Patrick Doyle
    I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
  54. Mod parent up by Animats · · Score: 3, Informative
    That's impressive technology. And it needs to be better known. Reverse-stepping has been available for gdb under Linux since at least 1999, and nobody knows it. So please, mod the parent up.

    This has real potential. Beta versions of programs should run with this installed, so the core dump can be stepped backwards to the trouble spot. This could make Linux software significantly more reliable.

  55. From the website... by ghost1911 · · Score: 2, Funny

    This is especially significant when you consider 50% of a software engineer's time is spent debugging software.

    They assume that programmers... DEBUG! Hah!

    --
    .: 2+2 = PI SQRT(1+N) :. All together now, what is n?
  56. There are a few issues but... by Morticae · · Score: 2, Interesting

    Since this appears to be a sandbox tool, what's the problem? The only real problem I can see, and that people bring up (since everything else is deterministic in a closed environment) would be random or psuedo random number generation. Could it not (or does it) simply save the results of system clock queries? Since the system clock is used to seed most random number generators, saving the return values and feeding them back could eliminate the problem. Clearly in encryption intensive programs this would act like some kind of memory bomb, but it would solve probably 99.9% of applications. As a safeguard, it could simply be alloted a certain area of memory that, once filled, would return to a 'closest fit' senario.

    1. Re:There are a few issues but... by Anonymous Coward · · Score: 0

      Simics simulates the complete system. I.e. the system clock is also simulated for the benefit of the virtual system. There is no indeterminism thanks to this. There is no relation between simulated time and real-world time in Simics!

  57. What, me lose brain cells? by Anonymous Coward · · Score: 1, Funny
    or you are writing a long document in a word processor, and you make a spelling error and you have to start from the beginning;

    That would be redicoulas.

    That would be redickulos.

    That would be ridikyulus.

    That would be funny!

  58. CodeGuide 7 does this for Java by Anonymous Coward · · Score: 0

    They seem to log execution and allow backstepping in individual threads:

    http://www.omnicore.com/debugger.htm

  59. don't worry by Anonymous Coward · · Score: 0

    in hindsight it will all become clear to them

  60. This *has* been done for the Game of Life by simon_clarkstone · · Score: 1
    What it does do is take complete snapshots every (for example) 100 steps. In order to move "backwards" a step, it returns to the previous breakpoint (a known state) and goes forward 99 steps.
    Then it returns to the same breakpoint and goes forward 98 steps. And so on. So from your perspective, you see the 99th step, 98th, 97th, and on down. It only LOOKS like it's running backwards.

    This would even work for the game of life.

    This *has* been done for Life, in Life32 (great program, and I am not affiliated). It works very well. It was in fact the first thing I thought of when I read this.
    --

    C:\>spell -b slashdot_submission.txt
    Bad command or file name.
  61. Hmm, that's cool. by MenTaLguY · · Score: 1

    Seems to me it at least deserves an attempt at revial. I may email the developer tonight if I have time and see if he'd be interested in participating (in an advisory capacity at least).

    I don't have time to do it all myself, but I can at least try to start the ball rolling...

    --

    DNA just wants to be free...
  62. bugmenot.com by Anonymous Coward · · Score: 0

    I didn't register to download it

    Well, whoever does, share the wealth.

    gewg_

  63. I need this! by Anonymous Coward · · Score: 0

    If only it could work...
    My current problem involves 4 cpus, 70 threads, 2GB RAM, a C/Just In time compiler/some assembler and a pointer being blatted in one of our data structures, once every eight hours.
    Would be interesting to see how often the actual error would occur under a simulator. Alas, the tool isn't for the machine I'm working on.

    sob.

  64. It doesn't seem to be affecting it, m'lord. by Anonymous Coward · · Score: 0

    --Biggles.

  65. I not really THAT big of a deal... by Vthornheart · · Score: 1
    Sorry to be the nay sayer this time, but I really don't see how this is so utterly impressive. For starters, all it takes is a little logical thinking to backtrack when you're debugging: every (or, nearly every) operation you can do on a computer can be thought of as having an input state, an operation on that input, and an output state. Backtracking, therefore, is as simple as coming up with the reverse of whatever the operation was, giving you the input state once more.

    And on top of that, most IDEs have a "set next statement" function, that combined with some quick on-the-fly restoration of variables that changed between then and now gives you the same effect. In fact, in that document it admits that all its really doing is having that second part (the restoration of variables) occur automatically instead of having the programmer do it manually.

    I'm glad that they did it, but not glad that they decided it was so groundbreaking (give me a break, we've been doing the same thing [admittedly manually, but still] for years) that they would charge such outlandish costs for it.

    --
    -Vendal Thornheart
    1. Re:I not really THAT big of a deal... by Stray7Xi · · Score: 1

      every (or, nearly every) operation you can do on a computer can be thought of as having an input state, an operation on that input, and an output state. Backtracking, therefore, is as simple as coming up with the reverse of whatever the operation was, giving you the input state once more.

      after execution of A=B the state is A is 1, b is 1... tell me what was A before execution. Clobbering of data is not reversible and is very common (as in everytime there's an assignment operator used). Even things like (A+B) which sound reversible at first aren't quite once you consider that the flags are clobbered (when'd the overflow flag get set?)

    2. Re:I not really THAT big of a deal... by Vthornheart · · Score: 1

      Hmm... well, in an isolated context you have a point... but then again, if you're stepping through the program anyways, you'd have known what the value for A was beforehand, and could have backtracked manually on your own.

      --
      -Vendal Thornheart
  66. Replay with nondeterministic events by DavidHopwood · · Score: 2, Interesting

    It is possible to replay the execution of programs that communicate with the outside world, rather than just in an isolated virtual machine: you have to log nondeterministic events. See http://www.erights.org/elang/concurrency/determini sm/overview.html.

    The first language I know of that supported replay is the Abundance database language, back in 1986. Also see http://c2.com/cgi/wiki?ReversibleProgrammingLangua ge.

  67. Implementing print_r in C++ by tepples · · Score: 1

    now on a side note does anyone know where i can get the c/c++ equivelent of php's print_r function?

    Functions such as print_r are available only in systems that allow for polymorphism. If all your classes and containers inherit interface from some Printable class, then you can implement print_r for each object, and then have containers call print_r on their contents.