From: anton@mips.complang.tuwien.ac.at
Stefan Monnier writes:
>> Yes RISC it needs a cache or it just wastes all its potential
>> concurrency in stalls.
>
>FWIW, the original ARM did not have a cache,
Indeed, the ARM2 used in the Archimedes does not have a cache and runs
rings around contemporary CISCs (including 386 and 68020, with a small
I-cache on the 68020).
It runs at 8MHz, the same speed as the first HPPA implementation
(TS-1, a board, not a chip), which does have 64K+64K cache. However,
the ARM2 does not have an MMU, while the 386 and the TS-1 have one,
and the 68020 was usually used with an MMU.
It seems to me that ARM made this clock work with DRAM without cache
by making good use of staying in the same row: In particular,
consecutive instructions usually are from the same row. In addition,
ARM includes load-multiple and store-multiple instructions that access
consecutive data that usually are in the same row.
By contrast, note that the VAX 11/780 has a 5MHz clock (and about
10CPI) and a cache. Even if the DRAM at the time of the VAX was
somewhat slower than at the time of the Archimedes, and the VAX has an
MMU, I am sure that an ARM-like RISC with an MMU, FPU and just DRAM
would have required less implementation effort and performed better
than the VAX 11/780 if implemented with the same technology as the VAX
11/780. If you add a cache to the RISC (as the VAX 11/780 has, even
better. If you convert the VAX 11/780 microcode store into a cache,
even better. And, to combat code size, use something like ARM T32
instead of A32, and the decoder and instruction buffering for that
would still fit in the implementation budget (the VAX 11/780 also has
instruction buffering and a decoder for variable-length instructions.
- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup,
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
