Nobody creates programs in computer code any more, and the amount of assembly language programming done in industry is limited. However, learning the two languages continues to be the simplest way to understand what’s “beneath the hood” of a given microcontroller (ìC) and prepare one once and for all high-level code programming. Debugging is frequently performed in the assembly level for high-level code programs (that is usually C for ìCs).
All compilers will generate assembly listings for that code they generate therefore the programmer can easily see the details of the code they produce. Difficult to find bugs usually require inspecting this program logic at this level. Therefore, any ìC programmer must be able to read and understand assembly language code. Many people (this author included) believe the easiest way (arguably the only method) to become good at reading assembly language would be to program inside it. The best guide to assembly language is to first examine a few programs written in computer code. It will help give a better comprehension of the ìC framework, and an knowledge of the objective of most of the features which exist in assembly.
What exactly do After all by the design of the ìC? It is the detailed functional description (what it really does – not how it does it) from the ìC. It is not essential to understand anything about how to create a ìC to be able to understand its architecture. It is actually, however, essential to understand its design so that you can either design the hardware for it, or even to program it in assembly. In fact, you need to know a lot about the architecture from the I/O, timer, and perhaps the interrupt subsystems even going to program a ìC in C.
Designing computers is the subject of other courses. Programming a ìC (and interfacing it to the world) is the topic of this course. Learning our ìC’s framework is the first step. The main elements of the design of the given ìC will be the description of their CPU, its memory organization, its processor control registers, I/O registers, and timer subsystems registers that exist. These later three are often memory-mapped registers.
An assembly statement consists of up to four fields. These are: [label[:]] [operation-code-specification operand(s) separated by commas] [;comment]
where  surround optional fields (and the optional colon in the label field). The only real field not optional will be the operand(s) field along with its existence and variety of elements is dependent upon the operation code (opcode) field. It will not (must not) exist for many instructions. The label field offers a symbolic handle for that information specified on that and perhaps succeeding lines. It is used to assign names to program variables, constants, and the starting of parts of code that need a reputation. Code sections which need names include subroutines, beginnings of loops, or areas of if-then-else style program constructs. The opcode field can specify either a machine instruction or it can be a command to the assembler. In the later case it will always be known as pseudo opcode or pseudo-op in short.
These assemblers have only a few pseudo-ops, but 120 machine instruction mnemonics. The opcode field dictates the number of operands that can be present (if any). These fields might appear on a line on its own except the operands field which must exist on the very same line since the opcode in which it really is connected. If a label is not followed by the optional colon it has to start in column 1.
Apart from that the fields will be in a free format. Any level of white space might appear between fields. No field can contain white space except the comment field and the operand field when it is a quoted string. No statement, in as well as itself, requires a izeurf label, but we will have programming situations which will necessitate labels. You should try to identify those situations in the following assembly code programs that are rewrites from the previously presented machine code examples.