Advantages and disadvantages of the Assembler Language
Once we have seen the evolution of languages, we can ask ourselves: In these “modern” times, why do I want the Assembler Language?
The process of evolution brought with it some disadvantages, which we will now see as the advantages of using the Assembler Language, with respect to a high level language:
- Efficiency in size
On the other hand, being a more primitive language, the Assembler has certain disadvantages with respect to high-level languages:
- Programming time
- Large source programs
- Danger of unexpectedly affecting resources
- Lack of portability
The translation process performed by the interpreters implies an additional computation process to which the programmer wants to carry out. Therefore, we will find that an interpreter is always slower than performing the same action in Assembler Language , simply because it has the additional cost of translating the program , every time we execute it.
From there the compilers were born , which are much faster than the interpreters, because they do the translation once and leave the object code, which is already Machine Language, and can be executed very quickly. Although the translation process is more complex and expensive than assembling a program, we can usually disregard it, against the advantages of coding the program more quickly.
However, most of the time, the code generated by a compiler is less efficient than the equivalent code that a programmer would write. The reason is that the compiler does not have as much intelligence , and it requires being able to create generic code, which serves both a program and another; in exchange , a human programmer can take advantage of specific features of the problem, reducing the generality but at the same time , does not waste any instruction, any process that does not need.
To give us an idea, on a PC, and assuming that all are good programmers, a program to order a list will take about 20 times more in Visual Basic (an interpreter), and 2 times more in C (a compiler), than the equivalent in Assembler.
Therefore, when the speed of the program is critical , Assembler becomes a logical candidate as a language.
Now, this is not an absolute; a well-made C program can be many times faster than a poorly done program in Assembler; It remains extremely important to the proper choice of algorithms and structures of data . For this reason, it is recommended to seek to optimize these aspects first, in the language you want, and only use Assembler when more optimization is required and can not be achieved by these means .
For the same reasons we saw in the speed aspect, compilers and interpreters generate more machine code than necessary; therefore, the executable program grows. Thus, when it is important to reduce the size of the executable, improving the use of memory and also having benefits in speed, you can agree to use the Assembler language. Among the programs that are critical to the minimum use of memory , we have viruses and device drivers (drivers). Many of them, of course, are written in the Assembler language.
The above reasons are a matter of degree: we can do things in another language, but we want to do them more efficiently. But all high-level languages ??have control limitations; when doing abstractions, they limit their own capacity. That is, there are tasks that the machine can do, but that a high level language does not allow. For example, in Visual Basic it is not possible to change the resolution of the monitor to half the program; it is a limitation, imposed by the Windows GUI abstraction . On the other hand, assembler is very simple, because we have direct access to the monitor’s hardware.
Being of low level, the Assembler Language requires more instructions to perform the same process, compared to a high level language. On the other hand, it requires more care on the part of the programmer, since it is prone to logic errors being reflected more strongly in the execution.
Because of all this, the development of comparable programs in Assembler Language is slower than in a high level language, since the programmer enjoys less abstraction.
Large source programs
For the same reasons that the time increases, the source programs grow ; simply, we require more primitive instructions to describe equivalent processes . This is a disadvantage because it hinders the maintenance of programs, and again reduces the productivity of programmers.
Danger of unexpectedly affecting resources
We have the advantage that everything that can be done in the machine, can be done with the Assembly Language (flexibility). The problem is that any mistake we can make, or any risk we may have, we can have in this language too. In other words, having a lot of power is useful but it is also dangerous.
In practical life, fortunately, not much happens; However, when programming in this language you will see that it is much more common for the machine to “hang up”, “block” or “the plane goes”; and that is reinitialized. Why? Because with this language it is perfectly possible (and simple) to make sequences of invalid instructions, which normally do not appear when using a high level language.
In certain extreme cases, it may be possible to overwrite the CMOS information of the machine (I have not seen more risky effects); but, if we do not keep it, this can cause us to stop “seeing” the hard drive , along with all its information.
Lack of portability
As already mentioned, there is an assembly language for each machine; therefore obviously it is not a choice appropriate language when we want to encode into a machine and then bring programs to other systems operating or models of computers . While this is a general problem for all languages, it is much more noticeable in assembler: I can reuse 90% or more of the code I develop in “C”, on a PC, by taking it to an RS / 6000 with UNIX, and the same if later I take it to a Macintosh, as long as it is well done and follows the “C” standards, and the principles of programmingstructured. On the other hand, if we write the program in Assembler of the PC, however well we develop it and many standards that we follow, we will almost have to rewrite 100% of the code when taking it to UNIX, and again the same when taking it to Mac.
Let’s see now how they are organized and a brief description of them:
|8 bit register||R of 16 b to which belongs||Description|
|TO||AF||Accumulator. The most used record J.|
|F||AF||Flags. Indicators of state .|
|B||BC||Normally used as an accountant.|
|H||HL||HL is ideal for accessing J memory.|
|TO’||AF ‘||A alternative.|
|F’||AF ‘||Alternative F|
|B ‘||BC ‘||Alternative B|
|C ‘||BC ‘||Alternative C|
|D ‘||FROM’||Alternative D|
|H ‘||HL ‘||Alternative H|
|L ‘||HL ‘||Alternative L|
|Xh||IX||IX is valid for indexed addressing.|
|Yh||IY||IY is valid for indexed addressing.|
A part of those, it has another two that are boléanos (1 only bit), called iff0 and iff1 (and at least another internal register of 8 bits for its internal calculations).
The records with < ‘> are alternative. Let’s say that they are on the bench waiting for his counterpart to leave the game to enter him. They can not be accessed directly (there would be more players than the regulators), but you can always make the change (here they are unlimited). Whenever one of these changes occurs, an entire 16-bit register is exchanged. It is not worth changing only one of 8.
Xh, Yh, Xl, Yl are the 8-bit registers that make up IX and IY. Officially, the instructions that operate on them are undocumented, but it seems silly not to talk about them from the beginning.
PC contains the “program counter”, that is, the memory address in which the processor will read its next instruction