Loading data to vector renamed register from across multiple cache lines

A load instruction that accesses data cache may be off natural alignment, which causes a cache line crossing to complete the access. The illustrative embodiments provide a mechanism for loading data across multiple cache lines without the need for an accumulation register or collection point for partial data access from a first cache line while waiting for a second cache line to be accessed. Because the accesses to separate cache lines are concatenated within the vector rename register without the need for an accumulator, an off-alignment load instruction is completely pipeline-able and flushable with no cleanup consequences.

BACKGROUND

The present application relates generally to an improved data processing apparatus and method and more specifically to an apparatus and method for loading data to vector renamed registers from across multiple cache lines.

A microprocessor is the heart of a modern computer, a chip made up of millions of transistors and other elements organized into specific functional operating units, including arithmetic units, cache memory and memory management, predictive logic, and data movement. Processors in modern computers have grown tremendously in performance, capabilities, and complexity over the past decade.

A memory cache is a memory bank that bridges main memory and the central processing unit (CPU). A cache is faster than main memory and allows instructions to be executed and data to be read and written at higher speed. Instructions and data are transferred from main memory to the cache in fixed blocks, known as cache “lines.”

Caches take advantage of “temporal locality,” which means the same data item is often reused many times. Caches also benefit from “spatial locality,” wherein the next instruction to be executed or the next data item to be processed is likely to be the next in line. The more often the same data item is processed or the more sequential the instructions or data, the greater the chance for a “cache hit.” If the next item is not in the cache, a “cache miss” occurs, and the CPU has to go to main memory or a higher cache level to retrieve it. A level 1 (L1) cache is a memory bank typically built into the CPU chip. A level 2 cache (L2) is a secondary staging area that feeds the L1 cache. Increasing the size of the L2 cache may speed up some applications but have no effect on others. L2 may be built into the CPU chip or may reside on a separate chip or a separate bank of chips.

SUMMARY

In one illustrative embodiment, a method, in a processor, is provided for loading data to a vector register from across multiple cache lines in a data cache. The method comprises receiving a vector load instruction in a load/store unit. The vector load instruction crosses at least one cache line boundary. The method further comprises accessing a first cache line in the data cache to receive a first data portion associated with the vector load instruction, formatting the first data portion for a partial write to the vector register to form a formatted first data portion, and writing the formatted first data portion to the vector register. The method further comprises attempting a second cache line access to access a second cache line in the data cache to receive a second data portion associated with the vector load instruction. Responsive to the second cache line resulting in a cache hit, the method comprises formatting the second data portion for a partial write to the vector register to form a formatted second data portion and writing the formatted second data portion to the vector register thereby loading the data associated with the vector load instruction into the vector register.

In another illustrative embodiment, a load/store unit is provided in a processor for loading data to a vector register from across multiple cache lines. The load/store unit comprises an address generation unit and formatting logic coupled to the address generation unit. The address generation unit is configured to receive a vector load instruction that crosses at least one cache line boundary in the data cache. The load/store unit is configured to access a first cache line to receive a first data portion associated with the vector load instruction. The formatting logic is configured to format the first data portion for a partial write to the vector register to form a formatted first data portion. The load/store unit is configured to write the formatted first data portion to the vector register. The load/store unit is configured to attempt a second cache line access to access a second cache line to receive a second data portion associated with the vector load instruction. Responsive to the second cache line access resulting in a cache hit, the formatting logic is configured to format the second data portion for a partial write to the vector register to form a formatted second data portion and the load/store unit is configured to write the formatted second data portion to the vector register thereby loading the data associated with the vector load instruction into the vector register.

