=========================================================================
Date: 10 November 1994, 20:35:06 EST
From: JBS      at YKTVMV
To:   usenet-poster at polecat.newsgate.ibm.com
Newsgroups: comp.arch
X-Post-Me: Yes
Subject: bloat
 
         John R. Mashey posted (in response to someone else):
>This is a rather large over-generalization; to some extent, it is
>silly: I know plenty of people who design high-performance chips
>in many compaines, and I haven't seen much  trace of "we should make it
>complicated in order to employ our huge staffs."  leading-edge chips
>are usually done with 50-100 people.
>Please: either back up this claim, which is pervasive ... or
>withdraw it.
>
>1) The current high-end chips are complicated ... because they have
>to be to stay competitive.  It is clearly good to keep things as simple
>as they can be, (but no simpler).
 
         Companies may not want to make things complicated in order to
employ people, however the decision making processes often appear to
be biased in ways that lead to the same result.
         Groups within large companies are always pushing pet proposals
of one sort or another.  There is considerable incentive for backers of
proposals to exaggerate the benefits and underestimate the costs.  Costs
due to added complexity may be easy to ignore because they are diffuse
and not readily quantified.  As a result bad proposals get adopted which
increase complexity and require additional employees to manage the
complexity.
         For example a group may ask that instruction p be added to the
architecture because it will improve performance for application A by
x% and application A is y% of the application mix (x and y are often
grossly inflated).  Only the most obvious costs may be considered, ie
instruction p will require z% of the chip area.  The cost of compiler
support for example may be totally ignored.  As a result the architec-
ture may gradually become overly complicated as changes are made with
inadequate justification.  What's more the simultaneous existence of
slightly different versions of the architecture is itself a source of
complexity and aggravation.
         In this regard looking at the mips architecture I find it hard
to believe that there are valid technical reasons for multiply-add to
be defined one way for the r8000 and another way for the r10000.  From
the outside this looks like a political decision making process
producing a sub-optimal result.  No doubt similar questions can be
raised about the various versions of the power architecture.
                     James B. Shearer