Xref: utzoo comp.lang.c++:2161 comp.lang.c:14442 comp.lang.forth:700 comp.lang.fortran:1568 comp.lang.misc:2244 comp.arch:7403
Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!cwjcc!gatech!purdue!i.cc.purdue.edu!k.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.lang.c++,comp.lang.c,comp.lang.forth,comp.lang.fortran,comp.lang.misc,comp.arch
Subject: Re: Assembly or ....
Summary: Still not right
Message-ID: <1040@l.cc.purdue.edu>
Date: 1 Dec 88 14:39:33 GMT
References: <1388@aucs.UUCP| <729@convex.UUCP> <1961@crete.cs.glasgow.ac.uk> <19848@ism780c.isc.com>
Organization: Purdue University Statistics Department
Lines: 35

In article <19848@ism780c.isc.com>, news@ism780c.isc.com (News system) writes:
> In article <1032@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
> ...

 
> Then he clarifies:
> 
> >I do not know if I made it clear in my initial posting, but the problem
> >arises if the types of a, b, and c are floating.  Not that the quote from
> >my paper specifically has i an integer.

 
> Ok here is one.  Quoting from the IBM/709 Reference Manual (Circa 1959)
> 
> FDH - Floating Divide or Halt
>     THe c(ac) [means contents of ac register] are divided by c(y). The
>     quotent appears in the mq and the remainder appears in the ac. ...

The format of this allows the multiple precison division of a single precision
floating point number by a single precision number, and was probably used in
computing double precision quotients, but it has nothing to do with the
question I raised.  The quotient is a truncated floating point quotient,
and the remainder is the remainder from this operation.  Even denormalization,
which was possible on that machine, could not get the quotient as an integer.  
The easiest way to do it on the 709 was first to check if the quotient was 0,
in which case the result is clear.  Otherwise, do the appropriate unpacking
and shifting, do an integer divide, and repack the integer remainder.  This
was more efficient on the 709 than on current machines, because division was
relatively slower and comparisons and transfers were FAST instructions in those
days.  (No, they have not gotten slower; the others have gotten relatively much
faster.)
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)