previous | contents | next

Chapter 32 A microprogrammed implementation of EULER on IBM System/360 Model 30 383

which interprets 360 language texts. It consists of a recognizing part to read the next consecutive string element and to branch to an appropriate action routine and of action routines to execute the particular procedure called for by the string element.

The essential difference between our situation and the 360 case is that the string language reflects the features of the particular higher level language as well as the features of the particular hardware better than the general purpose 360 language.

What is gained by defining this string language and by providing a microprogrammed interpreter for it? From the method of definition described, it can be seen that the elements of the string language correspond directly to the elements of the higher level language after all simplifying data-invariant and flow-invariant transformations have been performed. But the elements of the string language are also well-adapted to the microprogram structure of the machine. Therefore, during the compiling process (see Fig. 2) only a minimum of generation is necessary to produce the string language text. The compiler is shorter and runs faster.

But the more important aspect is that object code execution is also faster. The string language interpreter in case 2 will be coded to take care of all necessary operations in a concise form, whereas in case 1 it will be necessary to compile a whole sequence of machine language instructions for an elementary operation in the higher level language. Examples of this are the compilation of 360 code for an add operation in COBOL of two numbers with different scaling factors or the compilation of machine instructions for table lookup or search operations, etc. In these cases the string language interpreter of Fig. 2 will execute a function much faster than the machine language interpreter of Fig. 1 will execute the equivalent sequence of machine language instructions. Therefore, object code execution will be faster in scheme 2.

If object code performance is not as much in demand as object storage space economy, the string language interpreter can also be written such that the string language is as tightly packed as

Fig. 2. Processing programs written in higher level languages via translation to interpretive language.

possible so that the translated program is as compact as possible and will take up less storage space than the equivalent machine language program under the scheme of Fig. 1.

These ideas are applied in an experimental microprogram system for the higher level language EULER [Wirth and Weber, 1966a and 1966b] described below. Problem areas in this approach are indicated and some ideas for future development are offered.

Special considerations for EULER

The higher level language EULER [Wirth and Weber, 1966a and 1966b] is a dynamic language. This means that for programs written in it many things have to be done at object code execution time which can be done at compile time for other languages. EULER also contains basic functions which do not have comparable basic counterparts in the machine languages of most machines. To compile machine code for these dynamic properties and for those special functions would require rather lengthy sequences of machine language instructions, which would consume considerable object code space and require high object code execution time. Therefore, for a language like EULER, interpretation at the string language level by an interpreter into which the dynamic features and special functions are included by microcode will yield much higher object code economy and object code performance than compilation to machine language and interpretation of this machine language.

Three examples from EULER are given here.

1. Dynamic type handling. To a variable in EULER, constants of varying type can be assigned dynamically. For example in

A¬ 3; . . .; A ¬ 4.510-5; . . .; A ¬ true; . . .; A ¬ ' . . . ' ;

the quantities assigned to the variable A have the types: integer, real, logical, procedure. Therefore, in EULER each quantity has to carry its type indicator along and each operator operating on a variable has to perform a dynamic type test. The adding operator + for instance in A + B has to test dynamically whether both operands are of type number (integer or real). This type testing is done by the String Language Interpreter in minimum time, whereas it would require extra instructions if the program were to be compiled to 360 machine language.

2. Recursive procedures and dynamic storage allocation. In EULER, procedures can be called recursively, e.g.,

F ¬ 'formal N; if N = 0 then 1 else N * F(N - 1)';

previous | contents | next