Boost logo

Boost :

From: james.jones_at_[hidden]
Date: 2007-04-27 10:56:12


From: "Phil Endecott" <spam_from_boost_dev_at_[hidden]>
> That's interesting. Is there any way to use that from C++? Of course,
> it also has a relatively efficient 32x32->64 because it has a single
> instruction for 64x64->64. So any code for this problem would have to
> be architecture-specific. But here is the sort of thing that I am
> thinking about for machines that only have 32x32->32:
>
> In these figures, each letter represents 16 bits.
>
> If I want to do 32x32->64, I need to break up the two operands into two
> 16-bit portions and do this calculation:
>
> A B
> x C D
> ---------
> B*D
> A*D
> C*B
> A*C
> ---------

You could also do it with NO multiplications by shifting one of the operands and adding or not adding it to an accumulator depending on a bit test of the other operand. Of course, integer multiply is fast enough in modern CPUs that this might not help.

> (Is this sort of integer arithmetic of interest to people, other than
> as the implementation of fixed point? I believe there was a big-int
> SoC proposal; does that overlap with this?)

It's really interesting to me, which is why I keep talking about my proposal for a decimal library. The algorithms are more general than the sort of fixed-point library you're working on (but also slower), and the use case is slightly different, but the two are related in the sense that they both work essentially with integer math.

Incidentally, I have some ideas on how to implement all or at least some of the <cmath> functions in a fixed-point library. This has already come up in my decimal library.

-
James Jones Administrative Data Mgmt.
Webmaster 375 Raritan Center Pkwy, Suite A
Data Architect Edison, NJ 08837


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk