RISCs too close to hardware? (was: Do we really need virtual machines?)

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>It is interesting that the S/360 instruction set has had as long a
>life as it has, surviving two changes to its address space, huge
>factors in processor speed and memory size. S/360 is fairly simple as
>instruction sets go. Only a few addressing modes and a few
>instruction lengths.
>
>Consider how long the VAX lasted, for example, with a large number of
>addressing modes and instruction lengths.
>
>RISC architectures, being closer to the underlying hardware, I see as
>shorter lived.


Some features of some RISC architectures, like branch delay slots
(MIPS, SPARC, 88k) and architectural load delay slots (MIPS-I) have
indeed proved to be too close to hardware, and were eliminated in
newer RISC architectures, and sometimes eliminated or at least
deprecated even in later revisions of the same architecture.


And certainly the RISC principles seem to have provided more speedup
in the time around 1990 than nowadays, but I don't see that the RISC
principles as embodied in e.g., the Alpha architecture would provide a
disadvantage over the 360 or the 386 architecture on current hardware
or hardware in the foreseeable future.


If these architectures are not as long-lived as the 360 or 386, the
reason is not hardware, but software.


>Architectures like Itanium, requiring the compiler to know fine
>details of the hardware, less virtual in the sense described above,
>might be expected to have shorter lifetimes.


Here similarly, the software rather than the hardware will be the
decisive factor.


The compiler does not need to know details of the hardware. Even
utilization of the fancy architectural features is optional, one could
just treat it as an ordinary RISC.


Followups to comp.arch


- anton
--
M. Anton Ertl
anton@mips.complang.tuwien.ac.at
http://www.complang.tuwien.ac.at/anton/home.html
[I would argue that the 360 survived both because it had IBM's marketing
might and because it had big enough addresses and wasn't overly optimized
for a particular hardware cost model like the Vax was. But this argument
definitely belongs in comp.arch. See you there. -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.