Microprogramming: History and Evolution - Edwardbosworth.com
Microprogramming: History and Evolution - Edwardbosworth.com Microprogramming: History and Evolution - Edwardbosworth.com
Microprogramming is Taken Seriously It was with the introduction of the IBM System/360 that microprogramming was taken seriously as an option for designing control units. There were three reasons. 1. The recent availability of memory units with sufficient reliability and reasonable cost. 2. The fact that IBM took the technology seriously. 3. The fact that IBM aggressively pushed the memory technology inside the company to make microprogramming feasible. IBM’ goals are stated in the 1967 paper by Tucker. ―Microprogramming in the System/360 line is not meant to provide the problem programmer with an instruction set that he can custom–tailor. Quite the contrary, it has been used to help design a fixed instruction set capable of reaching across a compatible line of machines in a wide range of performances. … The use of microprogramming has, however, made it feasible for the smaller models of System/360 to provide the same comprehensive instruction set as the large models.‖ Tucker notes that the use of a ROS [Read Only Store] is somewhat expensive, becoming attractive only as ―an instruction set becomes more comprehensive‖. Source: (Page 225 of Tucker, 1967)
Microprogramming is Taken Seriously (By IBM’s Customers) The primary intent of the IBM design team was to generate an entire family of computers with one ISA (Instruction Set Architecture) but many different organizations. Microprogramming allowed computers of a wide range of computing power (and cost) to implement the same instruction set and run the same assembly language software. Several of the IBM product line managers saw another use for microprogramming, one that their customer base thought to be extremely important: allowing assembly language programs from earlier models (IBM 1401, IBM 7040, IBM 7094) to run unchanged on any model of the System/360 series. As one later author put it, it was only the introduction of microprogramming and the emulation of earlier machines allowed by this feature that prevented ―mass defections‖ of the IBM customer base to other companies, such as Honeywell, that were certainly looking for the business. This idea was proposed and named “emulation” by Stewart Tucker (quoted above).
- Page 1 and 2: The Evolution of Microprogramming I
- Page 3 and 4: Design of the Control Unit There ar
- Page 5 and 6: How Does the Control Unit Work? The
- Page 7 and 8: Maurice Wilkes Maurice Wilkes worke
- Page 9 and 10: A Diode Memory A diode is a one way
- Page 11: Early Interest in Microprogramming
- Page 15 and 16: The Microprogram Design Process Her
- Page 17 and 18: Benefits of Microprogramming As not
- Page 19 and 20: Side-Effects of Microprogramming It
- Page 21 and 22: Microprogramming and Memory Technol
- Page 23 and 24: The IA-32 Control Unit In order to
- Page 25: References (Davies, 1972) Readings
<strong>Microprogramming</strong> is Taken Seriously<br />
It was with the introduction of the IBM System/360 that microprogramming was taken<br />
seriously as an option for designing control units. There were three reasons.<br />
1. The recent availability of memory units with sufficient reliability <strong>and</strong><br />
reasonable cost.<br />
2. The fact that IBM took the technology seriously.<br />
3. The fact that IBM aggressively pushed the memory technology inside the<br />
<strong>com</strong>pany to make microprogramming feasible.<br />
IBM’ goals are stated in the 1967 paper by Tucker.<br />
―<strong>Microprogramming</strong> in the System/360 line is not meant to provide the problem<br />
programmer with an instruction set that he can custom–tailor. Quite the<br />
contrary, it has been used to help design a fixed instruction set capable of<br />
reaching across a <strong>com</strong>patible line of machines in a wide range of performances.<br />
… The use of microprogramming has, however, made it feasible for the smaller<br />
models of System/360 to provide the same <strong>com</strong>prehensive instruction set as the<br />
large models.‖<br />
Tucker notes that the use of a ROS [Read Only Store] is somewhat expensive, be<strong>com</strong>ing<br />
attractive only as ―an instruction set be<strong>com</strong>es more <strong>com</strong>prehensive‖.<br />
Source: (Page 225 of Tucker, 1967)
Change language