Re: Constant divisions, remainders

jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879)
Wed, 11 Nov 1992 14:59:32 GMT

          From comp.compilers

Related articles
Constant divisions, remainders rutt@paradise.mti.sgi.com (1992-10-20)
Re: Constant divisions, remainders Cheryl_Lins@gateway.qm.apple.com (Cheryl Lins) (1992-10-21)
Re: Constant divisions, remainders phillips@swanee.ee.uwa.oz.au (1992-10-23)
Re: Constant divisions, remainders kelsey@flora.ccs.northeastern.edu (1992-10-27)
Re: Constant divisions, remainders torbenm@diku.dk (1992-11-02)
Re: Constant divisions, remainders joe@babel.ho.att.com (1992-11-05)
Re: Constant divisions, remainders henry@zoo.toronto.edu (1992-11-08)
Re: Constant divisions, remainders jones@pyrite.cs.uiowa.edu (1992-11-11)
Re: Constant divisions, remainders nickh@CS.CMU.EDU (1992-11-11)
Re: Constant divisions, remainders preston@miranda.cs.rice.edu (1992-11-11)
Re: Constant divisions, remainders jlg@cochiti.lanl.gov (1992-11-12)
Re: Constant divisions, remainders corbett@lupa.Eng.Sun.COM (1992-11-12)
Re: Constant divisions, remainders jfc@athena.mit.edu (1992-11-16)
| List of all articles for this month |

Newsgroups: comp.compilers,comp.arch
From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879)
Organization: University of Iowa, Iowa City, IA, USA
Date: Wed, 11 Nov 1992 14:59:32 GMT
Keywords: arithmetic
References: 92-11-033

henry@zoo.toronto.edu (Henry Spencer):
> Actually, I seem to recall that it is specifically a relic of FORTRAN,
> which made a fairly arbitrary decision for the sake of well-defined
> behavior, and has been too influential for machine designers to ignore
> ever since.


Indeed, there are two "intuitive" ways to solve the problem of negative
operands in the system:


      Q = A div B
      R = A mod B


While adhering to the rule that


1) A = QB + R


One solution preserves the equation:


2) (-A)/B = -(A/B)


The desirability of this equation is obvious!


While the other preserves the rule that


3) sign(R) = sign(B)


The desirability of this equation is also obvious -- it makes
modular arithmetic work, specifically, either


0 <= A mod B < B -- for positive B


or


0 >= A mod B > B -- for negative B


Rules 1, 2 and 3 are all desirable, but they cannot all be satisfied! The
designers of FORTRAN, being numerically inclined, chose to keep rule 2,
and they didn't really think about 1. Wirth, in Pascal, chose to keep 2
because of precidents, and also added rule 1 to define the mod operator.
Ada provided a mod operator that satisfied rule 3, but also a rem operator
so that they could define div and rem in terms of 1 and 2. The average
Ada programmer probably flips a coin to select between the mod and rem
operators.


Speaking as someone who worries primarily about coding and other integer
stuff, I'd prefer division to obey rules 1 and 3, because then I can use
div and mod to pack and unpack things to an arbitrary radix.


If hardware designers need a hard and flat statement to guide their work,
it should be that both definitions of div and mod should be supported by
the hardware! (or in a RISC, if neither is supported, I should be able to
get either).


In my PhD thesis, long ago, I suggested that the div instruction (that
produces both quotient and remainder) should provide one interpretation,
but that there should be a single instruction that can be used to flip
between rule 2 and 3 -- I called this the divide correct instruction.
checks the condition codes (or whatever) and if needed adjusts the
quotient up or down by one and adjusts the remainder by adding or
subtracting the divisor.
Doug Jones
jones@cs.uiowa.edu
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.