crowl@rochester.ARPA (Lawrence Crowl) (11/21/86)
In article <242@bobkat.UUCP> m5d@bobkat.UUCP (Mr Mike McNally) writes: >Various architectures involve a mechanism whereby the CPU is able to fetch >code during unused/unusable bus cycles. In the x86 series, the prefetch >is dumb. The prefetch queue is kept small because it was found that the >point of diminishing returns was encountered at about 6 bytes. The >obvious problem is that branch instructions do not cooperate with the >idea of prefetching. Attempts to follow different paths beyond a branch >seem like Koyaanisqatsi solutions to me. >A compiler with a minimal amount of smarts can detect runs of code which >can be guaranteed to execute in sequence. Since the compiler is >generating the code, why not provide information on the size of the >upcoming run of certainly sequential instructions? ... The advantages >to such a system are even greater given a burst-mode bus cycle. >Mike McNally The sequence approach still does not help in prefetching code past the branch point before actually finding out which way the branch will go. I suspect a variable length burst mode will be no more effective than a fixed burst mode which is always applied on instruction fetch. One possible solution to this problem is to have the branch instructions themselves indicate which branch is more likely. The machine could then prefetch the most likely sequence, and most often it will already have the instructions it needs. When the branch taken is the least common, the prefetch queue must be flushed and re-filled. The RISC approach is to have the instructions after the branch executed reguardless if the branch is taken or not. For a small pipe or prefetch queue, the compiler can usually fill this "delay slot" with a useful instruction. Though this represents a problem if the pipe or prefetch queue gets to large. -- Lawrence Crowl 716-275-5766 University of Rochester crowl@rochester.arpa Computer Science Department ...!{allegra,decvax,seismo}!rochester!crowl Rochester, New York, 14627