kds@intelca.UUCP (Ken Shoemaker) (06/05/85)
> o Memory speed and resource usage > > This one is a tie as far as I can tell. Both use a 4-clock memory > cycle, both have prefetch queues, the bigger ones (286 & 020) both > have a cache (although the 68020 has a 3-clock memory cycle as I > understand it (though I may be wrong), and the 286 has a 4-clock > cycle (from the 286 hardware reference manual crouching near my left > elbow)). From a pure bus speed standpoint, it seems to be a tie. > A little confusion, I'm afraid. The 286 accepts a 2X clock, and the clock speed from which things are drawn is a divide by 2 of that clock. So, the 286 really has a 2 clock bus cycle. Of course, the other option is that what we call a 12MHz 286 is what you would call a 24MHz 286. Also, with pipelined address/data, the 286 provides more generous access times, even if you don't use interleaved memories, since the address output delays from clock on MOS devices aren't nearly as fast as that of an F or AS latch. Also, this means that you can pre-select memories before a cycle, or whatever. This kinda falls into the AT vs Z150 battle, too. If you believe that most modern microprocessors are bus limited to some extent, then performance is closely tied to the bus bandwidth of the processor. Even with 1 wait state, the 286 has a 3 clock bus as opposed to a 4 clock bus of the 8088. Thus, at 6MHz, the 286 with 1 wait state has a maximum bus bandwidth of 4MBytes/second (=6MHz/3 * 2) while at 8MHz, and 8088 with 0 wait states has a maximum bus bandwidth of 2Mbytes/second (=8Mhz/4). Even for byte reads, the latency time from the bus for the 286 with one wait state is the same as the 8088 with no wait states. Besides all this, the 286 does execute instructions inside the chip faster than the 8088, so you are going to have to look a little farther than just a processor(286)/processor(88) comparison for an explaination of your results. The nature of the 286 bus as opposed to the 8088 bus also follows through to the 286 bus vs the 68{000,010,020} busses: I still don't understand why since Mot gives you seperate address and data busses that they don't use them better, i.e., present early addresses to memory systems that could use them to an advantage. This really does allow faster operation with slower memories at the cost of more pins on your package. For what it's worth, it seems to me that Mot is wasting money providing seperate address/data pins with the utilization that they provide (unless they are not pad limited on their die, and their yields are such that package costs are insignificant). I mean, all those extra drivers do take up die space, and those extra pads could mean that the chip is not as small or as cheap as it could be.... Finally, I have another question to pose to the net. I believe Mot uses a two level microcode in the 68k and its followons... (can someone verify this?) Does anyone have any idea what this means to its performance (with respect jumps and having to fill up the instruction queue). Do they take two clocks to do a complete microcode lookup (the first to the first level, the second to the second level)? RISCs that are out there have NO microcode, and present this as one reason for their faster performance. Also, this was one reason Zilog presented way back when for the performance of the Z8000 (they said it was good). If you think about it, it does make sense, since you have to wait at least 1 clock to go through your microcode lookup. Any thoughts? -- It looks so easy, but looks sometimes deceive... Ken Shoemaker, 386 Design Team, Intel, Santa Clara, Ca. {pur-ee,hplabs,amd,scgvaxd,dual,qantel}!intelca!kds ---the above views are personal. They may not represent those of Intel.
henry@utzoo.UUCP (Henry Spencer) (06/06/85)
> ... I believe > Mot uses a two level microcode in the 68k and its followons... > (can someone verify this?) Yup, that's correct. Don't know how it affects the speed. Remember that microcode fetch time normally is pipelined out, since the execution of microcode is predictable (barring bizarre architectures with micro- interrupts) and techniques like delayed branches are routine. > ...this was one reason Zilog presented way back when for the performance > of the Z8000 (they said it was good). It's also one reason why the (hardwired) Z8000 took a lot longer to debug than the (microcoded) 68000. I believe Zilog has since admitted that not using microprogramming was a mistake. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry