Path: utzoo!attcan!uunet!snorkelwacker!tut.cis.ohio-state.edu!pt.cs.cmu.edu!chiles.slisp.cs.cmu.edu!chiles
From: chiles@chiles.slisp.cs.cmu.edu (Bill Chiles)
Newsgroups: comp.arch
Subject: MIPS 64x32 Divide?
Message-ID: <9462@pt.cs.cmu.edu>
Date: 30 May 90 14:16:24 GMT
Reply-To: chiles@cs.cmu.edu
Organization: Carnegie-Mellon University, CS/RI
Lines: 30

This is a general query of how to do 64-bit by 32-bit division when a
machine only gives you a 32-bit by 32-bit instruction.  At first I was
shocked that MIPS didn't offer this since a 32-bit by 32-bit multiply
potentially results in a 64-bit result, and I expected to be able to
reverse the operation.  I suspect all of their intensive profiling has
revealed that C programs only ever divide a long integer by a long integer
at best.  I wonder if they profiled any languages that support infinite
precision integer arithmetic?  Maybe they did, and what they found is that
conventional computing almost never requires a 64x32 divide.

Some languages and number packages do support this stuff and require a
64x32 divide for completeness, even if profiling dictates that it isn't
worth providing such an instruction.  This assumes the implementation has
chosen 32-bit digits values.

Has anyone implemented this on the MIPS?  Is there some theory I'm missing
that makes 64x32 divide fairly simple given a 32x32 divider?  Given a
routine
   DIVIDE x1 x2 y   -->   q, r
DIVIDE could make the following assumptions:
   1] x1 is the high 32 bits of a 64-bit positive integer.
   2] x2 is the low 32 bits of a 64-bit integer.
   3] y is positive and sufficiently large to adhere to your favorite
      infinite precision integer divide algorithm.
   4] q and r are unsigned 32-bit quantities.

I'm curious to know what MIPS has seen profiling programs regarding the use
of 64x32 bit division if anyone there can report this kind of information.

Bill