LOADERS ... We have talked about compilers, assemblers, source programs, and object programs. How do these programs get into the machine? One (horrible) alternative is for an operator to load the binary instructions through the console of the machine, one word at a time by setting switches or entering them through a small calculator-like keyboard. Preferably, the program could be punched onto paper tape or cards before hand and then simply read into the machine. The capability to "read" a program into memory requires that another program already must be in memory to cause the reading to take place! Such a program, called a "loader," must include all of the many detailed instructions required to read a card, for instance, and then move all of the 80 characters or other binary information read from the card into designated locations in memory. In fact, all input and output operations are fairly complicated at the machine language level and the manufacturer usually provides "utility" programs so that the programmer doesn't have to write these himself. For the same reason, a "Library" of other useful routines is generally available including such things as math functions. SYSTEMS SOFTWARE... Compilers, assemblers, loaders and utilities are collectively referred to as "systems software" and are usually written by the manufacturers "systems programmers". The using programmer is, in contrast, referred to as an "applications programmer" and his "applications programs" are the programs written to solve the user's problem. Starting with a program written in BASIC, there are many steps required before the output is available. First, a loader must be in the machine. (Loading the loader is itself a job to be done by the operator!) Then the BASIC compiler can be loaded in, the source program read, and the translated object program produced as output. Now the object program is read in (again by a loader) and then executed producing the final results. Input/output utilities and math routines may well have been required and loaded in along with the object deck. The smallest mini (or micro) computers are often operated in just this fashion, with the operator handling many separate programs and manually controlling the sequences of loading and execution. This job, too, is one in which the computer can lend a hand. OPERATING SYSTEMS . . . The most important of "systems" programs is one called an "operating system" (sometimes "executive," "monitor," "control program") which takes over these tasks of scheduling, allocating space in memory, calling other systems programs, etc. With an operating system (OS), the using programmer can simply state the kind of job he wants to do (using a special "job control language" requiring a card or statement of the beginning of his program), and the OS will handle many of these details for him. Here, then, we have another form of computer language, that which is used to talk with the operating system. With an OS in control of the computer, our sequence of events is simplified. The source program deck, written in BASIC, together with a job control card, may be all that the user must place in the input card reader. After reading the job control card, the OS will call in the BASIC compiler (probably stored on a disc file), load it, translate the source program to a machine language program, load the machine language program together with all required utility and ** 'Hardware math instructions are normally limited to add, subtract, multiply, and divide. Trig functions, square roots, etc , require programs that compute these higher math functions using the basic instructions. ** Library programs, and finally execute the object program. What we have described here can be called a "Compile-and-Go" scheme, in which the system does not have to stop between the translation and execution phases. INTERPRETERS . . . Our brief tour of systems software has omitted one important type of program, the "interpreter," which is particularly important to BASIC users. The use of a BASIC compiler to first translate a BASIC program into machine language for later execution is one method available for the BASIC user to execute his programs. It may be the only method, depending on the computer and its available systems software. Frequently, however, a BASIC interpreter may be available to execute BASIC programs, either in addition to a compiler or in place of it. An interpreter differs from a compiler in one major area: an interpreter does not translate the source program, but rather it effectively executes it directly. Each line of a BASIC program is examined by the interpreter to determine what actions will be required to execute (or, more accurately, evaluate) the statement. The interpreter then performs those actions by immediately executing the appropriate portions of its own program, and then moves on to the next source BASIC statement. This is in contrast to the compiler process in which the entire BASIC program is translated to a unique set of machine language instructions which are then executed after the compiler has finished its job. To illustrate how the two systems differ, let's consider how they would process the BASIC statement: LET X = 2+3 A compiler would produce as its output a machine language program consisting of several instructions, which when executed later would calculate the desired result and assign it to the variable X. An interpreter, on the other hand, would produce as its output the new value of X which is 5; no instructions or new program would be produced by the interpreter. What differences does the user see between a compiler and an interpreter? Not many. Both methods ultimately produce the same end results. If the program is to be executed many times, there is a benefit to using the compiler method; in this method, it is possible to obtain a copy of the object program produced by the compiler, on punched cards or tape for instance. Then when the user [image] "Where did you learn to debug a program, HaverStraw?"