- Email: [email protected]
The potential of microprogramming techniques
Light Pen
The potential of microprogramming techniques It is well known that the relative costs of hardware and software are changing rapidly with time - hardware costs have fallen very considerably over the last five years or so as a consequence of technological development - especially in the minicomputer area. On the other hand, software costs are rising slowly with time, as consequences of inflation and the increasing complexity of systems. These two effects in combination are resulting in the design of systems which are hardware-intensive rather than software-intensive. In the USA, there has been considerable accent on hardware-intensive systems for some time, owing to the relative costs of equipment and labour in that country. Until now this has contrasted with a software-intensive approach in the UK, where the emphasis has been largely on getting the maximum use out of a particular given investment.
Hardware versus software At a more detailed level, another technological development is causing the trend mentioned above to lead to advances in a particular direction. In the minicomputer area, there is now a clear trend towards the migration of basic software into hardware form, in the form of microprogram. In particular, one small system now has an executive in completely hardwired form; in this case designed into the monolithic structure of the control circuits. However, there is no reason why it should not be separated out as a particular, modular microprogram component. Other small computers now have compilers in hardwired form, particularly for the BASIC language. Other similar hardwired modules will almost certainly appear for other high level languages, and probably later for communication functions. The latter
must necessarily await the next round of standardization - line control protocols such as HDLC and SDLC and higher level protocols - already mentioned in Light Pen.
0.2 of a microsecond). As mentioned above, such modular subsystems are particularly suitable for uses which entail frequent iterations through a predetermined set of instructions, with few branches.
Microprogram as a subsystem Graphic operations Hardware for the handling of microprograms normally takes one of three forms. Traditionally, the microprogram in a large processor was designed into the processor by the logical designers at the time of design. For example, the Atlas computer had a read only memory consisting of ferrite pegs inserted into an array of sensing circuits. Most of the familiar third generation data processing computers in use today have microprogram arrays backing the basic arithmetic units, the resultant combination providing a greatly enlarged order code. However, as outlined above, a microprogram is now emerging as a discrete component or subsystem, and being used for purposes other than the extension of an order code. The second form of microprogram will be familiar to many - this involves providing a number of routes through a hardware array of passive or active devices - the route taken is determined by removing links selectively before the modular unit is used. Some minicomputers already have such microprograms - redundant links being removed by simply fusing them i.e. passing an excess current through them. The third form of microprogram is based on the use of Programmable Read Only Memories (PROM's) which can store, normally on a rather slow cycle, microprogram instructions before a particular computer is brought into operation, that is, each day, or after being switched off. Once stored, such PROM instructions can be read very rapidly, typically with an access time of 1 - 2 0 0 nanoseconds (0.1 or -
A microprogram has several potential uses in the design area. For example, most graphic systems require frequent use and iteration through specific subroutines, for example, the routines responsible for rotating a 2-dimensional presentation of a 3-dimensional object. Other frequently used operations include such graphical functions as scissor, magnify, reduce and blink, together with the generation of special figures such as circles, and other conic forms via hardware. Microprogram techniques therefore have considerable potential applications in the c.a.d. field.
Standardization There is, however, one fundamental question still not determined. This is one which again has been raised on many occasions by Light Pen, namely, that of standardization. If microprogram is standardized ahead of requirements in such a way that plug-in units can be interchanged between manufacturers' equipment, then a considerable amount of effective use will be obtained from investment in that area. If, on the other hand, a number of very widely differing implementations (in detail) of similar functions occur, then investment will be increased, and the effectiveness of the technique dissipated. This is a technology which should attract the attention of those responsible for national policies, and international standardization.
The potential of microprogramming techniques It is well known that the relative costs of hardware and software are changing rapidly with time - hardware costs have fallen very considerably over the last five years or so as a consequence of technological development - especially in the minicomputer area. On the other hand, software costs are rising slowly with time, as consequences of inflation and the increasing complexity of systems. These two effects in combination are resulting in the design of systems which are hardware-intensive rather than software-intensive. In the USA, there has been considerable accent on hardware-intensive systems for some time, owing to the relative costs of equipment and labour in that country. Until now this has contrasted with a software-intensive approach in the UK, where the emphasis has been largely on getting the maximum use out of a particular given investment.
Hardware versus software At a more detailed level, another technological development is causing the trend mentioned above to lead to advances in a particular direction. In the minicomputer area, there is now a clear trend towards the migration of basic software into hardware form, in the form of microprogram. In particular, one small system now has an executive in completely hardwired form; in this case designed into the monolithic structure of the control circuits. However, there is no reason why it should not be separated out as a particular, modular microprogram component. Other small computers now have compilers in hardwired form, particularly for the BASIC language. Other similar hardwired modules will almost certainly appear for other high level languages, and probably later for communication functions. The latter
must necessarily await the next round of standardization - line control protocols such as HDLC and SDLC and higher level protocols - already mentioned in Light Pen.
0.2 of a microsecond). As mentioned above, such modular subsystems are particularly suitable for uses which entail frequent iterations through a predetermined set of instructions, with few branches.
Microprogram as a subsystem Graphic operations Hardware for the handling of microprograms normally takes one of three forms. Traditionally, the microprogram in a large processor was designed into the processor by the logical designers at the time of design. For example, the Atlas computer had a read only memory consisting of ferrite pegs inserted into an array of sensing circuits. Most of the familiar third generation data processing computers in use today have microprogram arrays backing the basic arithmetic units, the resultant combination providing a greatly enlarged order code. However, as outlined above, a microprogram is now emerging as a discrete component or subsystem, and being used for purposes other than the extension of an order code. The second form of microprogram will be familiar to many - this involves providing a number of routes through a hardware array of passive or active devices - the route taken is determined by removing links selectively before the modular unit is used. Some minicomputers already have such microprograms - redundant links being removed by simply fusing them i.e. passing an excess current through them. The third form of microprogram is based on the use of Programmable Read Only Memories (PROM's) which can store, normally on a rather slow cycle, microprogram instructions before a particular computer is brought into operation, that is, each day, or after being switched off. Once stored, such PROM instructions can be read very rapidly, typically with an access time of 1 - 2 0 0 nanoseconds (0.1 or -
A microprogram has several potential uses in the design area. For example, most graphic systems require frequent use and iteration through specific subroutines, for example, the routines responsible for rotating a 2-dimensional presentation of a 3-dimensional object. Other frequently used operations include such graphical functions as scissor, magnify, reduce and blink, together with the generation of special figures such as circles, and other conic forms via hardware. Microprogram techniques therefore have considerable potential applications in the c.a.d. field.
Standardization There is, however, one fundamental question still not determined. This is one which again has been raised on many occasions by Light Pen, namely, that of standardization. If microprogram is standardized ahead of requirements in such a way that plug-in units can be interchanged between manufacturers' equipment, then a considerable amount of effective use will be obtained from investment in that area. If, on the other hand, a number of very widely differing implementations (in detail) of similar functions occur, then investment will be increased, and the effectiveness of the technique dissipated. This is a technology which should attract the attention of those responsible for national policies, and international standardization.