Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Hindsight: Reversible Computing

Hemos posted more than 9 years ago | from the step-back-into-the-past dept.

Programming 178

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.

Sorry! There are no comments related to the filter you selected.

Funnay (0, Flamebait)

Godboy_g (794101) | more than 9 years ago | (#11909308)

*Insert Obligatory Hindsight is 20/20 joke here*

!tsop tsrif (1, Funny)

destinedforgreatness (753788) | more than 9 years ago | (#11909310)

cheap joke. sorry.

Re:!tsop tsrif (0)

Anonymous Coward | more than 9 years ago | (#11909629)

Oh, come on! +1 Funny at least.

Re:!tsop tsrif (2, Funny)

gorjusborg (603799) | more than 9 years ago | (#11910254)

C'mon, this is funny!

It's friday people, lighten up :)

Sounds good - but expensive. (4, Informative)

bigtallmofo (695287) | more than 9 years ago | (#11909317)

From reading about this earlier [eetimes.com] , 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.

Not necessarily (4, Informative)

spookymonster (238226) | more than 9 years ago | (#11909350)

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

Re:Not necessarily (1)

subrabbit (866878) | more than 9 years ago | (#11909869)

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

That's just nutty... (3, Informative)

The Desert Palooka (311888) | more than 9 years ago | (#11909318)

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?

Re:That's just nutty... (2, Interesting)

frobnoid (64717) | more than 9 years ago | (#11909382)

Take a look at
http://www.lambdacs.com/debugger/debugger.html [lambdacs.com] 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.

Microsloth (0, Offtopic)

TimeTraveler1884 (832874) | more than 9 years ago | (#11909481)

...running the code [ass] backwards...
Funny, the way Windows runs sometimes, I thought this was Microsoft's idea.

Re:That's just nutty... (1)

tagish (113544) | more than 9 years ago | (#11909638)

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.

Re:That's just nutty... (1)

CortoMaltese (828267) | more than 9 years ago | (#11909700)

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.

Re:That's just nutty... (3, Insightful)

paulsnx2 (453081) | more than 9 years ago | (#11909954)

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

Re:That's just nutty... (3, Interesting)

VAXman (96870) | more than 9 years ago | (#11910366)

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.

Re:That's just nutty... (2, Insightful)

matman (71405) | more than 9 years ago | (#11910505)

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

Re:That's just nutty... (2, Informative)

zootm (850416) | more than 9 years ago | (#11910055)

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

Turbo Debugger (1)

xbytor (215790) | more than 9 years ago | (#11910572)

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.

First Post (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#11909319)

First post are so damn annoying.

Re:First Post (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#11909414)

... and you are too damn slow trollboy

hrmmm (1)

Dimentox (678813) | more than 9 years ago | (#11909320)

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

Re:hrmmm (1, Interesting)

Anonymous Coward | more than 9 years ago | (#11909505)

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.

Re:hrmmm (0)

Anonymous Coward | more than 9 years ago | (#11909534)

Debugging is "practicality," douchenuts.

Where do they store the entropy? (2, Interesting)

goombah99 (560566) | more than 9 years ago | (#11910123)

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.

Demos? (0)

mordors9 (665662) | more than 9 years ago | (#11909321)

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

Remember When (0)

Anonymous Coward | more than 9 years ago | (#11909337)

..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?

UI (5, Interesting)

GigsVT (208848) | more than 9 years ago | (#11909347)

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.

Re:UI (2, Interesting)

lazer_nm (593581) | more than 9 years ago | (#11909364)

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 [lauterbach.com] 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"

Re:UI (1)

hrieke (126185) | more than 9 years ago | (#11909430)

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?

Re:UI (1)

dtfinch (661405) | more than 9 years ago | (#11909647)

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.

Re:UI (0)

Anonymous Coward | more than 9 years ago | (#11910176)

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.

Re:UI (2, Interesting)

TuringTest (533084) | more than 9 years ago | (#11909596)

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...

Mirror (4, Informative)

tabkey12 (851759) | more than 9 years ago | (#11909353)

Mirror of the PDF [mirrordot.org]

Never underestimate the Slashdot Effect!

Re:Mirror (-1)

Anonymous Coward | more than 9 years ago | (#11909514)

Never underestimate the Slashdot Effect!

You seem to forget the second rule, which is:
You don't need mirrors for files such as
  • PDF documents
  • RealPlayer videos
  • Goatse web site links
  • Microsoft Office .doc documents

Virtualization layer for checkpointing and steppin (4, Informative)

jaxdahl (227487) | more than 9 years ago | (#11909356)

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.

checkpoint the hard disk too? (3, Insightful)

goombah99 (560566) | more than 9 years ago | (#11910154)

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.

"Last Technical Hurdles"? (1, Interesting)

Catiline (186878) | more than 9 years ago | (#11909359)

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?

Re:"Last Technical Hurdles"? (0)

Anonymous Coward | more than 9 years ago | (#11909389)

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

The trick... (2, Funny)

Professor S. Brown (780963) | more than 9 years ago | (#11909423)

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.

Re:"Last Technical Hurdles"? (1, Troll)

shish (588640) | more than 9 years ago | (#11909576)

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.

But what about external events (4, Interesting)

bangzilla (534214) | more than 9 years ago | (#11909368)

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?

Re:But what about external events (5, Informative)

tesmako (602075) | more than 9 years ago | (#11909428)

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.

Re:But what about external events (2, Interesting)

G. W. Bush Junior (606245) | more than 9 years ago | (#11909996)

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.

Re:But what about external events (4, Funny)

LiquidCoooled (634315) | more than 9 years ago | (#11909439)

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.

Re:But what about external events (0)

Anonymous Coward | more than 9 years ago | (#11909949)

8-)

Re:But what about external events (1)

martyros (588782) | more than 9 years ago | (#11910705)

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 [slashdot.org] .

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.

better be (1, Funny)

promantek (866291) | more than 9 years ago | (#11909371)

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

Too good to be true... (5, Insightful)

Leadhyena (808566) | more than 9 years ago | (#11909395)

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.

Re:Too good to be true... (1)

ysachlandil (220615) | more than 9 years ago | (#11909612)

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

Re:Too good to be true... (1, Informative)

Anonymous Coward | more than 9 years ago | (#11909707)

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.

Re:Too good to be true... (3, Informative)

CausticPuppy (82139) | more than 9 years ago | (#11909747)

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.

RTFA (2, Informative)

p3d0 (42270) | more than 9 years ago | (#11910953)

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.

Wow ! (4, Funny)

Digital Warfare (746982) | more than 9 years ago | (#11909397)

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

I can hear it now, "Godlike!"

The Omniscient Debugger? (3, Informative)

Anonymous Coward | more than 9 years ago | (#11909402)


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

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

BSOL? (3, Funny)

bunyip (17018) | more than 9 years ago | (#11909417)

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

That would be so cool...

Alan.

Re:BSOL? (1)

Thuktun (221615) | more than 9 years ago | (#11910885)

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

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

Problems with platform emulalators (2, Insightful)

selectspec (74651) | more than 9 years ago | (#11909422)

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.

Thats simple... (3, Funny)

Anonymous Coward | more than 9 years ago | (#11909432)

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

Not by a decade. (5, Interesting)

Murmer (96505) | more than 9 years ago | (#11909449)

This technology has existed, in GPL form [shout.net] , for ten years. It's just had exactly zero uptake.

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

+1 Interesting (-1, Offtopic)

TuringTest (533084) | more than 9 years ago | (#11909539)

I already used all my mod ponts for today, before I found the really interesting post.

Re:+1 Interesting (0)

xilet (741528) | more than 9 years ago | (#11909802)

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

Re:Not by a decade. (1)

zogger (617870) | more than 9 years ago | (#11910848)

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

Bash VB all you want.... (1, Informative)

Anonymous Coward | more than 9 years ago | (#11909452)

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!

Oh Dear (-1)

Anonymous Coward | more than 9 years ago | (#11909454)

I write professional code, and am pretty good.

I rarely use a debugger.

I debug by:
Hypothesize problem
Insturment code
Run
Analyze
Repeat

Debuggers that run backwards are of second or third order importance.

If anything, this should be added to valgrind.

Re:Oh Dear (1)

HidingMyName (669183) | more than 9 years ago | (#11909842)

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.

Reverse Execution of Code? Haha! Oh wait... (2, Interesting)

AceJohnny (253840) | more than 9 years ago | (#11909457)

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?

Re:Reverse Execution of Code? Haha! Oh wait... (1)

BradleyUffner (103496) | more than 9 years ago | (#11909538)


"However how does it work with hardware?"
It doesn't. It works inside a virtual machine.

Re:Reverse Execution of Code? Haha! Oh wait... (2, Interesting)

0x461FAB0BD7D2 (812236) | more than 9 years ago | (#11909769)

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.

Re:Reverse Execution of Code? Haha! Oh wait... (2, Informative)

HidingMyName (669183) | more than 9 years ago | (#11909793)

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 [rpi.edu] .

Re:Reverse Execution of Code? Haha! Oh wait... (0)

Anonymous Coward | more than 9 years ago | (#11910411)

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.

Reversible Computing != Reversible Execution (5, Informative)

Anonymous Coward | more than 9 years ago | (#11909494)

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.

Re:Reversible Computing != Reversible Execution (1)

dmanny (573844) | more than 9 years ago | (#11909782)

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

Damn misleading articles. (2, Informative)

PxM (855264) | more than 9 years ago | (#11910353)

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 [ufl.edu] .

--
Free iPod? Try a free Mac Mini [freeminimacs.com]
Or a free Nintendo DS, GC, PS2, Xbox [freegamingsystems.com]
Wired article as proof [wired.com]

Re:Damn misleading articles. (2, Interesting)

fraudrogic (562826) | more than 9 years ago | (#11910444)

...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?

OCaml anyone? (4, Interesting)

fab13n (680873) | more than 9 years ago | (#11909498)

OCaml [inria.fr] 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...

Coding C in Eclipse? (1)

Laz10 (708792) | more than 9 years ago | (#11909524)

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.

Re:Coding C in Eclipse? (1)

jbrocklin (613326) | more than 9 years ago | (#11909656)

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!

Re:Coding C in Eclipse? (0)

Anonymous Coward | more than 9 years ago | (#11910932)

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?

Worth it if it works... (1)

kclittle (625128) | more than 9 years ago | (#11909526)

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

Visual Basic (1)

keird (519534) | more than 9 years ago | (#11909529)

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

Any relation to ReVirt? (4, Interesting)

eddy (18759) | more than 9 years ago | (#11909532)

ReVirt [umich.edu] :

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.

Elephants never forget (5, Interesting)

same_old_story (833424) | more than 9 years ago | (#11909550)

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 [stanford.edu] that can refer to the past in computer programs.

Pretty cool stuff!

Refering to the past would be really handy (1)

NotQuiteReal (608241) | more than 9 years ago | (#11909820)

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!

Doesn't work for multi-threaded programs (-1)

Anonymous Coward | more than 9 years ago | (#11909555)

which is where most programmers have problems.

Re:Doesn't work for multi-threaded programs (1)

subrabbit (866878) | more than 9 years ago | (#11909652)

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

Call Stack (1)

sparkhead (589134) | more than 9 years ago | (#11909574)

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.

Is This Really New? (3, Interesting)

Ginnungagap42 (817075) | more than 9 years ago | (#11909586)

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.

Obligotory jwz reversible gdb link (1, Interesting)

Anonymous Coward | more than 9 years ago | (#11909683)

A while ago there was a jwz post about being able to run a debugger backwards [slashdot.org] (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 [slashdot.org] the links jwz was talking about)

Hmm... (2, Funny)

thed00d (822393) | more than 9 years ago | (#11909703)

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

My thesis (0, Offtopic)

Urusai (865560) | more than 9 years ago | (#11909714)

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

Isn't this cheating??? (0, Troll)

YodaToo (776221) | more than 9 years ago | (#11909741)

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!

Re:Isn't this cheating??? (0)

Anonymous Coward | more than 9 years ago | (#11910216)

Not if you learn assembly :)

Re:Isn't this cheating??? (1)

t_allardyce (48447) | more than 9 years ago | (#11910521)

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?

Re:Isn't this cheating??? (1)

LionKimbro (200000) | more than 9 years ago | (#11910915)

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.

Exec-8 (1968) - remember ? (1)

tuomoks (246421) | more than 9 years ago | (#11909803)

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

Time saving estimates.. (1)

lunadog (821751) | more than 9 years ago | (#11909941)

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.

reversible computing == low energy computing (1)

peter303 (12292) | more than 9 years ago | (#11910056)

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.

Re:reversible computing == low energy computing (2, Informative)

TeknoHog (164938) | more than 9 years ago | (#11910214)

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.

The title threw me off a bit (1)

SomeoneGotMyNick (200685) | more than 9 years ago | (#11910158)

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"

Last Post (1, Funny)

Anonymous Coward | more than 9 years ago | (#11910618)

Last Post

Come from? (3, Funny)

AJWM (19027) | more than 9 years ago | (#11910663)

Reverse execution? Are we finally going to see an implementation of the COME FROM [fortran.com] statement?

(See also the entry in the jargon file [catb.org] .)
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?