Now let's look at the major failing of higher level languages. In attempting to achieve machine independence and to be applicable to a wide range of applications, they only give you acess to a fraction of the capabilities of your computer. If you compare the number of loop control instructions on your computer to the number of loop constructs in your language, you'll see what I mean.
Let me indulge in a 1 sentence characterization of 3 popular languages to illustrate their restricted capabilities:
FORTRAN is great at evaluating complicated algebraic expressions. COBOL is great at processing packed decimal data. ALGOL is great at providing loops and conditional statements.
Each language can be very efficient at its sort of job. But if you want conditional loops involving complicated decimal expressions you have a problem.
We are going to be concerned with efficiency. We are going to do some things that if we don't do efficiently, we can't do at all. Most of these things will not fit in the framework of a higher level language.
Some will; others will demand controlled use of the hardware that a compiler doesn't permit. For example, upon entering a FORTRAN subroutine it may save the registers it uses. If you didn't need to save them you've wasted time and space. An ALGOL subroutine may expect registers available that you have reserved; then you have to save them. It may well cost you more effort to interface with the compiler than it saves you in return.
Moreover, none of these languages are very good at moving things around. Most statements are data transfers count them in your latest program. There is a profound philosophical truth concealed in how much we can accomplish by moving numbers around. If we can move several things with one instruction, or put the same register several places we can't afford not to.
You will have to code in assembler! Not the whole program, if you insist, but the important parts that we'll be concentrating on. You might be able to do some of these in FORTRAN, but it simply isn't worth the effort. I'll show you where higher level subroutines can go, and I think you'll agree there is good reason to restrict them to that function.
I recognise the drawbacks of assembler and chafe at them as much as anyone. I don't like to punch and debug 10 times as many cards either. But I will in order to get the performance I need. By the way, I will use the word "compiler" to include assembler; we will compile an assembly language program.
Later I'll show you how to write a program in a forgotten language: machine language. By that I mean sitting at the console and entering absolute, binary instructions with the switches. Depending on the hardware and software available, and the nature of your application, it may just be the best language of all.