Path: utzoo!utgpu!water!watmath!clyde!bellcore!rutgers!cmcl2!nrl-cmf!ames!mailrus!wasatch!utah-gr!uplherc!sp7040!obie!wsccs!dharvey
From: dharvey@wsccs.UUCP (David Harvey)
Newsgroups: comp.arch
Subject: Re: RISC v. CISC
Summary: Software to the rescue!
Message-ID: <754@wsccs.UUCP>
Date: 27 Oct 88 09:09:05 GMT
References: <156@gloom.UUCP> <890@cps3xx.UUCP> <10194@cup.portal.com>
Lines: 23

In article <10194@cup.portal.com>, bcase@cup.portal.com (Brian bcase Case) writes:
> 
> What has been left out of this discussion is the software side of the
> issue.  The almighty Compiler can save us from our sins!  It is our
> saviour!  Long live common subexpression elimination!  Hail to the code
> reorganizer!  Praise the register allocator!  Jim Bakker, watch out!

This view is typical of hardware types.  By all means, lets pass the
buck to the next guy.  So the compiler writer has his(her) share of
nightmares actually getting something to make the thing compile some
code.  And then the systems programmer comes along and inserts a few
more kludges to make the machine purr.  Did he document them?  I hope
so.  Now it is the application programmer's turn to s***w things up.
If my memory serves me correctly, it is much easier to get something
up and running on a Motorola 68000 than on an Intel 8086 (very nasty,
those beasty little segments).  And miracle of miracles, we learn that
over 70% of computing costs are software.  It seems like hardware types
should be designing their end of the deal to reduce it at the other end.


dharvey@wsccs

What do I know...I don't design the d**n things, I just use them.