Special Section on Microprogramming

Abstract

This special section focuses primarily on high-level language concepts applicable to microprogramming. The notion of "microprogramming" is best explained in terms of more familiar levels of programming. Let us identify the configuration of the hardware system as the /0 level. Machine language programming (or "assembly language" coding) is at the/2 level. In between, at the ii level, is the specification of instructions that serves to extend the existing hardware instruction set. Instructions written at this level provide a set of language commands, used by i2-1evel programmers, that are expected to execute in time frames typically identified with the initial hardware system. Thus, microprogranuning lies somewhere between hardware and software, and is often dubbed "firmware."While we have made a great deal of progress in language designs for the various levels at which programming is done, there is insufficient discussion of optimization techniques and specification techniques for programming at the /o and il levels. One would assume that microprogrammed control and writable control stores would afford architects the opportunity to design hardware configurations that are innovative and suitable for specification techniques, such as iteration and conditional control structures, typical of high-level programming languages. But very little has actually been done in this regard. Microprogramming continues to be a convenient form of implementing traditional hardware configurations.The form in which microprogramming is carried out is also quite traditional, despite the usual arguments against bit-level coding and the horrendous nature of the postcoding deciphering task. A number of new approaches to the design of microprogramming languages are needed. For example, some of the parallelism which exists in microprogramming must be handled in ways other than the concurrency techniques presently available in higher level programming systems. In particular, microprograms must rigorously enforce controlled timing constraints. Register transfer operations are at the very heart of microprogramming, but only some hardware de-scription languages contain appropriate commands for carrying out these operations. The search continues for a language that lies somewhere between a specialized hardware description language and the familiar problem-oriented languages.New techniques are also needed for microprogram compilers. The microinstructions generated must be optimized in their use of space (i.e., to minimize the number of microinstructions) and in their associated execution times. Microinstructions typically consist of fields specifying two functions: control register transfer operations within the central processing unit, and next-address computations (toggles and flags) found within the microprogram control store. These second operations occur independently of the register transfer operations. The two papers presented in this special section deal primarily with the use and improvement of register transfer operations.