One interesting question is whether a prefetch should be encoded with its own unique opcode, or whether it should simply be a variation on a normal load instruction. A load instruction could be modified to encode a prefetch in the following two ways. First, some RISC architectures (such as the HP Precision Architecture) allow user-specified hints on loads, and one type of hint could be interpreted as a prefetch. Second, many RISC architectures set aside one register which always sources the value zero. Performing a load to this reserved register does not change its contents, so such operations could be interpreted as prefetches.
Although a prefetch can be encoded as a form of a load, it is preferable to designate a unique opcode for prefetches (assuming one can be spared) for the following two reasons. First, since prefetches and loads behave quite differently (i.e. prefetches are non-binding, non-blocking, and non-excepting), it may be important to distinguish them early on during decoding, which is presumably easier with distinct opcodes. Second, with distinct opcodes, the bits normally used to specify the destination register of a load can be used instead as ``hint bits'' to describe various flavors of prefetching. For example, we have already seen in Section the advantages of having both shared-mode and exclusive-mode prefetches in multiprocessors under an invalidation-based cache coherence scheme. Other prefetching variations which will be described later in this chapter include: (i) prefetching multiple cache lines rather than a single cache line (which may help reduce instruction overhead, as described in Section ); (ii) prefetching data that is to remain uncached rather than being placed in the cache (which may help reduce cache conflicts, as described in Section ); and (iii) whether or not a prefetch should be dropped on a TLB miss (as described in Section ). Figure shows a possible encoding of the prefetch instruction, based on the MIPS instruction set, including these prefetching hints.