Depends when you mean by "analyze", if you mean find out what it does, then yes, you probably need to understand the code and the computer won't help you do that. If you mean how fast it'll be, how to optimize it, etc, then there are tools available for this kind of stuff (but it doesn't hurt to understand what the assembly is doing, either).

“If I understand the standard right it is legal and safe to do this but the resulting value could be anything.”

If you just want to see how code in one language turns into assembly, most compilers give you an option to see generated assembly. For gcc you can use the -S switch and with MSVC you can use the /FA switch.

That part is not too hard. The first hit on Google for `assembly x86 tutorial' was this page, which seems reasonable. You can then ask your C or C++ compiler to generate assembly output for some simple programs and try to analyze what it's doing. If you have optimizations turned off, it should be pretty straight forward most of the time.

If you get far enough to understand how conditional statements and loops are implemented, you should make a little extra effort and understand how function calling and local variables work, since that's very informative for any programmer.

If you have optimizations turned off, it should be pretty straight forward most of the time.

Well, I must anaylze a code with full optimization especially in a loop, so I know what kind of loop optimization(such as interchanging, unrolling) is happening.Is optimized assembly harder to understand?

1 C++ line is not 1 assembly line, especially with optimizations enabled. There is no simple one-to-one translation between a lower level and a higher level language. You will just need to learn basic assembly, there is no way around that. You can't learn how to ride a bike by driving a car!

“If I understand the standard right it is legal and safe to do this but the resulting value could be anything.”

I was wondering if assembly code could show if branch prediction is taking place.

No, that doesn't make any sense. Branch prediction is a feature of the CPU, which tries to execute the code as fast as possible, but the assembly is not instrumented in any way to enable it: The CPU will do it automatically everywhere.

I was wondering if assembly code could show if branch prediction is taking place.

No, that doesn't make any sense. Branch prediction is a feature of the CPU, which tries to execute the code as fast as possible, but the assembly is not instrumented in any way to enable it: The CPU will do it automatically everywhere.

Actually, this is not true for all instruction sets. Some don't have complex branch prediction mechanisms but rely on branch hinting where a special branch hint instruction has to be issued a few cycles before the branch. In those cases you can actually check in the assembly if the branch hint instruction is present and located in the right spot.

For x86 (or x86_64) however, this is not the case, as alvaro already pointed out. But all modern intel and amd CPUs have hardware counters that can be used by profilers to tell you, where branch mispredictions occure. See oProfile (Linux) or vTune and CodeAnalyst (Windows).

My two cents: grab a disassembler - a program which shows you the assembly of a compiled EXE or DLL file.. I used to modify all sorts of programs (while simultaneously gaining a bare-minimum awareness of assembly itself) by disassembling them, and editing their code directly using a hex editor - overwriting small bits of existing code by surmising the actual byte opcodes of the asm instructions I desired and writing them in by hand.. Also, writing programs that would do it all in memory (WriteProcessMemoryEx) so that the original file could be left alone while effecting the equivalent change in functionality once the target was running. That may or may not help you.