FMPC - Programming

Machine Language, Compilers, and Interpreters

The CPU of a given computer understands instructions only in its own language. Most computer systems support a variety of higher level languages by providing either interpreters or compilers to serve as intermediaries between the programmer and the CPU. Depending on the type of task that must be programmed, the programmer chooses the "high level language" that is most suited to that type of task. Some development environments provide their own program editing environments for the programmer to use to write the instructions out in the correct order, but in general the act of actually WRITING the program is most like that of using a word processor (and many dev environments allow you to substitute your favorite word processor for that function).

After the program is written in the high level language, one of two things will occur. If the program is interpreted it will be stored as a text file (possibly parsed, but that's beyond the scope of this document) and each time that the user wishes to execute it they must run the interpreter program. The interpreter program itself reads the source text file and translate it into appropriate instructions for the CPU, and feeds those instructions to the CPU for it to execute them. Interpreted programs must be translated to machine level instructions each time they execute, in general resulting in slower performance than for compiled programs. Most versions of BASIC, HyperTalk/SuperTalk, and Apple's Scripting language are generally interpreted (although compilers do exist for some of them).

If the program was written in a dev environment that will compile source files written in that language then a different process occurs. In this case, the compiler program performs a translation of the information contained in the source files into the appropriate machine language instructions that will perform these operations (including the bugs that we insert by accident), and writes an application file to the disk. This application file is now fully independent of the compiler and the source files, and may be executed independently of them at full machine level speed. Almost all commercially available software and shareware is compiled. A notable exception is that of HyperCard stacks.

Modular Programming and Parameters

The source code grows to be quite large for any significant programming project. Most programs may be logically broken into separate modules that each focus on some specific aspect of the overall program, and the programmer will usually write each of these modules (or related groups of modules) in a separate source code files. The C language itself has syntax that allows the programmer to 'call' a module from within another module simply by naming the desired module in the place that it is to be executed. All major C language development environments provide ways to manage the relationships among the various files that make up a program, and provide a 'linker' program to handle the task of resolving the 'calls' or 'references' between the various files when the program is actually built.

The various modules that constitute a C language program each perform some discrete action or set of related actions. To organize the overall flow of a program, the programmer provides a shell module that defines the highest level of flow of the program. This shell module (which must be called "main") is the one that will be executed when the user starts the program. The 'main' module will then call the first level of the other modules at the proper times, and each of them may further call other modules. It is up to the programmer to ensure that all modules that are called are actually provided to the dev environment when the application is finally built (either by being explicitly coded for the project or in libraries - see below).

The variables used in C language programs may be declared as either 'global' or 'local' in scope. Global variables may be used by any module written for the program. Local variables are only available within the module that defines them. If a module wishes to allow another module that it is calling to use the value of one of its local variables, the calling module passes the variable(s) to the called routine as a parameter. If the module wishes to allow the called module to modify the actual local variable ITSELF, the calling module passes a pointer (or a handle) to its local variable to the called module. Because the called module has a 'pointer' to the memory that holds the value of the original module's data, the called module may operate on the calling modules variable directly by operating on that section of memory.

Header Files

Most C language programs require the programmer to define a variety of structures to define the data that it will use. However, every module doesn't need to know about every data structure that is used anywhere in the program. Each module only needs to know about the constants, definitions, structures, arrays, unions, etc. that will be used within it. Some structures are used in more than one module, and it is difficulty to keep all definitions of a structure in sync if the definition of the structure is ever changed. For these reasons, it is convenient to the programmer to define each entity in their program only once, and then to copy that definition explicitly into those modules that need it. The C language facilitates this by supporting 'include files', or 'header files'.

Header files are used to hold the definitions of the structures, etc. that will be used by more than one module in a program. Simple syntax in the C language allows the programmer to specify multiple header files within a source module. Header files may be included within other header files, nested as deeply as necessary. Most C development environments support facilities to prevent the compiler from attempting to include the same header file twice in any specific compile.

Libraries

Some functions that a programmer needs to accomplish are common to many programs. The C language itself comes with a standard library of 'pre-written modules' that perform a variety of common tasks (such as formatting numeric values for printing or performing trigonometric functions). Other libraries are available both commercially and in the public domain that provide other desired functions. These modules are provided in 'object code', already compiled from their original source code and ready to be used in the final link.

The provider of any library will make appropriate header files available to the programmer for inclusion in any modules that call routines from the library. These header files define the names and parameters associated with each module of the library, and usually give additional tips on using the library.

The Mac OS and Toolbox can be seen as a collection of language independent libraries that offer additional capabilities to the Mac programmer who is willing to learn how to call their routines.

Copyright © 1996, 1997, 1998. Last Update to This Page: 1998/10/22
This Page Maintained by: radar pangaean * * * Original Author: radar pangaean
The MOST web site is built and maintained by the voluntary efforts/donations of our members.