Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!unisoft!gethen!farren
From: farren@gethen.UUCP (Michael J. Farren)
Newsgroups: comp.lang.misc
Subject: Re: software ICs vs. libraries
Message-ID: <250@gethen.UUCP>
Date: Sat, 24-Oct-87 17:33:42 EST
Article-I.D.: gethen.250
Posted: Sat Oct 24 17:33:42 1987
Date-Received: Tue, 27-Oct-87 02:54:41 EST
References: <3405@ece-csc.UUCP> <638@its63b.ed.ac.uk>
Reply-To: farren@gethen.UUCP (Michael J. Farren)
Organization: Sci-Fido - Unix in Oakland
Lines: 52


Several people have made statements that attempt to correlate hardware
with software, usually starting with the resistor and transistor as a
basic block.  I don't feel that this analogy is appropriate.  The closest
equivalent in software to a 7408, to take a very low-level IC for an
example, is three or four AND statements in assembly language, NOT a small
library function (unless you have logical and implemented as a library
function, in which case you have my pity).  The largest piece of software
that has a hardware equivalent is probably something like BitBLT.

The current state of the hardware design art has shifted somewhat away
from general-purpose VLSI implementations of design.  More and more,
hardware designers are recognizing that a general-purpose implementation,
while possibly somewhat simpler to implement, carrys a high cost in
circuit efficiency, economy, and cost.  One of the hottest design
techniques right now is ASIC (Application Specific Integrated Circuits),
which commonly takes many low and medium level components and binds them
together in a form suitable for the specific job at hand - rather like a
high-level routine would use library functions in a specific way.

I believe that the "software IC" concept fails on just those kinds of
issues.  A routine which is simple to use, but complex in function, will
be more costly, both in storage and in speed, than one that is simply
complex, as the simple interface will, in itself, have a cost in code
and execution time.  The example has been mentioned of the difference in
implementation of window functions on the Macintosh and (I believe - I'm
not a Lisp hacker) a Lisp machine.  It was pointed out that changing
window parameters on the Lisp machine was much easier than the same
operation on the Mac.  However, what was not noted, probably because it
was fairly transparent to the end-programmer, was the cost, in bytes and
in nanoseconds, of making those parameters easy to change.  Most machines
now available just don't have enough resources to allow that level of
flexibility and still have an acceptable response for the user.  Smalltalk
is an instructive example; although its concepts made things a lot easier
for many tasks, it took considerable advances in technology before an
actual system could be constructed which wasn't painfully slow from the
user's standpoint.

There will always be a tradeoff between speed and ease of use/programming.
Currently, I strongly believe that the tradeoff favors the use of smaller,
less sophisticated routines designed for the maximum efficiency in
operation, rather than construction.  This situation may well change, but
I think that the use of more primitive constructs in order to obtain the
maximum in efficiency and machine usage will always be a preferred
alternative, whenever it is possible to make the choice.  What will change
will, more than likely, be the level of complexity considered "primitive".


-- 
----------------
Michael J. Farren      "... if the church put in half the time on covetousness
unisoft!gethen!farren   that it does on lust, this would be a better world ..."
gethen!farren@lll-winken.arpa             Garrison Keillor, "Lake Wobegon Days"