🚀 go-pugleaf

In article <1991May1.160128.1367@sono.uucp> miklg@sono.uucp (Michael Goldman ) writes:
>As for CPU upgrades, I see the SPEC marks and other benchmarks showing
>CISC keeping up with RISC within reasonable limits.  I don't see any reason
>why CISC can't keep performance up with a lag time of a year or 2, which is
>negiligible in terms of making a box, getting it to market, and getting
>the price down to reasonable levels.

2 years certainly is negligible in terms of developing a base of
application software. RISC is 2 years ahead in hardware speed, but
it is AT LEAST 2 years behind in applications base, according to the 
overwhelming majority of customers. 

If RISC gets 5 years ahead of CISC in hardware speed, that will be
enough to counter its software lag, which is probably of the same
order. (I.e., if present trends continue, the software available in
5 years for the current major RISC families, assuming they preserve 
binary compatibility, *might* resemble the software available NOW for 
the 80x86 family, in terms of range and price. However, leading-edge
hardware seems hard-pressed to maintain binary compatibility very
far backwards. This is *precisely* the software advantage and
hardware disadvantage of CISC.)

Do comp.arch pundits see RISC chips widening their gap over the
CISC chips? If the performance gap stays at a factor of two or three,
that represents a ~2 year hardware delay for CISC, which doesn't seem
large compared to the ~5 year software lead for CISC. Also, consider
that very few individual users are able to keep even a '386 machine
busy all the time. To do even that is an intense, full-time job for
anyone whose problem can't be solved in one "for" loop.

I would guess that the average PC or Mac gets used a lot more than the 
average Sparcstation, primarily because the average PC or Mac user can 
afford more applications. The average useful program, if available
under UNIX, costs 2--10 times as much as the DOS or Mac equivalent.
This problem isn't going away anytime soon.

Of course, since CISC and RISC are Turing-equivalent, there is no
fundamental reason why the software lead of CISC should be immutable.
In the real world, however, transparent portability across 
architectures appears elusive, for a variety of reasons, and most
of them seem rather silly.


--
Dan Mocsny				
Internet: dmocsny@minerva.che.uc.edu