Will assembly language die out

Why use assembler?

Assembler as a programming language is no longer very popular these days. Usually a third or fourth generation language is used.

Usually - for "08/15" applications - this is exactly the right thing to do. But there are situations in which it is necessary to look closely at the arguments for and against assembler.

On the one hand, the arguments against the use of assembler are largely prejudices, on the other hand, the arguments for using it are relatively unknown. If you have the prejudices against assembler knows and the advantages does not know, it will be very difficult to make an objective decision when choosing the programming language.

One rule remains important - as for each Programming language: without well-trained people you will get nowhere, without good documentation you will end up in an unknown position.

Below you will find an overview of the most important advantages of assembler. Then we will try to remove the prejudices. We end with a brief summary.

The advantages of assembler.

Working with assembler offers a number of possibilities which are not (in this entirety) available to 3GL or 4GL programmers.

  • Defensive mistake.
    How often does it happen that your applications stumble upon something as simple as an S0C7, or an intermediate file that is too small. With the help of a relatively simple assembly language routine, these problems can be handled and solved. Your applications don't just crash, they keep running. All problems encountered are logged and allow the controller to take the necessary actions.
  • Use of memory above the 16MB line.
    There are still many companies that (by necessity) convert with AMODE = 24. By adding small assembler modules, your application programs can run over the 16MB line and thus reduce the pressure under the 16MB line.
  • Dynamic memory management.
    Programs that maintain data in tables, lists or trees often do not know in advance how large the memory requirement will be. In assembler, memory can be allocated and released dynamically. This allows only the memory that is really needed to be requested and used.
  • Optimization.
    State-of-the-art compilers reliably generate efficient code. But you cannot decide what your specific optimization goals are. Because a programmer knows the structure of your application, they can make this decision. For example, it can reduce the risk of a page-steal operation to make the program faster and to reduce the load on the paging subsystem.
  • Use of operating system options.
    Many of these possibilities cannot be used by high-level programming languages. If they can be used, the additional effort is sometimes considerable, so that a possible gain in performance is overlaid by this effort.
    Among other things, there are:
    • Data spaces.
      Programs that require large amounts of memory can use data spaces. This reduces the need to create work files (which in turn saves I / Os) and at the same time reduces the need for storage (which avoids out-of-storage in the evening).
    • Virtual look-aside facility.
      VLF enables named data to be kept in memory outside of its own address space. For intensively used data (e.g. members in certain PDS files), this can significantly reduce the time for I / Os for your applications.
    • Simultaneous access to different files.
      If an application wants to read and / or write records from two or more files, it can do so at the same time. This is even possible for records in the same file. This overlap can save considerable I / O wait times, especially if the records are on different volumes.
    • Subtasks.
      A task can be accelerated considerably by dividing it into several subtasks. For example, by relocating the necessary creation of journal records to a second task, the sales transaction can be accelerated.
    • Reenterability.
      By reentranting frequently used programs, they can be stored in shared memory (preferably above the 16MB line). This means that all programs that use this code are accelerated because the probability of a page fault becomes minimal.

The prejudices against assembler.

There are various prejudices against working with assembly language. The most important are:

  1. Structured programming is impossible in assembler.
    This is not true. In this area, assembler actually offers more possibilities than many 3GLs.
  2. Maintaining assembly language programs is much more expensive than maintaining 3GLs.
    This may have been true when 3GLs were introduced. But today this statement can be debated.
  3. Assembler is a cumbersome language and difficult to learn.
    Assembler is in fact a little less readable for the layman than e.g. COBOL. Languages ​​like C and C ++, on the other hand, are much harder to master.
