There are two types of operands fetch policies such as issue bound or dispatch bound. The issue-bound fetch policy defines that operands are fetched during instruction issues. In this method, shelving buffers influence instructions with their operand values, needing that the buffers be fully long to support space for all the source operands.
The other basic operand fetch policy is the dispatch bound fetch policy, when operands are fetched during dispatching. In this case, shelving buffers contain short register identifiers instead of long operands.
In this case, while issuing the instructions, the referenced source register numbers are forwarded to the register file to fetch the source operands. It can also the operation codes (OC), the destination register numbers of the issued instructions (Rd), and the fetched operand values (Op1 and Op2) are written into the allocated reservation stations.
In this approach, operands are fetched in connection with instruction dispatch instead of with instruction issues. During the reservation, stations hold the instructions, including the source register number.
During dispatch, the operation codes and destination register identifiers of the dispatched instructions are delivered from the reservation stations to the related EUs, and the source register identifiers are moved to the register file. Then fetching, the source operands are gated into the inputs of the equivalent EUs.
In Operand fetch policies, it can be considered a common register file for both FX and FP-data. However, most current architectures including the x86, R, PA, Alpha, and PowerPC architectures, use different register files for FX- and FP-data.
Subsequently, the corresponding lines of processors execute different FX- and FP-register files. There are only several modern processors which have an individual FX register file, including the Am 29000 architecture, which provides only FX data. There is another exception is the Nx586 which executes only the FX-part of the structure in the main processor, while the FP-part is performed by an FP-coprocessor chip, known as the Nx587.
In the lack of register renaming, all needed register operands are equipped with the architectural register files. When register renaming is used, still, quite multiple situations arise because in this case intermediate results are held in an additional register space, known as the rename buffer file.