Re: [boost] Some follow-up on my fixed point code, and safe integers

From: Maurizio Vitale (mav_at_[hidden])
Date: 2007-04-26 14:48:47

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

>> Btw, X86_64 gives you 64x64->128, I think.
>
> That's interesting.  Is there any way to use that from C++?  

Well, not directly as there's no 128-bit datatype were to store the result, but
the instruction mulq rx (pseudo-syntax) multiplies the 64-bit in rax by the 64 bit
in rx and stores the result in (dx,ax). So an inlined function with asm and the 
appropriate constraints could store the result in two longs.

Then there's an imul instruction for signed quantities, where if you are willing
to pay for longer opcodes (and don't know the implication in execution speeds) you
have more flexibility on where to store instruction.

It might even be that GCC defines those operations as intrinsics, but haven't checked
this.

> Yes.  Storing a 32-bit safe_int in 32 bits is significantly harder than 
> storing a 31-bit one, however you do it.  I believe that most of the 
> time when we ask the compiler for an 'int', we don't really care 
> exactly how many bits it has and making a 31-bit value your default 
> safe_int so that it can use the relatively easy guard bit 
> implementation would be a good enough solution.

In general I agree, but my application is modeling hardware and people would be surprised
if the object modeling their 32 bit register ends up being 8 byte long, so in my implementation
I'll take one of the approaches I've outlined, and look at the carry and overflow bits.
This will make my library a tad more difficult to port, but for now I'm focusing on
X86_64 and GCC.

Regards,

        Maurizio