In yet another illustrative embodiment, a processor is provided for loading data to a vector register from across multiple cache lines. The processor comprises an instruction sequencing unit, an issue queue coupled to the instruction sequencing unit, a load/store unit coupled to the issue queue, a data cache coupled to the load/store unit, and a vector register coupled to the load/store unit. The instruction sequencing unit is configured to dispatch instructions to the issue queue. The load/store unit is configured to receive a vector load instruction from the issue queue. The vector load instruction crosses at least one cache line boundary in the data cache. The load/store unit is configured to access a first cache line to receive a first data portion associated with the vector load instruction from the data cache, format the first data portion for a partial write to the vector register to form a formatted first data portion, and write the formatted first data portion to the vector register. The load/store unit is configured to attempt a second cache line access to access a second cache line to receive a second data portion from the data cache. Responsive to the second cache line access resulting in a cache hit, the load/store unit is configured to format the second data portion for a partial write to the vector register to form a formatted second data portion and write the formatted second data portion to the vector register.

DETAILED DESCRIPTION

The illustrative embodiments provide a mechanism for loading data to vector rename register from across multiple cache lines. A load instruction that accesses data cache may be off natural alignment, which causes a cache line crossing to complete the access. The illustrative embodiments provide a mechanism for loading data across multiple cache lines without the need for an accumulation register or collection point for partial data access from a first cache line while waiting for a second cache line to be accessed. Because the accesses to separate cache lines are concatenated within the vector rename register without the need for an accumulator, an off-alignment load instruction is completely pipeline-able and flushable with no cleanup consequences. As long as both cache line accesses result in a cache hit, the mechanism maintains continuity and avoids costly and timely logic additions.

The illustrative embodiments may be utilized in many different types of data processing environments including a distributed data processing environment, a single data processing device, or the like. In order to provide a context for the description of the specific elements and functionality of the illustrative embodiments,FIGS. 1-3are provided hereafter as example environments in which aspects of the illustrative embodiments may be implemented. While the description followingFIGS. 1-3will focus primarily on a single data processing device implementation, this is only an example and is not intended to state or imply any limitation with regard to the features of the present invention. To the contrary, the illustrative embodiments are intended to include distributed data processing environments and embodiments.

With reference now to the figures and in particular with reference toFIGS. 1-3, example diagrams of data processing environments are provided in which illustrative embodiments of the present invention may be implemented. It should be appreciated thatFIGS. 1-3are only examples and are not intended to assert or imply any limitation with regard to the environments in which aspects or embodiments of the present invention may be implemented. Many modifications to the depicted environments may be made without departing from the spirit and scope of the present invention.

Referring toFIG. 3, an exemplary block diagram of a conventional dual threaded processor design showing functional units and registers is depicted in accordance with an illustrative embodiment. Processor300may be implemented as processing unit206inFIG. 2in these illustrative examples. Processor300comprises a single integrated circuit superscalar microprocessor with dual-thread simultaneous multi-threading (SMT) that may also be operated in a single threaded mode. Accordingly, as discussed further herein below, processor300includes various units, registers, buffers, memories, and other sections, all of which are formed by integrated circuitry. Also, in one example embodiment, processor300operates according to reduced instruction set computer (RISC) techniques.

As shown inFIG. 3, instruction fetch unit (IFU)302connects to instruction cache304. Instruction cache304holds instructions for multiple programs (threads) to be executed. Instruction cache304also has an interface to level 2 (L2) cache/memory306. IFU302requests instructions from instruction cache304according to an instruction address, and passes instructions to instruction decode unit308. In an illustrative embodiment, IFU302may request multiple instructions from instruction cache304for up to two threads at the same time. Instruction decode unit308decodes multiple instructions for up to two threads at the same time and passes decoded instructions to instruction sequencing unit (ISU)309.

Processor300may also include issue queue310, which receives decoded instructions from ISU309. The issue queue310stores instructions awaiting dispatch to the appropriate execution units. In an illustrative embodiment, the execution units of the processor may include branch unit312, load/store units (LSUA)314and (LSUB)316, fixed point execution units (FXUA)318and (FXUB)320, floating point execution units (FPUA)322and (FPUB)324, and vector multimedia extension units (VMXA)326and (VMXB)328. Execution units312,314,316,318,320,322,324,326, and328are fully shared across both threads, meaning that execution units312,314,316,318,320,322,324,326, and328may receive instructions from either or both threads. The processor includes multiple register sets330,332,334,336,338,340,342,344, and346, which may also be referred to as architected register files (ARFs).

