Path: utzoo!attcan!uunet!auspex!guy
From: guy@auspex.UUCP (Guy Harris)
Newsgroups: comp.arch
Subject: Re: RISC v. CISC
Message-ID: <390@auspex.UUCP>
Date: 2 Nov 88 09:49:43 GMT
References: <156@gloom.UUCP> <890@cps3xx.UUCP> <10194@cup.portal.com> <754@wsccs.UUCP> <359@auspex.UUCP> <223@daitc.daitc.mil>
Reply-To: guy@auspex.UUCP (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 27

>But since most of us customize software rather than hardware, this may
>be a valid comparison.

Although I doubt it is in this particular case.  Compiler and OS
development costs tend to be amortized over a base close in size to the
base over which hardware development costs are amortized, and that's
what the original poster was talking about.  (Arguably, the base is even
larger, since many hardware development costs are amortized over an
implementation of an architecture, rather than over the entire
architecture.)

I've not seen any good evidence that any added software
development/production/maintenance cost, over the lifecycle of an
architecture, of a simpler architecture outweighs any added hardware
development/production/maintenance cost, over the life cycle of an
architecture, of a more complex architecture. 

I'm also not convinced that there's a major added application
development cost for developing in sufficiently high-level languages on
RISC machines (I've heard some flames that there is, but many of those
problems appear to be due to sloppy coding habits combined with luck, on
the part of the developers, in the choice of CISC machines they ported
to).  I know that I had no great extra trouble getting C code, whether
kernel-mode or user-mode, working on SPARC as well as 68K; it tended to
run on the 80386 and 370 as well.  In cases where code failed on SPARC,
it often failed for reasons that would cause it to fail on some
CISC-based systems as well....