Chapter 30 ÷ A command structure for complex information processing 361
Fig. 9. Application of a data program to chess.
Conclusions
The purpose of this paper has been to outline a command structure for complex information processing, following some of the concepts used in a series of interpretive languages, called IPL's. The ultimate test of a command structure is the complex problems it allows one to solve that would not have been solved if the coding language were not available.
At least two different factors operate to keep problems from being solved on computers: the difficulty of specification, and the effort required to do the processing. The primary features of this command structure have been aimed at the specification problem. The authors have tried to specify the language requirements for complex coding, and then see what hardware organization allowed their mechanization. All the features of delegation, indirect referencing, and breakout imply a good deal of interpretation for each machine instruction. Similarly, the parallel program structure requires additional processing to set up CIA lists, and when a data symbol is designated, there is delegated interpreting through several words, each of which exacts its toll of machine time. If one were solely concerned with machine efficiency, one would require the programmer to so plan and arrange his program that direct and uniform processes would suffice. Considering the size of current computers and their continued rate of growth toward megaword memories and microsecond operations, it is believed that the limitation already lies with the programmer with his limited capacity to conceive and plan complicated programs. The authors certainly know this to be true of their own efforts to program theorem proving programs and chess playing programs, where the IPL languages or their equivalent in flexibility and also in power have been a necessary tool.
Considering the amount of interpretation, and the fact that interpretation uses the same operations as are available to the programmer; e.g., the save and delete operations, one can think of alternative ways to realize an IPL computer. At one extreme are interpretive routines on current computers, the method that the authors have been using. This is costless in hardware, but expensive in computing time. One could also add special operations to a standard repertoire to facilitate an interpretive version of the language. Probably much more fruitful is the addition of a small amount of very fast storage to speed up the interpreter. Finally, one could wire in the programs for the operations to get even more speed. It is not clear that there is any arrangement more direct than the wired in program because of the need of the interpreter to use the whole capability of its own operation code.
References
ShawJ58; BernA58; BrooF57b; KistJ57; NeweA56, 57a, 57b, 58
APPENDIX 1 c OPERATIONS (DESIGNATING OPERATIONS)
c Nature of operation for (a) = b c d e.
0 (a) is the symbol s.
1 d is the address of the symbol s.
2 d is the address of the address of the symbol s.
3 d is the address of the address of the address of the symbol s.
4 d is the address of the designating instruction that deter mines s.
5 d is the address (name) of a process that determines s.
APPENDIX 2 b OPERATIONS
b Nature of operation
SEQUENCE-CONTROL OPERATIONS
0 Stop interpreting; return to previous program structure.
1 Execute process named s.
2 Interpret instruction s.
3 Transfer control to location s.
4 Transfer control to location s, if signal is on.
5 Transfer control to location s, if signal is off.
6 Execute parallel program s; turn signal on if stops; off if not.
7 Continue parallel program s; turn signal on if stops; off if not.
8 Stop interpreting, if signal is on.
9 Stop interpreting, if signal is off.
10 Terminate.
11 Halt; proceed on go.
SAVE AND DELETE OPERATIONS
12 Save s.
13 Delete s (and everything for which s is responsible).