The Share 709 System: Input-Output Translation

Abstract

The 709 System Committee agreed from the start that the system, to be complete, should contain some provision for input and output translation at the program execution or customer level. The big problem was to specify a translation system that every 709 user could and would want to use. In contrast to assemblers, compilers, debugging systems and operational systems which are designed to simplify programming and to make a complete computing operation run smoothly, an input-output system must, in addition, facilitate the work of the data originator, the keypunch operator, and the person who analyzes the results of a computation. In specifying such a system there were many questions to be answered:

• Should a general input-output scheme conserve space to the utmost or should execution time be the primary consideration?

• Should the concept of symbolic reference which so characterizes the rest of the SHARE 709 System be carried through to the customer level in terms of input and output?

• Should a general input program expect that data would be prepared in records with so-called fixed field formats where, for example, columns 12 through 15 of an input card might contain an integer to be scaled by 10^-6 and converted to floating binary? Or should it expect data in a variable field format where each item on the card is expressed in such a way that its length and type of conversion is expressly implied in the field itself?

Many of the answers depend upon the particular computing installation being asked—its past experience, its policies, and the components which will make up its particular 709. It was clear that one general input program and one general output program would not satisfy even a small fraction of the people who are to use the 709 system.

It was clear that one general input program and one general output program would not satisfy even a small fraction of the people who are to use the 709 system. The only common ground shared by these people is that they have real-world data such as alphabetic and decimal information which must be made available to a computer program in binary form and vice versa.

The only obvious answer to the problem then seemed to be the development of an automatic programming scheme which would render the job of writing a tailor-made input or output program a simple one. A programmer could then write his specifications concisely within the rules of the system. These statements would be interpreted by the automatic system which would, in turn, produce the desired input or output program. Therefore, a language consisting of macro-operations was developed to answer this purpose. The programmer precedes his descriptive macros with a linkage to the appropriate input or output translator. The compiler expands each macro into one or more words of machine code to produce a calling sequence to the appropriate translation routine. To add an additional degree of freedom, the programmer is allowed to intersperse machine language coding with his translation macros.

The available macro instructions are divided into four classifications according to the type of information they are designed to convey. They are: 1) conversion, 2) control, 3) transmission, and 4) modal. Each macro follows the same type of format as the normal 709 instructions. Following the operation code are four fields: Y, T, C and N; and each field is separated from the preceding one by a comma. The use of each field varies somewhat between macro classifications but in all cases the operation mnemonically states the type of information being conveyed by the macro.

For simplicity, we will discuss the macros only as they apply to input translation. In general, the operations are reflective for output; that is, conversion and transmission take place in the opposite direction and the term “card column” is replaced by “print position.”

The conversion macros convert binary coded decimal—or BCD—information contained in the input record to its equivalent binary form and store it in the designated memory location of the computer. The operation field of the macro designates the format of the input field to be converted and/or the form of the information after conversion. For example, the macro OCTAL tells the translator that the input field in question is an octal number to be converted to binary. The macro BCC implies that some number of binary coded characters are to be retained in their BCD form without conversion. Let us look more closely at the conversion macro FLOAT. OP Y, T, C, N FLOAT X, 2, 21, 11 It tells the input translator that the field to be converted is a decimal number of the form ±X.XXXXE ± YY where E implies that the value of ±X.XXXX is to be scaled by ten to the ±YY power. The resulting number is to be converted to floating binary and stored. The Y and T fields of the macro tell where this number is to be stored, with Y denoting the symbolic memory reference and T the index register to be used in modifying Y. Provision is also made for specifying whether Y is a direct or an indirect address. In our example, the number is to be stored in the location symbolically referred to as X minus the contents of index register two, C and N tell the translator where in the input record to find the field to be converted. C is the card column where the field begins and N is the number of columns in the field.

If C and N are given as zero, then it is understood that the position and length of the field are variable and that the necessary information is contained in the field itself.

Another important conversion macro is SYMEX which permits symbolic references to appear in the input records. A symbolic expression such as R/2 + 1 appearing in the input record is evaluated by finding the absolute value for R in the dictionary and then performing the necessary arithmetic. Note that this permits the use of symbolics throughout the entire SHARE 709 System—from the programmer in writing and debugging to the user of the completed program.

