Path: utzoo!attcan!uunet!samsung!ctrsol!cica!iuvax!purdue!bu-cs!mirror!prism!rob
From: rob@prism.TMC.COM
Newsgroups: comp.sys.ibm.pc
Subject: Re: Ami Bios and the V20
Message-ID: <206900138@prism>
Date: 21 Nov 89 15:57:00 GMT
References: <6129@merlin.usc.edu>
Lines: 23
Nf-ID: #R:merlin.usc.edu:-612900:prism:206900138:000:1430
Nf-From: prism.TMC.COM!rob    Nov 21 10:57:00 1989


 > A major problem is that the 8088 and V20 are bus-bound.  Any instruction
 > that executes in less than four clock cycles per byte will drain the
 > four-byte instruction prefetch queue.  

  This is true for many code sequences, though not all. The problem is that, 
on the 8088 at least, many instructions take longer than 4 clocks/byte. In 
general, register intensive code (like the SHL AX,1 in your example) is bus 
bound, while memory intensive code, and some register arithmetic, is compute 
bound. 'Typical' code falls somewhere in between, though the bus is still a 
bottleneck. The V20, with its faster effective address calculation, is more 
likely to run up against the bus limit when accessing memory, so your point 
about bus bandwidth being a limiting factor is valid.

   One of SI's problems is that it's entirely compute bound on an 8086/88. 
It shows no difference between an 8088 and an 8086 running at the same clock 
speed. This is because SI spends about 2/3 of its time on IMUL or IDIV 
instructions, which are uninfluenced by bus bandwidth. Thus the way to speed 
up a CPU's SI rating is to speed up its multiplies and divides. Of course, 
since most code doesn't contain many IMULs or IDIVs, a CPU that speeds those 
instructions up more than it speeds up the more common ones will do better 
at SI than it will in 'real life'. That's why SI overstates the performance 
of many CPUs so drastically.