An ARF is a file that stores completed data once an instruction has completed execution. ARFs330,332,334,336,338,340,342,344, and346may store data separately for each of the two threads and by the type of instruction, namely general purpose registers (GPRs)330and332, floating point registers (FPRs)334and336, special purpose registers (SPRs)338and340, and vector registers (VRs)344and346. Separately storing completed data by type and by thread assists in reducing processor contention while processing instructions.

The processor additionally includes a set of shared special purpose registers (SPR)342for holding program states, such as an instruction pointer, stack pointer, or processor status word, which may be used on instructions from either or both threads. Execution units312,314,316,318,320,322,324,326, and328are connected to ARFs330,332,334,336,338,340,342,344, and346through simplified internal bus structure349.

In order to execute a floating point instruction, FPUA322and FPUB324retrieves register source operand information, which is input data required to execute an instruction, from FPRs334and336, if the instruction data required to execute the instruction is complete or if the data has passed the point of flushing in the pipeline. Complete data is data that has been generated by an execution unit once an instruction has completed execution and is stored in an ARF, such as ARFs330,332,334,336,338,340,342,344, and346. Incomplete data is data that has been generated during instruction execution where the instruction has not completed execution. FPUA322and FPUB324input their data according to which thread each executing instruction belongs to. For example, FPUA322inputs completed data to FPR334and FPUB324inputs completed data to FPR336, because FPUA322, FPUB324, and FPRs334and336are thread specific.

During execution of an instruction, FPUA322and FPUB324output their destination register operand data, or instruction data generated during execution of the instruction, to FPRs334and336when the instruction has passed the point of flushing in the pipeline. During execution of an instruction, FXUA318, FXUB320, LSUA314, and LSUB316output their destination register operand data, or instruction data generated during execution of the instruction, to GPRs330and332when the instruction has passed the point of flushing in the pipeline. During execution of a subset of instructions, FXUA318, FXUB320, and branch unit312output their destination register operand data to SPRs338,340, and342when the instruction has passed the point of flushing in the pipeline. Program states, such as an instruction pointer, stack pointer, or processor status word, stored in SPRs338and340indicate thread priority352to ISU309. During execution of an instruction, VMXA326and VMXB328output their destination register operand data to VRs344and346when the instruction has passed the point of flushing in the pipeline.

Data cache350may also have associated with it a non-cacheable unit (not shown) which accepts data from the processor and writes it directly to level 2 cache/memory306. In this way, the non-cacheable unit bypasses the coherency protocols required for storage to cache.

In response to the instructions input from instruction cache304and decoded by instruction decode unit308, ISU309selectively dispatches the instructions to issue queue310and then onto execution units312,314,316,318,320,322,324,326, and328with regard to instruction type and thread. In turn, execution units312,314,316,318,320,322,324,326, and328execute one or more instructions of a particular class or type of instructions. For example, FXUA318and FXUB320execute fixed point mathematical operations on register source operands, such as addition, subtraction, ANDing, ORing and XORing. FPUA322and FPUB324execute floating point mathematical operations on register source operands, such as floating point multiplication and division. LSUA314and LSUB316execute load and store instructions, which move operand data between data cache350and ARFs330,332,334, and336. VMXA326and VMXB328execute single instruction operations that include multiple data. Branch unit312executes branch instructions which conditionally alter the flow of execution through a program by modifying the instruction address used by IFU302to request instructions from instruction cache304.

