Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site peora.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!houxm!hjuxa!petsd!peora!jer
From: jer@peora.UUCP (J. Eric Roskos)
Newsgroups: net.arch,net.micro.68k
Subject: Re: 68k dbcc
Message-ID: <2102@peora.UUCP>
Date: Tue, 15-Apr-86 08:29:13 EST
Article-I.D.: peora.2102
Posted: Tue Apr 15 08:29:13 1986
Date-Received: Thu, 17-Apr-86 00:49:34 EST
References: <1511@decwrl.DEC.COM> <5100028@ccvaxa>
Organization: Concurrent Computer Corporation, Orlando, Fl
Lines: 30
Xref: watmath net.arch:3080 net.micro.68k:1627

> The lesson here is don't ever say "Nobody will ever try X" with an instruction
> set.

This is very true, and applies to OS & language design as well as instruction 
set design.

Actually I think it has to do with a more general aspect of design
philosophy, though.  (Ironically, one of the reasons I've always thought
highly of Motorola's CPUs is that they usually avoid such problems!)

There are two ways you can approach a design: either come up with some
set of simple and complete primitives out of which to build the system,
then build it consistently using those (this is a sort of axiomatic
approach); or just design piecemeal by saying "I think we need this...
well, we also need this so let's add it... and don't forget this...".
The latter you often see happening in "design by committee", e.g. some
of the old and infamous programming languages.

I suspect the "minimize the number of architects" principle that Brooks
mentions in "The Mythical Man Month" is actually a symptom of this
approach.  When you have one architect (or a small number of them), 
they are somewhat forced to design axiomatically, simply in order to
reduce the complexity of the design.  But designs by larger groups
can be done this way, just as designs by an individual can be done the
piecemeal way.
-- 
E. Roskos

"But all my words come back to me
 in shades of mediocrity..."