Browse Prior Art Database

Branch Refetch Direction Cache

IP.com Disclosure Number: IPCOM000217765D
Publication Date: 2012-May-11
Document File: 3 page(s) / 31K

Publishing Venue

The IP.com Prior Art Database

Abstract

A method which captures the branch direction calculated by branch execution for all branches is disclosed.

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

Page 01 of 3

Branch Refetch Direction Cache

Disclosed is a method which captures the branch direction calculated by branch execution for all branches.

Modern microprocessors employ deep speculation to achieve low cycles per instruction (CPI), but often these speculatively fetched and executed instructions are flushed due to a conflict in the pipeline. In many cases, this speculative path contains branches which are fetched, predicted, executed, and then flushed - discarding all information regarding the execution of the branch. After the flush, these branches are executed again - a process which re-calculates the same taken/not taken results. To save power and improve performance, it would be ideal to capture the computational results (taken/not taken direction information) of branches prior to the flush and use this instead of traditional prediction mechanisms when the branches are re-fetched.

After a flush of an instruction (for reasons such as unaligned address, conflict in load/store ordering, etc), the results of the offending instruction along with all younger instructions are discarded and the instructions are again fetched. The second fetch of any previously executed branch ignores the traditional branch prediction guess and uses the direction information (taken/not taken) which was stored when it was previously executed. This direction information may be used by the branch detection logic to determine the next effective address (EA) to speculatively fetch: either the next sequential instruction if the branch was not taken, or the branch target if it was taken.

This method guarantees correct prediction of the branch direction since it was previously resolved, and thus the correct direction is known. This method also saves power by reducing array accesses at fetch time. The prediction logic reads the appropriate direction prediction (a small table) rather than an entire branch history tables which consume significant power to read.

An embodiment of this mechanism could store the resolved direction information in an existing structure such as the effective address table (EAT) which contains other branch information, or it could be stored in a separate structure (array, or register file) in the fetch unit. The storage element must contain a resolved direction bit (taken/not taken), a valid bit, and must be indexed via some unique identifier to associate it with the appropriate branch upon refetch. Such identifiers include EAtag, some portion of the effective address, or other tag as conventionally used by the machine to index branch instructions.

The preferred embodiment of this method utilizes the EAT to store branch direction resolution information. When a branch is executed, the correct direction (taken vs not taken) is sent to the EAT. The EAT implicitly associates the branch direction data with the EA of the branch (taken branches end an EAT row) so an explicit direction bit is not required. A valid bit and branch bit are also assoc...