Browse Prior Art Database

Traps for Mainline Microcode Function

IP.com Disclosure Number: IPCOM000050173D
Original Publication Date: 1982-Sep-01
Included in the Prior Art Database: 2005-Feb-10
Document File: 3 page(s) / 60K

Publishing Venue

IBM

Related People

Lemaire, CA: AUTHOR

Abstract

The performance of microcode for fetching operands and interpreting higher level instructions can be improved by testing certain conditions in the Central Processing Unit (CPU) and taking a trap to a special microcode routine if an operand spans certain address spaces. The microcode trapping apparatus provides the hard branch to specific control storage addresses upon detection of microcode specified conditions which result from CPU operations. If the condition specified is not detected, the microcode continues executing instructions determined by the normal next address arrangement. If the condition specified is detected, the microcode traps to the address reserved for that condition's trap, execute the microcode to handle that condition, and return to the path which would have been taken had no trap occurred.

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

Traps for Mainline Microcode Function

The performance of microcode for fetching operands and interpreting higher level instructions can be improved by testing certain conditions in the Central Processing Unit (CPU) and taking a trap to a special microcode routine if an operand spans certain address spaces. The microcode trapping apparatus provides the hard branch to specific control storage addresses upon detection of microcode specified conditions which result from CPU operations. If the condition specified is not detected, the microcode continues executing instructions determined by the normal next address arrangement. If the condition specified is detected, the microcode traps to the address reserved for that condition's trap, execute the microcode to handle that condition, and return to the path which would have been taken had no trap occurred. A trap is taken if a page crossing is detected during the calculation of the virtual address of the second end of an operand if the virtual address is not a virtual=real address. This calculation could be the addition or subtraction of the length of the operand to or from, respectively, the address of the first end of the operand. A trap is also taken if there is an effective address overflow during the calculation of the virtual address of an operand irrespective of whether or not the virtual address is a virtual=real address.

In Fig. 1, central processing unit 10 passes a virtual address to virtual address translator 20 which translates the virtual address to a real address for addressing main storage 50. Schematically illustrated virtual storage 60 is partitioned into pages where each page is mapped into a main storage frame of equal size. Sequentially addressed pages are not necessarily mapped into sequentially addressed main storage frames. Therefore, when an operand spans the boundary between two virtual pages, translates are performed on the virtual addresses of both ends of the operand so as to have both main storage frames available. The resultant frame addresses are saved in a lookaside buffer 21 of the virtual address translator 20.

In Fig. 2, M register 30 contains the low order two bytes of a 6-byte virtual address for addressing one end of the operand to be fetched from main storage
50. L register 31 contains a one byte indication of the length of the operand to be fetched. The contents of the L register are added to the contents of the M register by a control storage instruction executed in CPU 10, as illustrated in Fig. 3, where the addition is performed...