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)