Assembly learning thread

[Imadatobanisa]

Hi everyone now started learning Assembly...
I don't know where the right start point is. I know a little bit of Assembly knowledge (through C ). I chose Flat Assembler, and first of all, I'm going to learn how to :
- Define a variable
- Perform basic calculation commands (add, sub, imul, idiv, neg)
- Log (show) the variable value
- Print "Hello World !"
- Pause (a console program)

In my opinion, it's quite important. Before learning Assembly I have to know these basic knowledge... :)

Do you know guys? (Any help would be greatly appreciated)

[Catfish3]

http://www.drpaulcarter.com/pcasm/

[Imadatobanisa]

I had downloaded the documentation, but I really need some very necessary & critical knowledge, code snippet examples, debug code tool (like I said and mentioned above)... It's a hard problem (searching the necessary assembly code)

[Catfish3]

Downloading that PDF is only the first step. The next step is reading it.

At some point, you will need to learn the things covered in Carter's book, anyway. Do it now.

[Moschops]

Sooner or later in any subject, you'll reach a point where you can no longer piece it together by reading examples and finding Q&A threads and lucky guesses and awful factoid "tuts" online, but instead have to actually sit down and learn. In assembly, that point comes early.

[BHX]

I've had Carter's book for a while, but I haven't had a chance to read it due to doing some C++ projects I've had on my plate. Once I finish my simple game I'll get started on learning Assembly (so many people say it is useless today, but from what I read it is still very much used in the industry).

[htirwin]

When I get the time I want to make it all the way through "The Art of Computer Programming; Fundamental Algorithms" by Donald Knuth. The language used throughout the book is assembly language for MIX (a mythical machine invented by Knuth). Knuth wanted to teach algorithms in a low level language so people will get a more in depth understanding them from reading his book.

MIX is "quite obsolete" and Knuth plans to replace MIX (similar to machines of the 1960's and 70's) with MMIX (similar to machines of the 1990's) in subsequent editions (someday).

Will knowing assembly for Knuth's mythical and obsolete machine be of any use to me? I don't know. I think it will help me understand algorithms at a low level, and prepare me for using other assembly languages.

I enjoyed reading this blog about whether or not you should read Knuth.

Especially this quote:

In my mind, reading Knuth is similar to choosing to walk three years by foot to some remote location in the mountains, in order to study with some famous zen monk (a thought that is somehow made more amusing by the fact that Knuth bears a certain resemblance to Yoda). Once you've made up your mind to study with this monk, you don't really question why he does things this way or that way - you just do as you're told. Wax on, wax off, if you like.

http://www.computas.com/Blogg/Einar-Host/Dates/2012/7/To-Knuth-or-not-to-Knuth/

[helios]

The thing about Assembly is that it generally takes a lot of skill to produce better code than a compiler. If you plan on working on a lot of performance-sensitive code, it makes sense to try to master it, but don't expect to get good results by just rewriting a function in Assembly. You really need to buckle down and think about what the CPU is doing and where it's spending the most time (feeding registers? Cache misses? Branch mispredictions?). Optimizing compilers do these things already, in the form of say, register allocation and loop unrolling, so to get better results you need to do them better than them. It's not impossible, and people do produce better code, but it takes practice.

[rapidcoder]

The thing about Assembly is that it generally takes a lot of skill to produce better code than a compiler

This is just as true as saying it takes a lot of skill to produce faster C++ code than a Java Hotspot compiler.

Actually C/C++ compilers are pretty dumb. There are many ways to write C code that will make a C compiler do wrong decisions. Overuising pointers (see pointer aliasing) is one of them. Another one is SSE and loop unrolling. Compilers deal fine only with trivial cases, but manually you can often get a 2x or 4x speedup.

[helios]

Must be raining fire somewhere. rapidcoder is implying writing in C++ gives a considerable speedup over Java.

[rapidcoder]

Yep, this is a similar situation as writing in assembly gives a considerable speedup over C. There are some edge cases. But in most cases, especially if you don't have ridiculous amount of time to optimize, but on the other hand you don't do something totally stupid (like using Vector instead of ArrayList or using finalize as a substitution for a destructor), the difference is enough small it is ok for many applications considred high performance (e.g. web servers and database systems).