Instruction completion unit354monitors internal bus structure349to determine when instructions executing in execution units312,314,316,318,320,322,324,326, and328are finished writing their operand results to ARFs330,332,334,336,338,340,342,344, and346. Instructions executed by branch unit312, FXUA318, FXUB320, LSUA314, and LSUB316require the same number of cycles to execute, while instructions executed by FPUA322, FPUB324, VMXA326, and VMXB328require a variable, and a larger number of cycles to execute. Therefore, instructions that are grouped together and start executing at the same time do not necessarily finish executing at the same time. “Completion” of an instruction means that the instruction is finishing executing in one of execution units312,314,316,318,320,322,324,326, or328, has passed the point of flushing, and all older instructions have already been updated in the architected state, since instructions have to be completed in order. Hence, the instruction is now ready to complete and update the architected state, which means updating the final state of the data as the instruction has been completed. The architected state can only be updated in order, that is, instructions have to be completed in order and the completed data has to be updated as each instruction completes.

Instruction completion unit354monitors for the completion of instructions, and sends control information356to ISU309to notify ISU309that more groups of instructions can be dispatched to execution units312,314,316,318,320,322,324,326, and328. ISU309sends dispatch signal358, which serves as a throttle to bring more instructions down the pipeline to the dispatch unit, to IFU302and instruction decode unit308to indicate that it is ready to receive more decoded instructions.

When a load instruction accesses data from a cache, the processor must inspect the contents of a store queue for data dependencies. Frequently, high performance designs install a path from the store queue to the output port of the load/store unit (LSU), such as LSU314or316, whereby the dependent store data can be forwarded directly as the result of the load instruction. This “store forwarding,” however, cannot take place at the same speed as a typical cache access, which is tightly compartmentalized in a compact design to reduce delay in any form that may increase the normal data cache-hit latency.

Due to the extra time needed in the store queue to correlate controls that measure the containment of the dependent store data and the accessing and formatting of the dependent store data and the physical travel time associated with this forwarding, a “store forwarding” will require an extra set of cycles additional to that of a normal cache-hit load. For the purposes of this disclosure, this will be referred to as the “recycle path” or “recycle mechanism.”

The recycle mechanism has two parts: a data part and an instruction part. When the data part has completed its duties and the dependent store data is ready to be transmitted to the central processing unit to finish the load instruction, the LSU must announce to the instruction sequencing unit (ISU), such as ISU309, the address of the register the load is targeting, steal a cycle away from the normal instruction dispatch issue process to “re-inject” this store forwarding result into the instruction flow, indicate to the ISU whether this store forwarding recycle process has finished successfully, and that dependent instructions awaiting these results can start to dispatch; and, re-inject into the address-generation path of the LSU the addresses and instruction information for the store forwarding result so that the data can be properly formatted/justified.

Such complication, once designed and established in a high-speed processor load/store unit, can now be used in other ways. Whenever there is a cache miss, and data must be in-paged to the cache from a higher level of hierarchical memory, the specific data from the fetched cache line that can satisfy the instruction is commonly bypassed around the storage element (the cache) and multiplexed into the cache output path. Giving the highest possible timing priority to the cache-hit data path logically leaves this path to be a secondary timing priority, and is commonly the “leg” of the cache output multiplexer that is used to insert “other” “non-cache-hit” data into the load results path back to the central processing unit. Frequently, LSU designs allow instructions moving data from special purpose registers or other architected registers to move along the data path of the recycle mechanism.

FIGS. 4A-4Dillustrate on-alignment and off-alignment cache accesses in accordance with an illustrative embodiment. A typical cache line is 128 bytes. With reference toFIG. 4A, cache line410is 128 bytes. In one example convention, a word is 4 bytes, a double word is 8 bytes, and a quad word is 16 bytes. Turning toFIG. 4B, a load/store unit (LSU) may receive a vector load instruction that accesses a large segment of data422, such as a quad word, within cache lines420. Because the data422naturally aligns with the 128-byte cache line, this data access is considered to be “on-alignment.”

With reference now toFIG. 4C, the LSU may receive a vector load instruction that accesses a segment of data that is “off-alignment,” meaning the segment of data does not naturally align with the 128-byte cache line and exists across multiple cache lines. Thus, the LSU must receive a first double word432from a first cache line within cache lines430and a second double word434from a second cache line.FIG. 4Dillustrates an off-alignment vector load where the LSU may receive a first double word442from a first cache line within cache lines440, and the second portion of the vector load results in a cache miss.