To 1.
Structured programming is impossible in assembler.
Bringing structure into programs is first and foremost a question of style and working method. If the programming language used offers good possibilities in this area, this can be of help, but nothing more.
  • In the area of ​​segmentation, assembler offers more options than 3GLs: In addition to the usual subroutines and functions, programs can be divided into CSECTs, which in turn can be divided into subroutines and functions.
    As an addition, you can choose between different types of call. Among other things: Standard 360 linkage conventions, the linkage stack or other calling methods, with or without a branch table.
    Finally, for the transfer of parameters, there is a choice between transferring the value, the reference or a mixture of these.
  • There are comparable possibilities for loop control in assembler with 3GLs. These are the so-called "branch on index" and "branch on count" instructions with their relative brothers. With the help of macros, these intructions can be expanded to include other powerful options.
  • Just like many 3GLs, assembler has a copy feature to copy standard code from a library member into the program.
  • Finally, the macro option offers a broad spectrum for structuring programs and standardizing recurring program constructs. When using conditional assembly it is always possible to optimize the generated code. Most 3GLs do not offer a comparable function.

To 2.
Maintaining assembler programs is far more expensive than maintaining 3GLs.
When 3GLs were first introduced, there was a broad base of assembly language programs in existence. Because structured programming was relatively new in those days, these programs left a lot to be desired when it came to structure. In assembler - as in any other language - you can create as much or as little structure as you want. With all the consequences for the later maintainability.
There are more possibilities in assembler than to wreak havoc in many 3GLs. Thanks to the macro option, there are several important options for creating more structure than in other languages.

A very important question is the question of style. A 3GL programmer who does "a bit of assembler" on the side can never compete with a professional assembler programmer. The results are measurable, not only in the time in which a given job is done, but also in the quality of the code produced. The main problem is: how do I find the experienced professional. A problem that you always have, no matter which language you choose.

So in order to make a fair comparison for required manpower between assembler and 3GLs, one must compare craftsman with craftsman and one must consider the age of the programs (read: degree of structure) and the quality of the existing documentation.

Our experience with new programs is an approx. 10 to 20 percent additional requirement for development in assembler. When it comes to nursing, the difference is too dependent on the availability of documentation and the structure of the programs to provide meaningful figures.

An example: One of our customers owns an assembler module (from us) and a COBOL module. Both do exactly the same thing. The last few changes were made by an assembler programmer in one day, whereas the Cobol programmer took 3 days. Although this sounds extraordinary, it shows that maintaining an assembler program is not automatically more complex than maintaining a 3GL program.

To 3.
Assembler is a cumbersome language and difficult to learn.
If you are addicted to the "layman", you should definitely not choose assembly language. As with any other language, you will only create your own problems.
Of course there are also professionals. They can not only program assembler, but also master the various options that assembler offers. This enables quick, efficient and clean work.


The arguments for and against the use of assembler can be summarized as follows:

  • Working with assembler takes a little more time. But nowhere near as much as is commonly thought.
  • Assembler offers more possibilities for structuring, although a lack of professionalism produces easier maintenance problems.
  • In assembler there are more possibilities to solve or prevent throughput problems.
  • It takes more time to find a professional.

In summary our tip: No assembler if it doesn't have to be. On the other hand, if there are reasons, just don't be embarrassed; Assembler isn't scary. And if you use assembler, please only for the modules that benefit from it. The greater part of your application is likely best written in your favorite 3GL or 4GL.

Finally, for some applications there is no alternative to assembly language. This is especially true for many exits.
Not only the operating system, but also many standard products are equipped with exit points so that installations can adapt this software to their needs. Assembler is the only language for many exits. With the above arguments, this should (hopefully from now on) not be an insurmountable problem.


This site is a member of a web ring.
You are invited to browse the list of mainframe enthusiast websites.
Dinos are not dead. You are alive and well in a data center near you. They speak strange languages ​​and do magic with the computer. And in case you're waiting for their ultimate extinction, dinosaurs ruled the world for 155 million years!
Dinos and other anachronisms.
[Join Now | Ring Hub | Random | << Prev | Next >>]

After the advantages of assembler.
After the prejudices against assembler.
After the summary.

According to the German homepage.
After the general homepage.

This text was written by A.F. Kornelis, translated by Martin Trübner.
© Copyright: A.F. Kornelis, 1997-2003. All rights reserved.
This translation: © Copyright: Martin Trübner, 2003. All rights reserved.
E-mail to the author or to the translator.

Here you will find the logos of our sponsors and the logos of the web standards that this page adheres to.