PROGRAMMING MICROMACHINES

in this decade microprocessors, and the components around them with which are built either a microcomputer or a microprocessor- -system have led us to flourishing area in the application

field. We do not want to summarize either the new applications or the new products, but to discuss them from a programming

standpoint.

Microprogramming and micromachine programming have one feature in common and this is ROM or PROM-programming: the program pro­

duced is placed (burned) into a ROM or PROM and no further

change is available in the case of a ROM, while a limited number of rewriting possibilities exist in the case of PROM-programs.

Due to this fact the classical model of the programs and data in the same memory cannot be applied further, because these should be divided into two parts: control-section for programs and mostly registers, RAM's to store data.

New and important problems arose from the rapidly growing appli­

cation fields and the variety of components in the micromachines.

Some of these problems are

- during micromachine des i on the formerly applied desi g n -technol­

ogies cannot be used, because the hardware and software and the "supervisors" should be designed together - hence a

unified technology would be needed: the systemdesing technol­

ogy.

are necessary: one for the hardware and one for the software.

Generally these are based on different tools; hardware-devel­

opment tools are based on compatible components, software- -developing tools are based on incompatible computers. Conse­

quently the programs produced by crossassemblers or cross- -compilers (even if they were carefully tested) are not di­

rectly those which were required, because the requirements and the programs are expressed on another computer by a (pos­

sibly high-level) programming language. Hence it follows that system-deveI o ping tools are needed to develop both programs and microcomputers. The industry recognized this problem at an early stage.

- It would be another variation of the same theme to discuss the question of whether we really need isolated system-design and system-developing tools or not: it is possible either to integrate or to realize them in the same way.

- in micromachine applications the application-field requires a special architecture to be tailored. Here by the word

"architecture" we mean both hardware and software. A small change in these requirements would disturb the special archi­

tecture and a tremendous amount of man-power would be wasted.

To avoid this role of modular and structured programming prin­

ciples is more important here.

In order to solve these problem, the tools now available are - higher-level languages (both macro- and algorithmic languages) - verification-oriented languages

- program-developing kits

- modular design and developing tools

- structured (micro) programming technology

nents of larger computer systems have been of growing importance.

The main problems in this issue are merged from the problems of both microprogramming and microprocessor-programming, and on the other side the advantages of these two lines are summed up. Most of the open problems can be derived from this application-area, hence it - as a paradigm - reflects the nature of questions to be solved.

To illustrate this let us assume that a microprogram-memory word is given divided into different fields: F. , F F

1 2 n

processing level

fieId-interpreter microprocessors

which are interpreted by an appropriate set of (possibly dif­

ferent) microprocessors with their own memories M. Bit-sliced microprocessors are designed to realize these sorts of central processings units or processing elements. From a programming point of view we can see that the programming of the field- -interpreter microprocessor leads us to those problems which are listed in Section 2 and programming this processing unit or element leads us to the problems in Section 1.

the problems of parallelism and synchronization on the level of microprocessors but not on the processing-level.

A new problem is that the architecture of microprocessors more or less determines the programming-I eve I arch i tecture. The number of bits in a register, the number of shared synchronization com­

ponents etc. are such features of microprocessors, so that sometimes in order to build up a processing unit there is only one possible solution, and to design a significantly different architecture for other purposes is almost impossible. These statements are not valid at the processing level because the

"micro-orders" (i.e. the contents of the fields) can be differ­

ent in order to reflect the problems in applications.

Due to this fact the reconfiguration principle (i.e. the dynamic changes in the interrelation between the microprocessors in

question) can be realized. Consequently the microprograms on the processing level should be written in such a way that either they are (more or less) invariant against these reconfigurations, or they have the available control structure as a "parameter".

The higher-level microprogramming language approach supports the methods for the first case, but for the second today's pro­

gramming principles are not enough.

In this conference we shall see some results in this direction.

What we really need are microprogram and microprocessor-pro­

gramming design and development tools integrated with the other components as a system design and development tool.

1. C.Boon: Computer Design. Infotech State of the Art Report, 1974.

2. P.M.Davies: Readings in microprogramming. IBM Syst.

Journal vol 11 nol pp. 16-40 (1972).

3. M.J.Flynn, M.D.MacLaren: Microprogramming revisited, Proc ACM National Meeting, pp. 457-464 (1 9 6 7).

4. M.J.Flynn, R.F.Rosin: Microprogramming; and introduction and a viewpoint. Transaction on Computers

vol C-20 no 7 pp. 727-731 (1971).

5. V.M.Gluskov: Automata theory and formal microprogram transformation. Cybernetics vol 1 no 5 pp. 1-9 (1 9 6 5).