Path: utzoo!attcan!uunet!zephyr.ens.tek.com!tekchips!tekgvs!toma
From: toma@tekgvs.LABS.TEK.COM (Tom Almy)
Newsgroups: comp.lang.forth
Subject: Re: Forth Implementation
Message-ID: <8302@tekgvs.LABS.TEK.COM>
Date: 22 Oct 90 15:13:29 GMT
References: <1899.UUL1.3#5129@willett.pgh.pa.us>
Reply-To: toma@tekgvs.LABS.TEK.COM (Tom Almy)
Organization: Tektronix, Inc., Beaverton,  OR.
Lines: 36

In article <1899.UUL1.3#5129@willett.pgh.pa.us> ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) writes:
>     I couldn't believe Jonah Thomas's results that found the push 
>instructions to be faster than the register move instructions.  There  is such
>a huge difference in the listed number of "clocks" that I bend  over backwards
>to use the moves instead of the push/pops.  I decided  I'd better test it out
>myself!

>     I tested it on an 8 MHz XT clone with a NEC V20 in place of the  8088
>microprocessor. 
[testing details deleted]

>     The NEC book also says to allow 4 clocks per byte when the needed 
>byte is not already in the prefetch queue. [...]
>If we assume the needed bytes are NEVER present in the prefetch queue, we 
>would add 2*4=8 clocks to the move, giving it a total of 10 clocks, and 
>we'd add 1*4 clocks to the push/pop, giving it a total of 16 clocks.  

>There's our 16 to 10 or 1.6 to 1 ratio. [...]

>At 12 clocks the 1 byte push/pop is "too fast."  The 
>prefetch queue can't keep up.  What instructions do you have to run to 
>keep the queue filled up?  Maybe divide instructions. 

The other way to keep the queue filled is to widen the data path. For instance,
an 8086, V30, 80186, or 80286 can fetch two bytes at a time, thus you only
need to add four clocks for every  two bytes if not already in the prefetch
queue. The move instruction would be 4 clocks added to the basic 2 clock = 6,
and the push/pop would add 2 clocks to the basic (now faster) 10 clocks=12,
for a 2 to 1 ratio, rather than the 5 to 1 quoted. This is off by a factor
of 2.5 rather than almost 4.

The 32 bit data path of the 80386 (and 80486 when instructions are not in
the cache) does even better.
Tom Almy
toma@tekgvs.labs.tek.com
Standard Disclaimers Apply