Browse Prior Art Database

Macros for Preparing Microcode Modules

IP.com Disclosure Number: IPCOM000087806D
Original Publication Date: 1977-Mar-01
Included in the Prior Art Database: 2005-Mar-03
Document File: 2 page(s) / 15K

Publishing Venue

IBM

Related People

Batey, MA: AUTHOR [+2]

Abstract

Modern data processors are controlled by microcode loaded into the main store of the processor. Microcode modules consist of two basic types, resident and transient. Resident modules contain that microcode which is necessary for the control of the processor, whatever task it is performing. Transient modules, on the other hand, contain microcode relating to a particular function and are loaded into the main store only when the processor is required to perform that function. Resident modules are loaded into the store so that the microinstructions occupy contiguous storage space. Transient modules, in contrast, are generally not loaded into contiguous storage space but are loaded into blocks of storage scattered throughout the main store. The blocks of storage space are chained together.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

Macros for Preparing Microcode Modules

Modern data processors are controlled by microcode loaded into the main store of the processor. Microcode modules consist of two basic types, resident and transient. Resident modules contain that microcode which is necessary for the control of the processor, whatever task it is performing. Transient modules, on the other hand, contain microcode relating to a particular function and are loaded into the main store only when the processor is required to perform that function. Resident modules are loaded into the store so that the microinstructions occupy contiguous storage space. Transient modules, in contrast, are generally not loaded into contiguous storage space but are loaded into blocks of storage scattered throughout the main store. The blocks of storage space are chained together.

The macros described below are designed to complement a transient-loading system which operates as follows. When a transient module is loaded into main store, the loader (to which no changes are required for the operation of the macros) assigns blocks of the module to available blocks of storage space, these being seldom contiguous (hence the term `scatter-loading'. The former will contain references to each other for transfers of control and possibly for access to tables of data. Certain bytes at the end of each block are used as a system control area for this purpose. Prior to loading, the assembled microcode in a module block will contain references to slots in the system control area which contain the relative block numbers (0,1,2, ...) of the blocks to which references are made from that module block. When the transient module is loaded into main store, the loader replaces these relative block numbers by the physical storage addresses of the main store blocks into which the referenced blocks have been loaded.

However, the process of organizing the relative block numbers in the system control area and the references to them from the microcode has proved to be a tedious and error-prone task for the microcoder preparing such transient modules. The code must be packaged to fit into the nonsystem control area part of each block. For each block, references to other blocks must be identified and a slot allocated in its system control area for each different referenced block (and a check made that no more than the maximum allowable number of slots are required). Each reference must then be coded as a reference to the appropriate system control area slot (typically a 3-instruction sequence) to obtain the more significant half of the address of the referenced location (with which the loader will replace the relative block number), followed by a further instruction to load the less significant half of the address (which is known at assembly time).

The whole process is further complicated by the not infrequent necessity of inserting or amending code in a block at a later date, w...