Why assembler?

Using assembler as a programming language is not so popular any more. As a rule people prefer to use a third or fourth generation language.

Usually - for "vanilla" applications - this is absolutely right. There are however situations in which it is prudent to thoroughly weigh both the arguments for and against using assembler.

On the one hand are the arguments against the use of assembler in large part prejudicial, on the other hand are the arguments for the use of assembler relatively unknown. When you do know the prejudices against assembler without knowing the advantages, it becomes very hard indeed to take any objective decisions concerning the choice of programming language.

One rule remains important - as it does for any programming language: without well-trained people you'll never get anywhere, without proper documentation you'll end up not even knowing where you are.

Below you will find an overview of the most important advantages of assembler. Thereafter we will try to shade the prejudices. We then end with a short summary.

The advantages of assembler.

Working with assembler offers you a range of capabilities, which are not (all) available for 3GL- of 4GL-programmers.

• Parry errors.
  How often does it happen your application falters over something ever so simple? A S0C7-abend because there were spaces, where zeros were expected? An intermediate dataset that was allocated just a little too small? With the help of a relatively simple assembler-routine these problems can be parried and solved. Your application no longer falters, it just keeps on running. All problems encountered are reported either in the joblog or in a separate error log, enabling the controller in command to take any required actions.
• Usage of memory above the 16MB-line.
  Enterprises still can be found, that (are forced to) compile with Amode=24. By adding small assembler modules you can have your application programs run above the 16MB-line, easing the pressure on memory below the 16MB-line where it is most severely felt.
• Dynamic memory management.
  Programs that maintain data in tables, lists, or trees often do not know in advance how large these objects will have to grow. In assembler storage can be allocated and de-allocated dynamically, enabling you to grow or shrink your in-storage objects to the required size.
• Optimization.
  State-of-the-art compilers certainly do generate efficient code. They cannot, however, decide which optimizing criterion is of primary importance in any one of your specific programs. Because a programmer does have knowledge of the structure of your application, he can make that decision. He may for example choose to reduce the risk of page-steal, making the program run faster and reducing the pressure on the paging subsystem.
• Usage of operating system facilities. Many such services are not available from high-level languages, or when they are available, the overhead incurred by the high-level language's invocation of these services largely overshadows the performance benefits one would otherwise enjoy.
  Amongst others one might think of:
  • Data spaces.
    Programs that need large amounts of working storage might well make use of data spaces. This reduces the need for allocating work datasets (which in turn reduces I/O) and at the same time saves on virtual storage within your own address space, reducing the risk of out-of-storage abends.
  • Virtual look-aside facility.
    VLF enables you to keep named data in virtual storage, outside of your own address space. For heavily used data that can be named (eg PDS-members in certain datasets) this can substantially reduce I/O-delays for your application.
  • Concurrent access to several datasets.
    When an application needs access to records from two or more datasets, these records can be read and/or written at the same time. It is even possible to access several records within a single dataset at the same time. This concurrency can save considerably on I/O-wait time, especially when the datasets involved are on different volumes.
  • Subtasks.
    By splitting one or subtasks off a task, that task can be sped up considerably. E.g. by eliminating the need to write data to a work-dataset. Or by leaving it to a subtask to create the required financial journal records, meaning that the sales-transaction itself can be handled that much faster.
  • Reenterability.
    By making heavily used program segments reenterable they can be placed in common storage (by preference above the 16MB-line of course). This means that all programs using that code can be executed more efficiently, because the chance of a page fault in such a piece of code is minimal.

The prejudices against assembler.

There are several prejudices against working with assembler. The most important ones are:

1. In assembler structured programming is impossible.
   This is untrue. In this area assembler actually offers more facilities than most 3GLs.
2. Maintaining assembler programs is vastly more costly than maintaining 3GLs.
   When 3GLs were introduced this may have been true. Now however, this statement is highly debatable.
3. Assembler is a cumbrous language, and hard to learn.
   Assembler is indeed a little less readable to the layman than e.g. Cobol. Such languages as C and C++ on the other hand are more difficult to master.

Ad 1.

In assembler structured programming is impossible.
Bringing structure into programs is first and foremost a matter of style and craftsmanship. If the programming language in use offers good facilities in this area, that can be an aid, but no more than that.