One example design may employ an “accumulator register” to connect data together from two different cache lines before sending the accumulated data to the vector unit to finish a single write operation to the target vector register. For example, consider the example shown inFIG. 4C. The LSU may receive data432from the first cache line with a first cache access and store data432in an accumulator register. The LSU may then receive data434from the second cache line with a second cache access and concatenate data434with the data in the accumulator register. The LSU may then write the concatenated data to the target vector register.

While the use of an accumulator register does indeed allow off-alignment vector load operations, this design has several drawbacks. An accumulator register and the associated logic results in a large and costly design, particularly for multi-threaded core designs, because the LSU may require at least one implementation of the accumulator register per thread to maintain a respectable throughput for all threads. Furthermore, the use of an accumulator register is slow, even if implemented as one accumulator register per thread, because a burst of off-alignment loads means cache boundary crossing conditions could not be maintained in a seamless pipeline.

In accordance with an illustrative embodiment, a load/store unit uses a recycle mechanism to handle a double access to the cache to allow large vector data to be loaded to a vector unit from multiple cache lines. The load/store unit concatenates data received from multiple cache lines in the vector rename register without requiring an accumulator register. The mechanism of the illustrative embodiments is completely pipeline-able and flush-able with no cleanup consequences.

FIG. 5is a block diagram illustrating a mechanism for loading data to a vector register from across multiple cache lines in accordance with an illustrative embodiment. The mechanism shown inFIG. 5makes fetches to multiple cache lines from instructions for any number of threads seamlessly with respect to the cache line accesses. The mechanism uses target vector register bank530with split write control in formatting logic514. The vector register530is divided up into sections of a size that is equivalent to the granularity of the load data to be fetched.

As one example similar to that shown inFIGS. 4A-4D, load store unit (LSU)510receives a 16-byte vector load instruction that accesses data across a cache line boundary within data cache520, whereby the first 8 bytes is in a first cache line and the second 8 bytes is in a second cache line. If vector register530is also 16 bytes in size, then formatting logic514effects a logical and physical split into two 8-byte sections.

Instruction sequencing unit (ISU)502dispatches a vector load instruction to issue queue504, which issues the vector load instruction to load/store unit (LSU)510. The address generation (AGEN) unit512within LSU510determines whether the vector load instruction crosses a cache line boundary by examining data cache520. If the vector load instruction does not cross a cache line boundary, AGEN512accesses the appropriate cache line within data cache520and writes the data to vector register530.

LSU510also includes recycle mechanism516, which may include logic for store forwarding. In accordance with the illustrative embodiment, if AGEN512discovers that the vector load instruction does cross a cache line boundary, meaning the data being accessed is off alignment, AGEN512continues with the load operation, accessing the first cache line in data cache520. LSU510then writes the data from the first cache line in vector register530. Formatting logic514left justifies the data and performs a partial write to the vector register530.

For example, if the vector load accesses 16 bytes of data and vector register530is 16 bytes and the data is off alignment by 8 bytes, then the first cache line access results in 8 bytes of data. Thus, after the first cache line access, vector register530has 8 bytes of “good” data and 8 bytes of “bad” data, because formatting logic514writes the 8 bytes received from the first cache line into the first (most significant bit (MSB)) 8 bytes of vector register530.

AGEN512then uses recycle mechanism516to recycle the vector load instruction back into the AGEN path of LSU510. Recycle mechanism516increments the vector load instruction to the beginning of the next cache line in data cache520. AGEN512receives the recycled vector load instruction and performs the second cache line read from data cache520. Formatting logic514determines that he data is targeted to the last (least significant bit (LSB)) portion of vector register530; therefore, formatting logic514right justifies the data and performs a partial write to vector register530without overwriting the previously written portion.

Given the example above, the second cache line access results in 8 bytes of data. After the second cache line access, vector register530has 16 bytes of “good” data, because formatting logic514performs two partial writes: one to the MSB portion and one to the LSB portion of vector register530.

