Efficient division/remainder in C

[nessuno]

I can't find any discussion of this question in this NG.

I'd like to implement some variable precision integer arithmetic in C,
and do it efficiently. A problem arises with the divide/remainder
operations. I'm using gcc on x86, but a lot of what I say applies to
other architectures.

First, I assume the div and ldiv functions are more efficient than
using / and % (obviously it depends on the compiler and level of
optimization, but it's one operation instead of two).

However, div and ldiv require the length of the quotient, divisor,
dividend and remainder to all be the same. Now all the machines I've
ever worked with at the machine language level (quite a few of them)
implement integer division with a dividend that is twice as long as the
divisor, quotient and remainder. Moreover, this is what naturally
arises in multiple precision arithmetic, you get dividends twice as
long as everything else. So suppose I'm using 16-bit divisors,
quotients and remainders, but 32-bit dividends. If I were writing in
assembly language, I would use the instructions that divide 16 bits
into 32.

But when I write in C, I'm forced to use the ldiv function, since one
of the operands is 32-bits. (Let's say int=16-bit and long=32-bit, as
on my machine.) Then the compiler has to implement this ldiv function
by using the instruction that divides 32-bits into 64-bits, since the
divisor is now 32-bits. In other words, the compiled code is forced to
use a divide instruction with operands twice as large as needed, due to
the design of the div and ldiv functions.

Anybody know a way around this (apart from inserting assembly code in
my C program)?

Thanks in advance...

[Eric Sosman]

ne*****@wigner. berkeley.edu wrote On 01/13/06 17:47,:

[...]
First, I assume the div and ldiv functions are more efficient than
using / and % (obviously it depends on the compiler and level of
optimization, but it's one operation instead of two).
[...]
But when I write in C, I'm forced to use the ldiv function, since one
of the operands is 32-bits. (Let's say int=16-bit and long=32-bit, as
on my machine.) Then the compiler has to implement this ldiv function
by using the instruction that divides 32-bits into 64-bits, since the
divisor is now 32-bits. In other words, the compiled code is forced to
use a divide instruction with operands twice as large as needed, due to
the design of the div and ldiv functions.

The leap from "I assume" to "I'm forced" seems a
risky one. What have your measurements shown about
the efficiencies of /, %, both / and %, and ldiv?

You *have* made measurements, haven't you?

HAVEN'T YOU????

--
Er*********@sun .com

[Shark]

Use inline assembly for the system you are on. Use macros to determine
which routine depending on your system. Burst into flames.

ne*****@wigner. berkeley.edu wrote:

I can't find any discussion of this question in this NG.

I'd like to implement some variable precision integer arithmetic in C,
and do it efficiently. A problem arises with the divide/remainder
operations. I'm using gcc on x86, but a lot of what I say applies to
other architectures.

First, I assume the div and ldiv functions are more efficient than
using / and % (obviously it depends on the compiler and level of
optimization, but it's one operation instead of two).

However, div and ldiv require the length of the quotient, divisor,
dividend and remainder to all be the same. Now all the machines I've
ever worked with at the machine language level (quite a few of them)
implement integer division with a dividend that is twice as long as the
divisor, quotient and remainder. Moreover, this is what naturally
arises in multiple precision arithmetic, you get dividends twice as
long as everything else. So suppose I'm using 16-bit divisors,
quotients and remainders, but 32-bit dividends. If I were writing in
assembly language, I would use the instructions that divide 16 bits
into 32.

But when I write in C, I'm forced to use the ldiv function, since one
of the operands is 32-bits. (Let's say int=16-bit and long=32-bit, as
on my machine.) Then the compiler has to implement this ldiv function
by using the instruction that divides 32-bits into 64-bits, since the
divisor is now 32-bits. In other words, the compiled code is forced to
use a divide instruction with operands twice as large as needed, due to
the design of the div and ldiv functions.

Anybody know a way around this (apart from inserting assembly code in
my C program)?

Thanks in advance...

[Jordan Abel]

On 2006-01-13, ne*****@wigner. berkeley.edu <ne*****@wigner .berkeley.edu> wrote:

I can't find any discussion of this question in this NG.

I'd like to implement some variable precision integer arithmetic in C,
and do it efficiently. A problem arises with the divide/remainder
operations. I'm using gcc on x86, but a lot of what I say applies to
other architectures.

First, I assume the div and ldiv functions are more efficient than
using / and % (obviously it depends on the compiler and level of
optimization, but it's one operation instead of two).
Not really - it requires a function call and use of a structure, and any
compiler should optimize use of / and % with the same operands anyway.
But when I write in C, I'm forced to use the ldiv function, since one
of the operands is 32-bits. (Let's say int=16-bit and long=32-bit, as
on my machine.) Then the compiler has to implement this ldiv function
by using the instruction that divides 32-bits into 64-bits, since the
divisor is now 32-bits. In other words, the compiled code is forced to
use a divide instruction with operands twice as large as needed, due to
the design of the div and ldiv functions.
i'm pretty sure that there are instructions on x86 take 32 bits for both
operands.
Anybody know a way around this (apart from inserting assembly code in
my C program)?

just use / and %.

[nessuno]

You are right. Suppose I have declarations
unsigned int quot,rem,dvsr;
unsigned long dvnd;
and then I say
quot=dvnd/dvsr;
rem =dvnd%dvsr;

If the compiler is smart enough to generate a single divide instruction
(that's all that's required on the x86 hardware), then I have what I
want.

Maybe I will try to figure out how to list assembly output from gcc to
see what instructions it actually generates.

Thanks for the reply!

[Jordan Abel]

On 2006-01-14, ne*****@wigner. berkeley.edu <ne*****@wigner .berkeley.edu> wrote:

Maybe I will try to figure out how to list assembly output from gcc to
see what instructions it actually generates.

<OT>gcc -S</OT>

[Keith Thompson]

ne*****@wigner. berkeley.edu writes:

You are right. [...]

About what? Most of us can't easily see the article to which you're
replying. Please read <http://cfaj.freeshell. org/google/>.

[...]
Maybe I will try to figure out how to list assembly output from gcc to
see what instructions it actually generates.

<OT>
gcc -S
</OT>

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[James Dow Allen]

Jordan Abel wrote:

On 2006-01-13, ne*****@wigner. berkeley.edu <ne*****@wigner .berkeley.edu> wrote:

First, I assume the div and ldiv functions are more efficient than
using / and % (obviously it depends on the compiler and level of
optimization, but it's one operation instead of two).

Not really - it requires a function call and use of a structure, and any
compiler should optimize use of / and % with the same operands anyway.

just use / and %.

Some of the responses make me wonder if your question was understood.
You want both "/" and "%" but don't want to needlessly repeat the
division. Do compilers find this optimization?

Someone from Sun implies that speed comparison tests are appropriate.
He should preach this in-house. It was trivial to beat memcpy() on
Sun-3 (which was optimized for Sun-2). The early Sparc's integer
multiply
could not only be bettered by rewriting the assembly, it *could be
beaten
without assembly in a C routine!* (In either way the speed improvement
was huge.)

James

[Chuck F.]

Keith Thompson wrote:

ne*****@wigner. berkeley.edu writes:

[...]

Maybe I will try to figure out how to list assembly output from gcc to
see what instructions it actually generates.

<OT>
gcc -S
</OT>

I use: gcc -gstabs+ -Wa,-ahldn -c

and pipe the result to less.

--
"If you want to post a followup via groups.google.c om, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell. org/google/>

[Logan Shaw]

James Dow Allen wrote:

Someone from Sun implies that speed comparison tests are appropriate.
He should preach this in-house. It was trivial to beat memcpy() on
Sun-3 (which was optimized for Sun-2).

How many employees from 20 years ago do you think are still there? :-)

- Logan