Andy Glew's comp-arch.net wiki, http://semipublic.comp-arch.net
If you are reading this elsewhere, e.g. at site waboba.info, it is an unauthorized copy, and probably a malware site.
comp-arch.net wiki on hold from October 17, 2011
Future file (FF)
A future file (FF) is a hardware data structure in an OOO processor that lives in or near the register renaming pipestage. In is indexed by logical register number and contains the data value of the physical register currently mapped to that logical register.
Since that data value may not currently be available, a future file usually also includes a valid bit, cleared on initial allocation, set when the result is produced.
Often a future file is combined with a register renamer, so that the data value is provided if available, and the physical register number or other dataflow tag is provided if it is not ready.
Above I said that a future file is found in an out-of-order processor. However, a future file may also be used in in-order processor designs. E.g., the UltraSPARC III used a future file to avoid result forwarding overhead while also helping to support the use of register windows (using a very wide copying mechanism to move window contents from an architected register file, which mechanism is also used to recover register values after an exception since instructions may complete out of order).
Above I said "the physical register currently mapped to that logical register". However, not all OOO processors perform HaRRM-style register renaming with such an explicit mapping. Earlier designs, preceding HaRRM, sometimes used priority CAMs to locate which of the several values of a logical register should be used. Future files are useful even in such implicitly renamed microarchitectures.
During Intel P6 we used the term active register file (ARF) for what is commonly called a future file. "Active" as in "the current value active for that logical register, if available". I'm not sure why we used ARF instead of future file; perhaps because the acronym ARF is more meaningful, indicating that it is a form of register file (RF). Consistent with my (Andy Glew's) preference to use adjectives to modify an existing term, rather than create a new term.
Benefits and Disadvantages
One advantage of a future file is that is can remove the renaming delay for accessing operands. This may be particularly useful for less frequently changed (or commonly changed by adding an immediate value, which can be done in the front-end) base addresses like a global pointer, a thread local pointer, or a stack pointer. Likewise, a counter variable (or at least the least significant bits of such) might also be considered a candidate for a future file, allowing branches based on the counter to be resolved earlier and eliding counter updates in a manner similar to how stack engines reduce stack pointer updates in the execution engine.
A future file has the disadvantages of typically requiring additional storage and the copying of values.
TBD other advantages and disadvantages