Browse Prior Art Database

Pipelined IBM System/370 I-Fetching and Addressing Controls for Emulation Assist Processor

IP.com Disclosure Number: IPCOM000040353D
Original Publication Date: 1987-Oct-01
Included in the Prior Art Database: 2005-Feb-02
Document File: 3 page(s) / 48K

Publishing Venue

IBM

Related People

Hannon, ES: AUTHOR [+2]

Abstract

A performance gain for an Emulation Assist Processor (EAP) is attained by using pipelined IBM System/370 instruction fetching controls. The control logic is implemented using four logically reduced truth tables (Fig. 1). The function of these four tables and associated support logic virtually eliminates the need to wait for S/370 instructions which currently reside in CACHE. These controls directly interact with a CACHE/Data Storage Unit (DSU) which provides the S/370 instructions to the EAP. The functions of the four tables are as follows: The IREQ Table determines if there is a need to request a new (Image Omitted) S/370 instruction from the DSU. The determination is based upon predicting the state of the S/370 Pre-Fetch Register (PFR) in the next machine cycle.

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 53% of the total text.

Page 1 of 3

Pipelined IBM System/370 I-Fetching and Addressing Controls for Emulation Assist Processor

A performance gain for an Emulation Assist Processor (EAP) is attained by using pipelined IBM System/370 instruction fetching controls. The control logic is implemented using four logically reduced truth tables (Fig. 1). The function of these four tables and associated support logic virtually eliminates the need to wait for S/370 instructions which currently reside in CACHE. These controls directly interact with a CACHE/Data Storage Unit (DSU) which provides the S/370 instructions to the EAP. The functions of the four tables are as follows: The IREQ Table determines if there is a need to request a new

(Image Omitted)

S/370 instruction from the DSU.

The determination is based upon predicting the state of the S/370 Pre-Fetch Register (PFR) in the next machine cycle. The logical inputs that allow the need for a new instruction to be predicted are the present state of the PFR, the length of the next S/370 instruction to be emulated, and any pending undetermined branches. The IRSP Table determines whether an actual S/370 instruction request should be made. It also provides status on pending instruction requests, pending interrupt requests and received S/370 instructions.

The outputs of this table are determined by the need for a S/370 instruction (previously determined by the IREQ Table), DSU status
(i.e., interrupt Request/Busy), and conditional branch results. The PFR Table generates all the necessary control lines needed to receive and align 2-, 4-, and 6-byte S/370 instructions in the PFR (Fig. 2).

The PFR can accept either 2-or-4 byte-long input data for unaligned fetches. These controls are predetermined by the present state of the PFR, the length of the next S/370 instruction to be emula...