Xref: utzoo comp.lang.c++:2142 comp.lang.c:14414 comp.lang.forth:688 comp.lang.fortran:1555 comp.lang.misc:2227 comp.arch:7385 Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!claris!apple!desnoyer From: desnoyer@Apple.COM (Peter Desnoyers) Newsgroups: comp.lang.c++,comp.lang.c,comp.lang.forth,comp.lang.fortran,comp.lang.misc,comp.arch Subject: Re: Assembly or .... Message-ID: <21440@apple.Apple.COM> Date: 30 Nov 88 17:27:13 GMT References: <1388@aucs.UUCP| <729@convex.UUCP> <1961@crete.cs.glasgow.ac.uk> <949@taux01.UUCP> <1034@l.cc.purdue.edu> Organization: Apple Computer Inc, Cupertino, CA Lines: 25 In article <1034@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: > >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. This was only implicitly stated, at best, in the original posting by use of Fortran variable naming conventions. I read the article in comp.lang.c. Enough said. Now that I understand the original question, I have a new answer - There is no natural divide-type operation mapping (real,real) -> (real,integer). The operation mentioned was either poorly defined, or merely consisted of: convert a, b to int div a,b -> int quotient, remainder convert remainder to float If what you mean is that for any integer or floating-point operation op(i1,i2,...in,o1,o2...,om) with n inputs 'i' and m outputs 'o', the full set of 2^^n+m combinations of i1 : {int, float}, ... om : {int, float} should be supported as hardware instructions, then the idea is patently absurd. Peter Desnoyers