Once LSU510writes both portions to vector register530, the vector load operation is complete. LSU510then signals ISU502that the address of vector register530is available to be used in dependent operations. In a pipelined fashion, there may be any number of virtual registers engaged in this multiple cache line operation simultaneously without impeding the normal course of instruction sequencing and without requiring one or more accumulation registers for each thread.

While the example embodiments described herein show a 16-byte vector load being off alignment by 8 bytes, the aspects of the illustrative embodiments may be applicable to any vector load size, any cache line size, and any off-alignment condition. For example, a load may be off alignment by a single byte. For instance, a 16-byte load may cause a cache line boundary split with 15 bytes in a first cache line and 1 byte in a second cache line, or vice versa.

Computer program code for carrying out operations of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java™, Smalltalk™, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In addition, the program code may be embodied on a computer readable storage medium on the server or the remote computer and downloaded over a network to a computer readable storage medium of the remote computer or the users' computer for storage and/or execution. Moreover, any of the computing systems or data processing systems may store the program code in a computer readable storage medium after having downloaded the program code over a network from a remote computing system or data processing system.

FIG. 6is a flowchart outlining example operations of a load/store unit for a vector load across multiple cache lines in accordance with an illustrative embodiment. Operation begins, and the load/store unit (LSU) receives a vector load instruction from the instruction sequencing unit (ISU) (block602). The address generation (AGEN) unit in the LSU determines whether the vector load instruction results in a cache line crossing condition (block604). The AGEN may make this determination by examining the addresses in the data cache and determining whether the beginning address and amount of data to be loaded align with a cache line in the data cache.

If the vector instruction is in alignment, and does not result in a cache line crossing condition, the LSU performs a normal vector load operation. That is, the LSU accesses the cache line (block606), writes the received data to the targeted vector register (block608), and signals the ISU that the vector rename register address is available for dependent operations (block610). Thereafter, operation ends. Although not illustrated inFIG. 6, if the cache line access in block606results in a cache miss, the LSU may reject the vector load instruction, which may result in the vector load instruction retrying at a later time, at which point the data may be in the data cache. Alternatively, this determination may be performed as part of block604where a vector load operation may result in a cache line crossing condition any time the data is not found in a single cache line in the data cache. Operation may repeat beginning at block602each time the LSU receives a vector load instruction.

If the vector load instruction is off alignment, which results in a cache line crossing condition in block604, then the AGEN accesses the first cache line in the data cache (block612) and determines whether the cache line access results in a cache hit (block614). If the cache line access does not result in a cache hit (i.e. a cache miss), then the LSU flushes the instruction (block616) and releases the data in the vector register from the first cache line access (block618). In the case of a cache miss in block614, the vector register will not contain any data and block618may be disregarded. The processor may then replay the operation using a microcode routine (block620). Then, operation proceeds to block610where the LSU signals the ISU that the vector rename register address is available for dependent operations, and operation ends.

The microcode routine may retry the vector load at a later time, at which point the data may be in the data cache. The operation is flushed, the “bad” data in the VR rename register is released, and the operation may be replayed using a more elemental microcode routine that accesses the cache lines one-at-a-time and reassembles the result in the VR manually. This is shown in more detail below with respect to a cache miss resulting from the second cache line access.

If the first cache line access results in a cache hit in block614, formatting logic within the LSU formats the data for a partial write to the vector register (block622). The formatting logic may left justify the data so that it is written to the most significant bit (MSB) portion of the vector register. The LSU writes the formatted data to the vector register (block624). Then, a recycle mechanism within the LSU increments and recycles the vector load instruction (block626). Recycling the vector load instruction places the vector load instruction back in the AGEN path of the LSU, which is significantly faster than rejecting and retrying the instruction.

Thereafter, the AGEN receives the recycled vector load instruction and accesses the second cache line (block628) and determines whether the cache line access results in a cache hit (block630). If the second cache line access results in a cache hit, the formatting logic formats the data for a partial write to the vector register (block632). The formatting logic may right justify the data so that it is written to the least significant bit (LSB) portion of the vector register. The LSU writes the formatted data to the vector register (block634). Then, operation proceeds to block610where LSU signals the ISU that the vector rename register address is available for dependent operations, and operation ends.

