In the context of reverse engineering I feel like learning assembly this way is &#x27;doing it wrong&#x27;. Of course, there&#x27;s no such thing as &#x27;doing it wrong&#x27; when it comes to learning, but here&#x27;s what worked for me.<p>What worked for me was going in the opposite direction: start with simple C programs [0], and see what compilers do with them. If you understand C, you already kind of understand how the machine works, though without the machine specifics. If you see an assembly instruction that you don&#x27;t recognize, check the manual [1]. You can do this online these days, say, with [2]. Here&#x27;s an example of a simple program that covers calls and branches: <a href="http:&#x2F;&#x2F;goo.gl&#x2F;DKrYrE" rel="nofollow">http:&#x2F;&#x2F;goo.gl&#x2F;DKrYrE</a><p>Then, use an interactive debugger (like OllyDbg or whatever works for your platform) to trace through your small programs, instruction by instruction, and see how memory and registers get manipulated at each step. Change instructions and see what happens. This will also make you familiar with common compiler idioms, which is very useful in RE work. Once you get reasonably familiar with these small programs, try your hand at a program you _don&#x27;t know_, or increase the complexity of your small programs. Rinse and repeat.<p>[0] The choice of C here is relevant, since many other compiled languages tend to add a lot of cruft to their binaries.<p>[1] <a href="http:&#x2F;&#x2F;www.felixcloutier.com&#x2F;x86&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.felixcloutier.com&#x2F;x86&#x2F;</a><p>[2] <a href="http:&#x2F;&#x2F;gcc.godbolt.org&#x2F;" rel="nofollow">http:&#x2F;&#x2F;gcc.godbolt.org&#x2F;</a>