The second type, or control, macros are used within the interpretive scheme in much the same way that transfer and index register modification instructions are used in actual machine language coding. The macro JUMP is used to transfer control to another region of memory as specified in the Y and T fields. The contents of the C field tells whether or not control is to be retained in the interpretive mode at the new location. Another control macro, REPEAT, denotes that the next macro is to be repeated Y times. The T field contains the amount by which the index register used in the next macro is to be incremented for each repeated interpretation. In the same way C gives the increment of the card column number.

The transmission macros are used for bringing the next input record into core memory for subsequent conversion. The most important of this third classification is the macro SCRIBE. Only the Y field is used with SCRIBE and it designates the source of the input record—that is, a particular tape or the card reader.

An important feature of the input, or output, translator is effected by the use of the fourth, or modal, type macros. They allow the programmer to state only once the conditions under which his program is to operate.

He can establish with several statements in the form of modal macros his “MO”—to use the popular criminology term. He can specify such things as:

• what constitutes an error,

• what to do when an error is encountered,

• the location of the binary point in all of the data items that are converted to fixed point binary.

Each modal macro has a normal condition which applies at the initial entry to the translator and remains in effect until countermanded by the interpretation of a modal macro of that type. For example, the macro POINT specifies the number of binary places to the left of the binary point in all input items converted to fixed point binary and its normal mode is zero. If the programmer wishes to consider the point to be 12 places to the right of the standard case, he merely precedes his group of fixed point conversion macros with POINT 12. The modal macro need not immediately precede the affected operations; the only requirement is that it must be interpreted first. You will recall that the transmission macro SCRIBE did not specify the memory location to be used for the input record. The modal macro IMAGE contains this information in the Y and T fields and it applies to all subsequent uses of SCRIBE. Also, IMAGE tells the translator where to find the input record to be processed by the conversion macros. One of the error controls is effected by the use of the modal macro EOR. Here the programmer specifies in the C field the maximum number of columns that he will allow in an input record. Should a subsequent conversion macro call for a column number greater than this maximum, then control will be transferred to the location given in the Y and T fields of the EOR macro. The contents of the N field tells whether or not control is to be retained in the interpretive mode after the transfer takes place.

Similar use of the fields of the CHAR macro allow the programmer to state what he wishes to do when blanks or illegal characters appear in the input record to be converted. The modal macro RESET returns all modes to their normal conditions.

To illustrate the simplicity and conciseness of specifying a program in the language of the input translator, we chose a rather difficult routine called the Data Sentence Program. The input record which this program accepts is, as the name implies, a sentence as follows: XBAR + 4 = 17.25, .5, 8.125, 7.3^*. The subject of the sentence is, to the person preparing the data, the name of the first data item. To the input program the subject is the symbolic reference to the memory cell where the first data item is to be stored. The verb is an equals sign which signifies to the program the end of the symbolic memory reference. The object of the sentence denotes the numeric values to be assumed by the subject and each value is separated from the preceding one by a comma. The sentence is terminated by an asterisk and is analogous to the period at the end of a grammatical sentence. Each data item in the object of the sentence contains some identification within itself to indicate the type of conversion to be performed. In our example, the four numbers 17.25, .5, 8.125, and 7.3 are to be converted to floating point binary as indicated by the presence of a decimal point within each item. They are to be stored in four consecutive memory cells beginning at the location represented by the symbolic expression XBAR + 4. The complete program for interpreting and reading any such input record was specified in only 38 operations. Of these 38, there were 2 conversion macros, 5 control macros, 3 transmission macros, 4 modal macros, and 24 instructions were actual machine language coding.

It is estimated that from 400 to 500 instructions would be required to write the same program in actual machine language coding without the input translator.

The questions pertaining to the external features of an input-output translation system have thus been answered by the development of translators governed by the use of macro instructions written by the programmer. But the question of the internal characteristic—space versus time—still remained. This is indeed an important consideration in using the 709. There are within the logic of the computer several instructions which perform BCD-to-binary, or binary-to-BCD, conversion in only a few machine cycles, but these instructions require very large tables of values with which to make the conversion. The size of the core memory or the mode of operation within a given 709 installation will determine whether or not this feature can be economically utilized. Therefore, this final problem was solved by writing the necessary parts of the input and output translators in two ways—one to save space and the other to save time by using the convert instructions. Thus, each installation can use the version of the translators which best serves its own individual needs.

Index Terms

• Computer systems organization

• Software and its engineering

  • Software organization and properties

    • Contextual software domains

      • Operating systems

        • Communications management

          • Input / output