Browse Prior Art Database

Dynamically Sharing Controlled Storage

IP.com Disclosure Number: IPCOM000075754D
Original Publication Date: 1971-Nov-01
Included in the Prior Art Database: 2005-Feb-24
Document File: 3 page(s) / 50K

Publishing Venue

IBM

Related People

Dhus, EF: AUTHOR [+2]

Abstract

The instruction set of a machine may be dynamically extended by utilizing a writeable control storage (WCS). A fixed area portion of WCS stores the micro-code for the base instruction set, while another portion is reserved as a transient area for the loading and reloading of micro-code for the extended set. The microprogram loading mechanism treats microcode as data, which may be stored-off-line or kept in main storage, and loads the specific microprogram, as required, into WCS on a demand basis. Optimization of the loading process can be achieved by preloading microprograms, having a high frequency of execution, into main storage buffers before the actual requirement arises for execution of the micro-code, e.g.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 3

Dynamically Sharing Controlled Storage

The instruction set of a machine may be dynamically extended by utilizing a writeable control storage (WCS). A fixed area portion of WCS stores the micro- code for the base instruction set, while another portion is reserved as a transient area for the loading and reloading of micro-code for the extended set. The microprogram loading mechanism treats microcode as data, which may be stored-off-line or kept in main storage, and loads the specific microprogram, as required, into WCS on a demand basis. Optimization of the loading process can be achieved by preloading microprograms, having a high frequency of execution, into main storage buffers before the actual requirement arises for execution of the micro-code, e.g., by making the microprogram resident in main storage at SYSGEN or IPL time; whereas microprograms having a low frequency of execution may be left on a secondary storage device, and loaded into WCS via main storage at the precise moment it is required as when the problem program issues a request. Micro-code loaded into main storage is loaded into a Micros Code Load Area (MCLA), or if loaded at problem program execution time, into a Micro-Code Transient Area (MCTA). The first several bytes of data are used as an ID field containing two sub-fields: one contains a value for the length of the microprogram, and the other, the address in WCS where the microprogram is to be loaded. A table is provided, each entry of which contains an op-code field and a pointer field. The opcode field identifies a function or instruction which is not permanently resident in WCS, i.e., an extended instruction which does not belong to the system's basic instruction set. The field is two bytes long; the first byte containing the primary op-code and the second byte a qualifier or secondary decode. The pointer field, if equal to zero, indicates that the micro-code is not resident in main storage and must be fetched from the secondary storage device; if not equal to zero, it indicates that the micro-code is resident and points to its location. Within the routine for loading WCS is a Residency Mask, which is a two-byte field containing the same information as the op-code field of the MCLA and MCTA. The Residency Mask will contain the primary and secondary op- codes, which represent whichever microprogram is currently resident in WCS.

The microprogram loading mechanism is invoked via a Supervisor Call (SVC) instruction. Immediately following the SVC instruction, the user codes a constant, the value of which is the user op-code and its operands. After receiving control from the SVC Handler of the c...