Just a quick little tutorial on getting started writing assembly language for Intel and Intel-compatible (i.e. AMD) processors. This will cover IA-32 only for now.

First thing you need to know about the processor is that you don't really have a lot to work with - you can't just create your own variables and use them at will. Fortunately, you're given some very fast little variables called registers. Some of them are general-purpose, some are dedicated to performing a specific task. There are six 32-bit registers you can use for almost anything, as well as two more that are dedicated to use on the stack (I'll get to that later):

EAX, EBX, ECX, EDX, ESI, EDI

To retain backwards compatibility with 16-bit predecessors, the above 32-bit registers have the low 16 bits aliased to these registers:

AX, BX, CX, DX, SI, DI

If you were to store 0xCAFEBABE* in EAX, then the value of AX would be 0xBABE. Changing AX to 0xDEAD means that EAX now contains the value 0xCAFEDEAD.

The registers AX, BX, CX, and DX are further subdivided into two registers each. So AX is composed of AH and AL, aliased to the high and low bytes of the word respectively. (E)SI and (E)DI don't do this because they're intended for use as pointer registers, but you can use them for anything, really.

Perhaps an example in C++ would help:

uint32_t eax;
//AX points to low word of EAX. Since Intel processors
//are little-endian, we don't have to do any pointer
//arithmetic.
uint16_t& ax = (uint16_t *)&eax;
//same for AL
uint8_t& al = (uint8_t *)&ax;
//AH points to the HIGH byte, so we have to add one
//byte to get the proper offset into AX.
uint8_t& ah = ((uint8_t *)&ax) + 1;

Well, this is all well and good, but how does one do anything to these registers? The most common command is mov. Take a look:

Yes and no. The instruction set for the Intel 8086 was incredibly small, only about 256 instructions or so. The modern Intel instruction set has over 400. Changes in architecture also affect the language, i.e. adding new registers, new memory addressing modes, changing the behavior of functions, etc. Because it's so highly reliant on the processor architecture, there can't be a single assembly language. Due to backwards compatibility and legacy emulation modes, you can write a program for an 80386 and it'll (probably) run on a Pentium IV with no problems (disregarding the operating system, of course). The language is also typically compatible across a generation (sometimes even more), so you can write a program for a Xeon and expect it to run on a Celeron unmodified. The differences, if any, are usually minor, and usually just involves adding an instruction or three.

I would dare to say that assigning variables is the most basic and important statement you can do in C#. Therefore the fact that your tutorial is based on mov instructions seems to be... a very good idea. +rep

Do you think that writing most desktop applications and even operating systems will be become a good idea? .NET and Mono assemblies are always compiled into native code eventually, with the highest (best) instruction set available.

Do you think that writing most desktop applications and even operating systems will be become a good idea?

In assembly language? Dear God, no. You should use it for writing device drivers, self-modifying code, viruses, BIOS routines, code for embedded systems, and things that require high speed or have severe memory constraints. Writing a modern operating system in assembly language would be a daunting task, but it has been done.

Do you think that writing most desktop applications in managed code and even operating systems will be become a good idea? .NET and Mono assemblies are always compiled into native code eventually, with the highest (best) instruction set available.

Therefore managed code is versatile, while also with the best performance. As long as memory constraints are not as limiting as in a handwatch.