Decompiling

decompilers (fail to) work as such: find which architecture -> disassemble -> pattern finder/search for common code segments/idioms, language dependent -> turn into higher level code. it would seem to me what is needed is a good database of the high-level -> assembly idioms, that the decompiler accesses at run time and is always updated as new links are found (thinking that the decompiler would be part of a suite with other tools to help find these links). how many different ways do different compilers really have available to make "if(a==b)"? and more complex code is just combination of these smaller parts. assuming they optimize when compiling, that's what's really needed, a way to keeping track of these different ways of doing the same thing, slight variations, etc., and of course a way to find them in the first place (the suite i mentioned, which i also have ideas for; properly formatted assembly for starters). i don't get why decompilers don't work.

>>11 is technically right, however:

Decompilation is a relatively simple syntactic transformation; it does not give you new information.
The difference between call sub_12345678 and sub_12345678() is negligible, but the difference between call sub_12345678 and call launch_the_missiles is huge. Registers, stacks and jumps are the least of a reversers' concerns.

When a decompiler is reliable, it can help you a bit by converting the code to a language you are more familiar with. This is the case for e.g. Reflector (on unobfuscated, compiler-generated code).
When a decompiler requires constant babysitting, the costs quickly outweigh the benefits. Over the last year of intensively using IDA, I can count the number of times Hex Rays was helpful on the fingers of one hand.

Also >>1 is an idiot.