Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!hao!ames!lll-tis!lll-lcc!pyramid!nsc!csi!jwhitnel
From: jwhitnel@csi.UUCP (Jerry Whitnell)
Newsgroups: comp.lang.misc
Subject: Re: software ICs vs. libraries
Message-ID: <1270@csib.csi.UUCP>
Date: Fri, 23-Oct-87 20:58:44 EST
Article-I.D.: csib.1270
Posted: Fri Oct 23 20:58:44 1987
Date-Received: Sun, 25-Oct-87 23:14:31 EST
References: <3405@ece-csc.UUCP> <638@its63b.ed.ac.uk>
Reply-To: jwhitnel@csib.UUCP (Jerry Whitnell)
Organization: Communications Solutions Inc., San Jose, Ca
Lines: 88

In article <3349@uw-june.UUCP> bnfb@uw-june.UUCP (Bjorn Freeman-Benson) writes:
|>...exciting, like "Software-IC".  Libraries have been around at least as
|>long as programming languages; ...
|
|I think that there is a difference between libraries and something
|more general, say "software-ICs".  The libraries I have seen are
|collections of routines that someone found useful, and then put
|together for mass consumption.  A good example of this is the
|Macintosh Toolbox routines: they are powerful, but they are
|hopelessly complex, and have a questionable programmer improvement.

Having programmed the Macintosh, I'll have to disagree with the last two
comments.  The toolbox is complicated, but not hopelessly so, since there are
a large number of programmers using it to develop software.  As far as
programmer improvement is concerned, 99.9% of the programs on the Mac use
some portion of the interface, and 99.8% of them use the Toolbox rather
then write it themselves (there's always one who wants to write it himself
anyway :-)).  Compared to the cost of doing it all themselves, there is
certainly a large improvement in programmer productivity.  One might argue
that the Mac interface itself is detirmental to programmer productitivty,
but since it greatly enhances user productivity, we programmers will have to
bite the bullet and use it.

|
|A "software-IC" would seem to be a more thourghly thought out, better
|designed, unit of software that could be used for multiple purposes.
|In other words, a design team would set out to design a software-IC,
|rather than extracting little pieces of code from their final
|product to place in a library.  The subclassing ability of Smalltalk
|and its kin are a start.

My defintion of a "software-IC" is a follows:

1) Simplicity of function:  An IC should have one and only one function.  This 
function could be just to sort data or as complicated as converting 3d-objects
to 2d-display.  This relates directly to the hardware IC which implements a
single function (whether it is an AND or a Multiplexer).

2) Layered.  Not only should the calling function interface be defined, but
also the called functions interfaces should be defined.  The programmer can
mix and match pieces to achieve the desired set of features.  A example of
where this concept is not used but should be is the UNIX malloc function.  
Malloc is implemented using several queues and OS calls.  There is no reason
while the programmer couldn't replace these with other equivalent functions
if needed, except that unless he has access to the source code, he has no
idea what the called functions do.

3) Well documented.  If you looks at a 7400 book, you can see the wealth of
information provided about ICs.  Everything from pin-outs to time charts to
tempature specs.  You look at any software libary spec and you'll usually
get half a page of incomplete information, usually wrong :-).  Complete
documentation in a standard format is a necessity.

4) Machine/OS/Language independent.  For a hardware engineer, all of the
iterfaces are standard (TTL), as are the ICs (7400).  This means that
an engineer can mix and match with no worry about the enviroment the final
product will end up in.  Different choices can be made for reasons of costs,
speed, power consumption all without changing the base design.  For software
ICs the same should be true.  If you need a sort, you should be able to go
to your "42-series" catalog, look up sort routines and pick the one that
meets your needs for speed/memory consumption/... independent of whether
your working on a Mac, a PC, a UNIX box or an IBM mainframe (well, maybe not
there :-)).  


|
|>...7000 series ICs has all but ended and almost all serious design now is
|>being done with semicustom or custom components.
|
|However, one must consider that current software technology is at
|the level of individual transistors and resistors, and that we could
|use the step up to "7000 series ICs".  After that, custom and
|semi-custom would be great.

I disagree, semi-custom and custom are really a step backwards on the hardware
side, as far as engineers are concerned.  Whereas before one could depend on
each IC being a black box (chip?) whose implementation you didn't care about
(mostly), now the implementations will be right in front of you with nothing
to prevent from aliasing this function to that global over there...  Just
as bad as software is now!

|
|				Bjorn N. Freeman-Benson


Jerry Whitnell                           It's a damn poor mind that can only
Communication Solutions, Inc.            think of one way to spell a word.
						-- Andrew Jackson