
"Phil Endecott" <spam_from_boost_dev@chezphil.org> 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. Regards, Maurizio