NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/arch/9382

Text File | 1992-09-11 | 3.9 KB | 76 lines

Xref: sparky comp.arch:9382 comp.lang.misc:3043
Newsgroups: comp.arch,comp.lang.misc
Path: sparky!uunet!sun-barr!ames!haven.umd.edu!darwin.sura.net!Sirius.dfn.de!rz.ruhr-uni-bochum.de!jan
From: [e-mail] (Jan Vorbrueggen)
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Message-ID: <[e-mail]>
In-reply-to: [e-mail]'s message of 11 Sep 92 18:47:44 GMT
Organization: Inst. f. Neuroinformatik, Ruhr-Universitaet Bochum, FRG
References: <[e-mail]> <[e-mail]>
    <[e-mail]> <[e-mail]>
Date: 12 Sep 92 15:54:39
Lines: 62

In article <[e-mail]>
[e-mail] (Lawrence Crowl) writes:
   >And then the hardware designers, being told that something is useless, drop
   >it from the instruction set?

   You misunderstand what has happened in the industry.  The hardware designers
   were told that something was rarely used, and therefore was not cost
   effective.  As good engineers, they dropped the feature.

Ah yes. And them somebody thought of an algorithm, reducing the complexity
of some important programme. Unfortunately, because of a few cents' worth
of cost savings in the hardware design, the implementation is ten to 1000
times slower than necessary. Sheesh, how cost effective!

Pray tell, how are you, using this philosophy of "it's only rarely used",
going to avoid ending up with processors which can do nothing but NANDs?
They're still Trung machines, but I'd rather not use them for my simulations.

   >Designing flexibility in both hardware and software is not that expensive;
   >putting in something left out may be.

   [...] I invite you to provide _evidence_ in support of your claim.

   >A simple example is that of square root. The cost of putting in square root
   >on any machine which has "classical" division hardware is essentially zero
   >at the design and construction stage,but an algorithm to do it is otherwise
   >is necessarily slow and costly.

   Only costly when making simplistic comparisons.  If the lack of square root
   hardware increases my run time from 10 seconds to 10.0001 seconds (which is
   probably realistic for many if not most program runs), it is _not_ costly.

And that _is_ a simplistic comparison. Why should "many if not most"
programmes be good enough reason for elimiting a function? I think Herman
is talking about incremental cost effectiveness. And to give you an example:
When Inmos added an FPU to the transputer, they put in a barrel shifter and
a 3bit/cycle mutiplier. Taking these as a given, they put in the microcode
for square root and remainder because that's all it cost them: some more
microcode. Should they just leave them out just to spite their customers?

   >Bit vectors do not necessarily start on a word, or even a byte, boundary,

   Yes, but if only one in a million don't, supporting nonaligned bit vectors
   probably isn't cost effective.

And again, these decisions are limiting what gets done. Why are currently
proposed cryptoalgorithms using key lengths that are powers of two? Surely,
one of the reasons is that current hardware isn't able to process bit strings
that don't fall on 64 ot 128 bit boundaries efficiently.

   >and again, it is easier to deal with the problem at hardware design time
   >rather than in software.

   This claim is strongly supported by the wide abundance of hardware
   implemented compilers and spreadsheet packages.  :)

Not quite that, but look at IBM's VM/HPO. A large part of the virtual machine
assists and thus of VM is actually done in microcode, probably individually
for every model series. Saving 25% or more of your 3090's processing power
is certainly worth a few man year's microcoding slavery.

Jan Vorbrueggen, Inst. f. Neuroinformatik, EuheUniversitaet Bochum, FRG