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