how to compute 64 bit result from 2 32 bit values

[Guest]

Harald van Dijk wrote, On 10/02/07 23:58:

Still not necessarily -1 though.

Correct. Joe Wright added "on your system" in his message for thar
reason, and I copied that in my reply.

Think of sign-magnitude or ones
complement machines (not that I have come across any)

It's not even necessarily -1 on all two's complement machines.

 

[Old Wolf]

It would be an unusual implementation on which it's possible to have
an integer value that's out of range for any floating-point type.

True, but irrelevant. The issue is when you have a floating point
value that is out of range for an integral type.

FLT_MAX is at least 1E+37, which can be represented as an integer in
123 bits (124 bits if it's signed). It's certainly *possible* that a
float-to-integer conversion might overflow, but it's not likely on
realistic implementations.

Not sure what you meant to write here. Since FLT_MAX is so large, as
you say, a float-to-integer conversion could easily fail with the
value being out of the range of integer. On the other hand, an
integer to float conversion would be unlikely to fail, for the
reason you describe.

 

[Thomas Dickey]

However, if you don't mind a little bit of inefficiency, you can figure out
INDIRECTLY if a carry occurred. On a standard 2's complement machine, note

"standard 2's complement machine" is out of scope(*) for comp.lang.c

ymmv

(*) aka "nonstandard" according to frequent-posters ;-)

 

[Keith Thompson]

True, but irrelevant. The issue is when you have a floating point
value that is out of range for an integral type.

You're right; I somehow managed to reverse it in my head.

Not sure what you meant to write here. Since FLT_MAX is so large, as
you say, a float-to-integer conversion could easily fail with the
value being out of the range of integer. On the other hand, an
integer to float conversion would be unlikely to fail, for the
reason you describe.

What I *meant* to write was integer-to-float, which is, as you point
out, irrelevant.

Never mind.

 

[CBFalconer]

"standard 2's complement machine" is out of scope(*) for comp.lang.c

But, for unsigned integers (which he specified) the advice holds.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

 

[David T. Ashley]

Hi,
I am trying to compute a 64 bit result from 2 32 bit
registers, How do I get the carry into the higher word ?

Generally, C destroys the carry (you can't get at this result directly). If
you want efficiency, use assembly-language where you can use the carry.

However, if you don't mind a little bit of inefficiency, you can figure out
INDIRECTLY if a carry occurred. On a standard 2's complement machine, note
that for two unsigned integers of the same size, a carry occurred if and
only if the sum is less than both of the operands.

For example, this would work just fine:

unsigned int x, y, z;
....
z = x + y;
if (z < x) ...

If you look at the GMP, for example, in the code that is used if no
assembly-language is available for the target processor, it uses such tests.

So, here is what you're looking for:

void add(unsigned x, unsigned y, unsigned *out_msb, unsigned *out_lsb)
{
unsigned z;

*out_lsb = z = x + y;

if (z < x)
*out_msb = 1;
else
*out_msb = 0;
}

 

[Flash Gordon]

Thomas Dickey wrote, On 11/02/07 21:00:

"standard 2's complement machine" is out of scope(*) for comp.lang.c

ymmv

Actually, David's code used unsigned int so it did not rely on 2's
complement and would behave the same on any conforming C implementation.

(*) aka "nonstandard" according to frequent-posters ;-)

Not nonstandard, as the standard explicitly allows it, just not required
by the standard

 

[David T. Ashley]

However, if you don't mind a little bit of inefficiency, you can figure
out INDIRECTLY if a carry occurred. On a standard 2's complement machine,
note that for two unsigned integers of the same size, a carry occurred if
and only if the sum is less than both of the operands.

I did make a small booboo in that statement. It is technically true, but
misleading.

Note that with two unsigned integers a and b, and an unsigned integer result
formed by adding the two (call it c), it is technically impossible that

a < c < b

So, saying that "sum is less than both of the operands" is equivalent to
saying "sum is less than either of the operands".

The sum is either:

#1)Greater than or equal to both, OR

#2)Less than both.

Hence the single test for carry is adequate.

(c < a) will do.

(c < b) will do.

((c < a) && (c < b)) is not necessary ...