Xref: utzoo comp.arch:20999 comp.lang.misc:6668
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!sdd.hp.com!news.cs.indiana.edu!news.nd.edu!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: bizarre instructions
Summary: Or not so bizarre
Message-ID: <6503@mentor.cc.purdue.edu>
Date: 21 Feb 91 14:39:45 GMT
References: <9102210042.AA12291@ucbvax.Berkeley.EDU>
Sender: news@mentor.cc.purdue.edu
Followup-To: comp.arch
Lines: 74

In article <9102210042.AA12291@ucbvax.Berkeley.EDU>, JBS@IBM.COM writes:
> 
>           Herman Rubin says:
> Do you mean to tell me that computations involving both integers and
> floating-point numbers are not important?  Or that dividing floats by
> floats, obtaining an integer quotient and a floating remainder, likewise?
> That particular step is the first step of any trigonometric or exponential
> function computation when it is not known in advance that the argument is
> small.  There are other periodic and related functions for which this is
> useful.  It would also speed up interpolation, etc.
> 
>           Since argument reduction for the trigonometric functions is
> done in practice by multiplying by 1/pi I do not see how it would ben-
> efit from your proposed instruction.  I believe this instruction would
> have little general utility.

There is somewhat greater loss of accuracy in this, and it is still 
needed to extract the integer part to an integer register and the
fractional part.  Thus, it needs at least three operations, instead
of one.  Also, if one is calculating something like x - ln(1+x), a
natural operation in certain problems, the computing problems become
a little larger than one would expect.  In fact, to avoid a loss of
accuracy in some quite usual situations, it would even be a good idea
to have Boolean operations on floats, and unnormalized floating
arithmetic.  Floating arithmetic, apart from some preliminaries,
and normalization problems, is exactly the same as integer, so why
should there be a separate arithmetic unit even?
	
>           An efficient way to do the fortran "x=dint(y)" is important.
> This is lacking on the Risc System 6000 as was pointed out in a Los
> Alamos report.  By the way is it true that it is impossible to
> reasonably express this in ADA?
>         Peter Montgomery says:
>         Yes, most programs are written in these languages.
> As Dan says, the language designers made mistakes.  During one
> review period for Fortran 90, I requested an operation which
> takes four nonnegative integers a, b, c, n with
> a < n or b < n (c is optional and defaults to 0).
> The requested operation returns q and/or r, where
> 
>                 a*b + c = q*n + r   and   0 <= r < n
> 
>         Why didn't you ask for an integer*8 data type?  Wouldn't
> that give you what you want and have much more general utility?

Yes and no.  It would have much more general utility, but it would
do an abysmally inefficient job in this situation.  You would need
to have a way of indicating that the product of two integers*4 is
an integer*8, which I do not know how to do in any language with 
which I am familiar without writing it as a function, and I do not
think that one should have to write mult48(a,b) instead of a*b.  In
addition, how would you write the operation which, when applied to
a*b+c and n, yields both q and r?  Is the reason why it is difficult
to get double length multiplication, and division with quotient and
remainder, that the language designers left these out, and then the

As far as adding this type, why not allow the user to add any type?  This
was present for up to three additional types on Fortran VI(?) on the CDC3600.

>         I would like an instruction which counts the number of ones in
> the binary representation of an integer but I find it hard to argue
> that this would be widely used.

Cray seems to find this one important enough to include on his machines,
which have a real paucity of instructions.

I think you will find that those who want to add "bizarre" instructions in
both hardware and software to do what the present stuff does not do well
understand the problems of both, and have some idea of what is feasible 
at reasonable cost.  
--
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet)   {purdue,pur-ee}!l.cc!hrubin(UUCP)


Brought to you by Super Global Mega Corp .com