• In the area of program segmentation assembler offers more possibilities than 3GLs: next to the usual making of subroutines or functions it is also possible in assembler to divide programs up into CSECTs, which in turn can be subdivided again into subroutines and/or functions.
  On top of that, one can choose from a diversity of calling mechanisms. Amongst them are standard MVS-linkage through register 14, the linkage stack, or other calling mechanisms, with or without use of a jump-table.
  For passing parameters finally, one can choose between pass by value, pass by reference, or a mixture of these.
• As far as loop-control is concerned, assembler offers facilities comparable with 3GLs: these are the so called branch on index and branch on count instructions. With the help of macros the facilities can be extended with more powerful instructions.
• Just like most 3GLs assembler features copying standard code from a library member into your programs.
• The macro-facility finally offers a wide variety for bringing structure into programs and for standardizing routinely occurring program constructs. By using conditional assembly it is always possible to optimize the code to be generated. Most 3GLs offer no comparable functionality.
   
  

Ad 2.

Maintaining assembler programs is vastly more costly than maintaining 3GLs.
When 3GLs were first introduced there was a vast base of existing assembler programs. Because structured programming was a relatively new phenomenon in those days, these programs often left a lot to wish for as far as structure was concerned. In assembler - as in any other language - you can create as much or as little structure as you want. With all the usual consequences for their maintainability.
In assembler you do have more opportunities than in most 3GLs to make a mess of things. Thanks to the macro-facilities, however, you also do have a considerable number of extra options for bringing structure into your programs, as compared to other languages.
 
Furthermore the matter of craftsmanship is of primary importance. A 3GL-programmer also "doing some assembler" can never measure up to the professional assembler-programmer. The effects are measurable not only in the time required to get the job done, but also in the quality of the code produced. The main problem, then, is how to get experienced professionals on your team. A problem you will encounter anyhow, whichever the programming language of your choice may be, especially under current conditions.
 
So, if we do want to make a fair comparison for required manpower between assembler and 3GLs, we will have to compare craftsmen with craftsmen, and we will also have to take the age of the programs (read: measure of structure) into account, as well as the quality of the available documentation.
 
Our experience for new programs is, that you will need some 10 to 20 percent extra manpower for working with assembler. When maintenance is concerned, the differences are too dependent on the availability of documentation and on the amount of structure in the programs to give any meaningful figure.
 
An example: one of our customers owns both an assembler module, which was created by us, and a Cobol module. They both do exactly the same thing. For the last few modifications the assembler-programmer was ready in one day, whereas the Cobol-programmer needed a three days. Though this may seem exceptional, it proves that maintenance on assembler programs is not by definition more costly than maintenance on 3GL-programs.
 

Ad 3.

Assembler is a cumbrous language, and hard to learn.
If you are dependent on "laymen" you should certainly not choose to use assembler. As with any other language you would only be creating your own difficulties.
Of course there also are skilled craftsmen around. These do not only master the skills of assembler-programming, they also have a thorough knowledge of the macro-facilities the assembler-language offers. This enables us to code swiftly, efficiently, and neatly.

Summary.

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

• Working with assembler takes a little more time, though not as much as people are wont to think.
• Assembler offers more facilities for structuring, even though lacking craftsmanship will bring on maintenance problems more easily.
• In assembler one has more possibilities for solving or preventing performance problems.
• It takes some extra effort to find or train professionals.

Taking it all together, our standard advise is: do not use assembler when there is no need to. On the other hand, if you have good reasons to do so, don't shy away from it; assembler is not frightening. And if you do choose to use assembler, use it only for those modules that will benefit from it. The largest part of your application is probably best built in your favourite 3GL of 4GL.

Lastly, for some applications it simply is impossible to use any language but assembler. This holds specifically for most exits.
Not only the operating system, but also a good many standard products are endowed with exit points, to enable installations to adapt the software to their own requirements. For most exits coding in assembler is simply unavoidable. With the arguments given above this should (no longer) raise any insurmountable problems.

This site is a member of WebRing. You are invited to browse the list of mainframe-loving sites.		Dinos are not dead. They are alive and well and living in data centers all around you. They speak in tongues and work strange magics with computers. Beware the dino! And just in case you're waiting for the final demise of these dino's: remember that dinos ruled the world for 155-million years!
Dinos and other anachronisms [ Join Now | Ring Hub | Random | << Prev | Next >> ]

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

To the English Homepage.
To the general Homepage.

This text was written by A.F. Kornelis
© Copyright: A.F. Kornelis, 1997-2003. All rights reserved.
e-mail the author.

Below you find the logo of our sponsor and logos of the web-standards that this page adheres to.