If the second cache line access results in a cache miss in block630, the LSU flushes the instruction (block616) and releases the data in the vector register from the first cache line access (block618). In the case of a cache hit in block614and a cache miss in block630, the vector register will contain some “good” data with some “bad” data; therefore, the LSU releases all of the data in the vector register in block618. The processor then replays the operation using a microcode routine (block620). Thereafter, operation proceeds to block610where LSU signals the ISU that the vector rename register address is available for dependent operations, and operation ends.

FIG. 7is a flowchart outlining example operations of a microcode routine for a vector load across multiple cache lines in accordance with one example embodiment. This microcode routine is meant as an example only. Other microcode routines may be used to effectuate vector loads across cache line boundaries depending upon the implementation. Operation begins, and the microcode routine breaks the vector load instruction into two load instructions accessing two separate cache lines (block702). In response to the first instruction, the LSU accesses a first cache line (block704) and writes the data to a temporary register (block706). In response to the second instruction, the LSU accesses a second cache line (block708). The microcode routine then concatenates the data from the second cache line access with the data in the temporary register (block710). Then, the microcode routine writes the concatenated data to the vector register (block712), and operation ends.

Thus, the illustrative embodiments provide mechanisms for loading data to vector rename register from across multiple cache lines without the need for an accumulation register or collection point for partial data access from a first cache line while waiting for a second cache line to be accessed. Because the accesses to separate cache lines are concatenated within the vector rename register without the need for an accumulator, an off-alignment load instruction is completely pipeline-able and flushable with no cleanup consequences.

As long as both cache line accesses result in a cache hit, the mechanism maintains continuity and avoids costly and timely logic additions. This hit-hit requirement for fast operations may seem to be an oppressive limitation that may negatively affect performance. However, vector operations typically address data in a sequential manner. Therefore, data for vector operations may be pre-fetched in the data cache more easily than other kinds of data. Pre-fetch mechanisms are standard components in high-speed processing cores, so an assumption that data for two cache lines will be present in the data cache is realistic.

General purpose register (GPRs) and virtual registers (VRs) are typically implemented as “rename” registers, which are used as temporary registers to collect results until such time that the writing instruction completes successfully. This temporary register gets established as a renamed substitute for an architected register. Thus, at any time before the load operation completes, the target VR may be “flushed” when it becomes clear that the load operation will not complete successfully.

Reasons for flushing a vector load operation may include, for example, branch not taken, LSU addressing alignment problems, out-of-order sequence dependent corrections such as store-hit-load, and so forth. In the illustrative embodiments described above, the LSU may have two additional reasons to flush a vector load instruction when access to its data crosses a cache line boundary, because accesses to both cache lines must be cache hits. This allows the mechanisms of the illustrative embodiments to operate within the confines already defined by the highest speed recycle mechanism.

The recycle mechanism of the illustrative embodiments promises to deliver data to the target register and to signal to the ISU to dispatch held back dependent operations in a fixed number of cycles from the engagement of the recycle mechanism. The one case that does not conform to this restriction is whenever there is a cache miss and data must be in-paged to the cache from a higher level of hierarchical memory. The fetch may take an unknown amount of time. Therefore, whenever either of the cache line accesses causes a miss, the operation is flushed, the “bad” data in the VR rename register is released, and the operation may be replayed using a more elemental microcode routine that accesses the cache lines one-at-a-time and reassembles the result in the VR manually.

As an alternative embodiment, the LSU may reject rather than recycle a vector load that crosses a cache line boundary. The LSU must then keep track of the instruction as an off-alignment instruction to concatenate the data from the replayed instruction with the data from the first cache line access. Rejecting a vector load instruction that crosses a cache line boundary would take longer and would require more logic for managing rejected and replayed instructions; however, this would be a viable alternative for a LSU that does not have a recycle mechanism.