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.
