jmd@granite.dec.com (John Danskin) (09/14/88)
In article <904@elxsi.UUCP> you write: ... lots deleted >The other thing, the implications of which I don't yet fully understand, is >that access time to data in cache is the same as access to data in a register. >The instruction set allows one of the source operands to be a generalized >address of the usual sort - i.e., base, base + displacement, base + index >plus displacement, and so forth. The access time for data in the cache is >one cycle, without regard for the complexity of the address mode. Since >everything (practically every instruction) is one cycle, you are encouraged >to use the most complex address modes and most powerful instructions that >make sense, as they squeeze out RISCish instructions that would consume extra >cycles. They also seem to reduce the demand for registers by reducing the >penalty for not having something in a register, although there is still a >penalty. Naturally, these are expensive RAMs and an expensive CPU. My point >is that, in our CPU at least, there are interesting things going on in the >never-ending war between the levels of the memory heirarchy. At least one VAX (8700-8800etc.) has the same latency to cache as to the register file. That made the microcode much easier to write, improved time to market, meant that we sold it while the silicon was still hot, etc. etc. It was a RISCish way to implement a CISC architecture, in the sense that we simplified the internal architecture, possibly throwing away peak speed for simplicity (and getting the thing out the door while it was still fast (for a vax)). So this design tradeoff was probably a good thing for the Elxsi given the same constraints. But. In general (given freedom over the architecture) I hear that: a) If your registers are the same speed as your cache: i. Your registers are too slow, and/or ii. You have too many registers b) If you can access cache in a single cycle your CPU is too slow c) If you can decipher that complicated addressing mode in a single clock tick, you should decrease your clock cycle (gates/tick) until you can't anymore ---> this is so that those RISCy instructions that you are currently starving out become important again. Of course, all one tick instructions with very fast ticks puts a tremendous load on the instruction caching, requires more cache, and increases bandwidth across the chip edge. Comments? -- John Danskin | decwrl!jmd DEC Technology Development | (415) 853-6724 100 Hamilton Avenue | My comments are my own. Palo Alto, CA 94306 | I do not speak for DEC.