Boost logo

Boost :

From: Maurizio Vitale (mav_at_[hidden])
Date: 2007-04-26 10:57:53

"Phil Endecott" <spam_from_boost_dev_at_[hidden]> writes:

> The other main issues that were raised were:
> - The alternative approach of using proto to provide something more
> sophisticated. I would be very interested to see what can be achieved
> by this approach (and at what cost) compared to my simplistic version.

I'm still working on this, a bit slowed down by the complexity of the
SystemC datatype spec.
I'll make the source code available asap, maybe integer first and real
fixed point later.

I will actually have two separate proto contexes: one in which user
expressions are evaluated and one in which internal expressions
(overflow and quantization) are evaluated. The former is what one would expect,
the latter knows about special terminals like "MSB of the protion discarded
by quantization" and many others, with as much as possible done at
compile time.

> - My concerns about how to do, for example, a 32x32->64-bit multiply
> efficiently without actually doing a 64x64->64-bit multiply.

I don't see too many ways out. One thing people do is to shift right
by 16 both operands, do a 16x16->32 and then shift the result left
by 32. (e.g. compute (x/2^16 * y/2^16)*2^32).
This maintains at least the magnitude of the result, but whether it is
acceptable or not depends on the application domain.

Btw, X86_64 gives you 64x64->128, I think.
But yes, on other architectures you might have the problem.

I've seen in your code that you allocate one more bit than requested by the
user in order to detect overflow. As you note this is problematic when you hit
the machine operand length. In those cases, besides checking the msbs before
and after you can also use the carry flag. It can be accessed through
inline asm instruction, or used implicitely via conditional branches and
conditional moves.



Boost list run by bdawes at, gregod at, cpdaniel at, john at