Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!im4u!ut-sally!ut-ngp!infotel!pollux!bobkat!m5d
From: m5d@bobkat.UUCP (Mike McNally )
Newsgroups: comp.sys.intel
Subject: Code prefetch
Message-ID: <242@bobkat.UUCP>
Date: Thu, 20-Nov-86 12:00:30 EST
Article-I.D.: bobkat.242
Posted: Thu Nov 20 12:00:30 1986
Date-Received: Thu, 20-Nov-86 23:44:27 EST
Reply-To: m5d@bobkat.UUCP (Mr Mike McNally)
Distribution: na
Organization: Digital Lynx; Dallas TX
Lines: 36
Keywords: code prefetch compiler basic-blocks

Perhaps I am giving away a valuable idea, but I won't flatter myself
that this could be the case.  

Various architectures (the x86 architecture in particular) involve
a mechanism whereby the CPU is able to fetch code during unused/
unusable bus cycles.  In the x86 series, the prefetch is dumb (less
dumb on the 2- and 386 than the original chips, but dumb nevertheless).
The prefetch queue is kept small (although I was surprised at the 
size (16 bytes) of the queue in the 386) 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?  This
could easily be provided in the 86 architecture as a special
tag byte, leaving maybe four or five bits to tell how many instructions
can safely be prefetched.  The advantages to such a system are even
greater given a burst-mode bus cycle.

Do any existing architectures incorporate such a scheme?  Seems pretty
obvious to me.  Are there any problems that I can't see?  Could this
be as significant as the development of multitronics ("an entirely
new approach...") (note my username)?

-- 
****                                                         ****
**** At Digital Lynx, we're almost in Garland, but not quite ****
****                                                         ****

Mike McNally                                    Digital Lynx Inc.
Software (not hardware) Person                  Dallas  TX  75243
uucp: ...convex!ctvax!bobkat!m5                 (214) 238-7474