Re: Long unsigned integer math library

[David Holland <dholland-tech%netbsd.org@localhost>]

On Wed, Apr 14, 2010 at 12:42:39PM +0800, Dennis Ferguson wrote:
 > I'm wondering if there is any interest in the library whose man
 > page is attached, as I would like to donate it. It provides very
 > limited (but still quite useful) support for operations involving
 > 128 bit unsigned integers, and the functions implement operations
 > which are exactly those you would like to have efficiently done if
 > you are trying to write a more general library to deal with long
 > integers.  I haven't found similar library support anywhere,
 > though I may be missing something.

There is similar code in src/common/lib/libc/quad, which provides
64-bit operations in terms of pairs of 32-bit values, using the symbol
names expected by gcc-generated code.

Much of that code could be reused to do 128-bit operations in terms of
pairs of 64-bit values. However, that would work most naturally in
tandem with 128-bit integer value support in gcc, which I don't think
anyone (or at least, anyone around here) has looked at much.

In the absence of compiler-level support it would probably be nice to
have a library interface.

The question I see is whether on a 32-bit machine without much in the
way of native 64-bit ops it makes sense to stack 128-bit code on top
of 64-bit code; at least for the less trivial operations it seems like
that would introduce fairly significant overheads compared to an
128-bit implementation using 4x 32-bit values. But the latter would
also be a fairly large pain to implement.

 > The reason I'd like to donate it is a little bit selfish.  While
 > I have decent, portable C language code for all the functions the
 > end result can be much improved if you can #include inline
 > definitions for those operations which are supported directly
 > by the hardware in the machine you are running on, and most CPU
 > architectures provide support for at least a few of them (x86_64
 > can inline all of them, most to single instructions).

This is a strong argument for hacking up the compiler support...

-- 
David A. Holland
dholland%netbsd.org@localhost