Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!pacbell.com!ucsd!ucbvax!bloom-beacon!eru!hagbard!sunic!lth.se!newsuser
From: bengtl@maths.lth.se (Bengt Larsson)
Newsgroups: comp.arch
Subject: Re: new instructions
Message-ID: <1991May21.023625.21265@lth.se>
Date: 21 May 91 02:36:25 GMT
References: <9105200213.AA05095@ucbvax.Berkeley.EDU> <12526@mentor.cc.purdue.edu>
Sender: newsuser@lth.se (LTH network news server)
Reply-To: bengtl@maths.lth.se (Bengt Larsson)
Organization: Lund Institute of Technology, Sweden
Lines: 78

In article <12526@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu 
(Herman Rubin) writes:

>The last question first:  How about multiple precision floating (or fixed)
>arithmetic?  Considering that there are quite a few papers on this, it is
>certainly a topic of interest.  I do not believe it should be necessary here
>to go into the full range of situations I can list NOW where this would be
>useful.  

Please indulge. Where would this be useful?

>So why not have increased integer accuracy?

Yes, why not? But the important question is *why*?

>There are algorithms which call, at some stage at least, for fixed point 
>arithmetic. Infinite precision (no mistake here) methods of generating
>non-uniform random numbers tend to be of this type.  

Interesting progression. From "there are algorithms", to "generating
non-uniform random numbers". That is 1 algorithm.

>The chicken and the egg again.  Anyone who is willing to say that something
>is not useful is either ignorant, arrogant, or stupid.  Nobody can, or should,
>attempt to ever do this.  

You seem to have adopted a favorite metaphor. It doesn't apply here
though. You can implement just about any algorithm you want to.
If not, give counterexamples.

As for ignorant, arrogant, or stupid, this may occasionally apply to others
than the computer architects in the discussion.

>Even the best people can make big mistakes.

Well, name a favorite big mistake of your own doing, Mr Rubin :-)

>How many current languages have user-definable operations?

Practically all of them, assuming a function syntax.

>There are provisions for octal and hex
>integers, but none for explicitly writing floats or fixed-point numbers to
>those bases.  

Ada.

>Like the infamous frexp function in C? 

>The 4.2BSD library even used
>a machine independent algorithm, which needless to say was frequently slower
>by a factor of more than 100.  

Then the 4.2 BSD library could be rewritten, without changing the machine.

>Of course the work has to be done in machine-dependent code, and in the
>integer registers, if they are separate.

Naturally.

>On parallel machines, how does one handle conditional transfers and
>conditional calls?  They are deadly, and if one has 2^14 units (already
>in existence), a one-in-a-million condition becomes one-in-62.  If the
>condition calls for major work, say 100,000 cycles, and I have examples
>of this, this can occupy most of the time.  There are single operations,
>which deviate from the parallel idea, but are similar to those already
>in use there, which can alleviate the mess.

The programming of 2^14 parallelly working units using separate
instruction streams is not a solved problem. 

I assume that a clarification of the operations which can alleviate
the mess would be in order. 

Bengt Larsson.
-- 
Bengt Larsson - Dep. of Math. Statistics, Lund University, Sweden
Internet: bengtl@maths.lth.se             SUNET:    TYCHE::BENGT_L