392 Part 4 The instruction-set processor level: special-function processors
Section 4 Processors based on a programming language
The total compiler microprogram space is therefore approximately 500 ROS words. The total main storage space required is approximately 1200 bytes.
The speed of this compiler is limited by the speed of the card-reader of the system (1000 cards/minute). This excellent performance has three main reasons: (1) EULER as a simple precedence language is a language extremely easy to compile. (2) The functions of a compiler are mainly of a table lookup and bit and byte-testing type. Microprogramming is extremely well-suited for these kinds of operations. (3) Since the target language is String Code and not, for example, 360 Machine Language, the generative part of the compiler is relatively short.
It is very difficult to assess the individual contributions of these three main reasons to the high compiler performance. Therefore, it is not possible at this stage to make a statement as to whether the nature of the language EULER or the fact that the compiler is microprogrammed is the dominant factor.
Development of the microprogram
Since there is no higher level language to express microprogram procedures and no compiler to compile microcode, the microprograms were written in the symbolic language explained in Fig. 6. Actually the process was a hand translation of the algorithms in the EULER definition to the symbolic microprogram language. The microprograms were translated into actual microcode and simulated before they were put on the System/360 Model 30 by means of a general microprogram development system.
Outlook and general discussion
It is hoped that the development of this experimental system for EULER shows that with the help of microprogramming we can create systems for higher level languages or special applications, which utilize existing computer hardware to a much higher degree than conventional programming systems.
Among the thoughts which are raised by this scheme are the following:
1 There should be an investigation to determine the ideal directly interpretable languages which correspond to higher level languages. Although several attempts have been made to define string languages for interpretive systems (for instance in Wirth and Weber [1966a and 1966b] and Melbourne and Pugmire ), to the author's knowledge no work has been published which attacks this question in a general and theoretically founded manner.
2 A proliferation of interpretive languages and the development of microprogrammed interpreters can be justified when better tools are developed to reduce the cost of microprogramming. It is necessary that we be able to express microprogramming concepts (and also machine design concepts) in a higher level language form and that we develop compilers which translate the microprograms from higher level language form to actual microcode. Also, good microprogram simulation and debugging tools are called for.
3 The whole relationship between programming, microprogramming, and machine design should be viewed with a common denominator: how should the tradeoffs be made such that the ultimate goal can be reached more effectively, . . . how to solve a user's problem? Green  offers some thinking in this direction but the state of the art has to progress further before we will have a complete understanding of what these relationships and tradeoffs are.
WebeH67; FaggP64; GreeJ66; HainL65; MelbA65; WirtN66a, 66b; FORTRAN Specifications and Operating Procedures, IBM1401, IBM Systems Ref. Lib. C24-1455-2.