bixoft.nl Open in urlscan Pro
136.144.185.168  Public Scan

Form analysis
0 forms found in the DOM

Text Content

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.