468,491 Members | 1,952 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,491 developers. It's quick & easy.

Arithmetic for 32-bit and 64-bit machines

I understood that the CPU registers determine the size of the machine.
But what is the correct way to code an arithmetic operation to avoid
wrap-around when the code is to be run on both 32-bit and 64-bit
machines?

Example:

uint32_t x = SOME_LARGE_NO;
uint64_t y;
....

y = (uint64_t)(10000 * x); /* Will overflow occur before the cast? */
y = (int64_t)(x) * 10000; /* or, is it better to do the cast first?
*/

Please comment.

/Why Tea
Jan 9 '08 #1
10 4004
Why Tea <yt****@gmail.comwrites:
>I understood that the CPU registers determine the size of the machine.
But what is the correct way to code an arithmetic operation to avoid
wrap-around when the code is to be run on both 32-bit and 64-bit
machines?
>Example:
>uint32_t x = SOME_LARGE_NO;
uint64_t y;
...
>y = (uint64_t)(10000 * x); /* Will overflow occur before the cast? */
y = (int64_t)(x) * 10000; /* or, is it better to do the cast first?
*/
Why not perform all arithmetic in 64bits?

uint64_t x = SOME_LARGE_NO;
uint64_t y;

y = 10000 * x;
y = x * 10000;

--
Chris.
Jan 9 '08 #2
On Jan 9, 3:43 pm, Chris McDonald <ch...@csse.uwa.edu.auwrote:
Why Tea <ytl...@gmail.comwrites:
I understood that the CPU registers determine the size of the machine.
But what is the correct way to code an arithmetic operation to avoid
wrap-around when the code is to be run on both 32-bit and 64-bit
machines?
Example:
uint32_t x = SOME_LARGE_NO;
uint64_t y;
...
y = (uint64_t)(10000 * x); /* Will overflow occur before the cast? */
y = (int64_t)(x) * 10000; /* or, is it better to do the cast first?
*/

Why not perform all arithmetic in 64bits?

uint64_t x = SOME_LARGE_NO;
uint64_t y;

y = 10000 * x;
y = x * 10000;
Thanks Chris. But assuming the "x" is a 32-bit variable declared
somewhere else, and there is no easy way to change it to uint64_t; and
also it can be passed as a function parameter such as
some_func(1000*x,...), so what you mentioned would not work.

Let me rephrase the question:

void somefunc(uint64_t y, ....);
....

uint32_t x;
uint64_t y;
....
y = (uint64_t)(10000 * x); /* Will overflow occur before the cast? */
y = (int64_t)(x) * 10000; /* or, is it better to do the cast first?
*/
....
somefunc(1000*x,....); /* Overflow can occur here on 32-bit machine?
*/
...
Jan 9 '08 #3
Why Tea <yt****@gmail.comwrites:
>Thanks Chris. But assuming the "x" is a 32-bit variable declared
somewhere else, and there is no easy way to change it to uint64_t; and
also it can be passed as a function parameter such as
some_func(1000*x,...), so what you mentioned would not work.
>Let me rephrase the question:
>void somefunc(uint64_t y, ....);
...
>uint32_t x;
uint64_t y;
...
y = (uint64_t)(10000 * x); /* Will overflow occur before the cast? */
y = (int64_t)(x) * 10000; /* or, is it better to do the cast first?
*/
...
somefunc(1000*x,....); /* Overflow can occur here on 32-bit machine?
*/
..

Then quickly use: int64_t x64 = x;

If somefunc() is correctly prototyped and visible at the point of calling
it, 10000*x should be promoted to 64bits as

(10000LL * (int64_t)x).

--
Chris.
Jan 9 '08 #4
Why Tea wrote:
I understood that the CPU registers determine the size of the machine.
But what is the correct way to code an arithmetic operation to avoid
wrap-around when the code is to be run on both 32-bit and 64-bit
machines?

Example:

uint32_t x = SOME_LARGE_NO;
uint64_t y;
...

y = (uint64_t)(10000 * x); /* Will overflow occur before the cast? */
y = (int64_t)(x) * 10000; /* or, is it better to do the cast first?
*/

Please comment.

/Why Tea
Do operations in 64 bit arithmetic
The second is better. Or even better
y = (int64_t)(x) * 10000LL; /* put constant in 64 bits using LL
suffix */
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Jan 9 '08 #5
Why Tea wrote:
>
I understood that the CPU registers determine the size of the
machine. But what is the correct way to code an arithmetic
operation to avoid wrap-around when the code is to be run on
both 32-bit and 64-bit machines?

Example:

uint32_t x = SOME_LARGE_NO;
uint64_t y;
...

y = (uint64_t)(10000 * x); /* Will overflow occur before the cast? */
y = (int64_t)(x) * 10000; /* or, is it better to do the cast first? */
Yes and yes. For the first, within the parentheses you are
operating with integers, so overflow occurs, and the results are
undefined. For the second x is cast to long long, so to perform
arithmetic 10000 is automaticall also converted to long long, and
the arithmetic is done in long long.

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

Jan 9 '08 #6
On Jan 9, 12:08*am, CBFalconer <cbfalco...@yahoo.comwrote:
Why Tea wrote:
I understood that the CPU registers determine the size of the
machine. But what is the correct way to code an arithmetic
operation to avoid wrap-around when the code is to be run on
both 32-bit and 64-bit machines?
Example:
uint32_t x = SOME_LARGE_NO;
uint64_t y;
...
y = (uint64_t)(10000 * x); */* Will overflow occur before the cast? */
y = (int64_t)(x) * 10000; * /* or, is it better to do the cast first? */

Yes and yes. *For the first, within the parentheses you are
operating with integers, so overflow occurs, and the results are
undefined.
Since x has been declared as unsigned the results are perfectly
defined.
Jan 9 '08 #7
Why Tea wrote:
I understood that the CPU registers determine the size of the machine.
But what is the correct way to code an arithmetic operation to avoid
wrap-around when the code is to be run on both 32-bit and 64-bit
machines?

Example:

uint32_t x = SOME_LARGE_NO;
uint64_t y;
...

y = (uint64_t)(10000 * x); /* Will overflow occur before the cast? */
y = (int64_t)(x) * 10000; /* or, is it better to do the cast first?
*/
If ints are at least 64 bits, they are the same. Otherwise, the first will
yield a product which is either uint32_t or int, which ever is larger. The
second will yield a product which is uint64_t or int, whichever is larger.
The tie breaker goes to the unsigned type.

Bottom line: do the cast first.

--
Thad
Jan 9 '08 #8
Why Tea wrote:
I understood that the CPU registers determine the size of the
machine.
[OT: If you say so. Some people use the size of the address
bus, e.g. the original Macs used an m68k and was considered
a 16-bit machine even though registers are 32-bits.]
But what is the correct way to code an arithmetic
operation to avoid wrap-around
Do you mean unsigned modulo arithmetic?
when the code is to be run on both 32-
bit and 64-bit machines?
If you need a 64-bit result, then it doesn't matter whether
you're using a 32 or 64-bit machine, you use a 64-bit type,
if available.
Example:

uint32_t x = SOME_LARGE_NO;
uint64_t y;
Why are you using precise width types?
...

y = (uint64_t)(10000 * x); */* Will overflow occur before
the cast? */
Possibly.
y = (int64_t)(x) * 10000; * /* or, is it better to do the
cast first? */
Did you really mean to cast with (uint64_t)? Your cast will
work, but it's not obvious why you're switching between
signednesss.

The 'factor' of 10000 is enough to avoid overflow in either
case, but a more robust solution would be to preserve the
signness in cases where the factor might be (say) 0xF0000000.

jacob navia <ja...@nospam.comwrote:
Do operations in 64 *bit arithmetic
The second is better. Or even better
*y = (int64_t)(x) * 10000LL; */* put constant in 64 bits
using LL suffix */
How is this better? The presence of the cast on x means the
constant will be converted (if necessary) to a type that is
at least 64-bits anyway.

If the result is truly meant to be a 64-bit unsigned value
from a multiplication of two non-negative 32-bit values,
one of which is explicitly unsigned, then the following is
adequate...

y = x * 10000ull;

Even if unsigned long long is 128-bits (say), an optimiser
should be able to recognise that only 64-bits is significant
and a 64-bit calculation is all that is needed.

Alternatively...

y = x;
y *= 10000;

--
Peter
Jan 10 '08 #9
Spiros Bousbouras <spi...@gmail.comwrote:
CBFalconer <cbfalco...@yahoo.comwrote:
uint32_t x = SOME_LARGE_NO;
uint64_t y;
...
y = (uint64_t)(10000 * x); */* Will overflow occur before
the cast? */
y = (int64_t)(x) * 10000; * /* or, is it better to do the
cast first? */
Yes and yes. *For the first, within the parentheses you are
operating with integers, so overflow occurs, and the
results are undefined.

Since x has been declared as unsigned the results are
perfectly defined.
Not if (say) INT_MAX == 0x7FFFFFFFFF.

--
Peter
Jan 10 '08 #10

"Why Tea" <yt****@gmail.comwrote in message
news:a9**********************************@p69g2000 hsa.googlegroups.com...
>I understood that the CPU registers determine the size of the machine.
But what is the correct way to code an arithmetic operation to avoid
wrap-around when the code is to be run on both 32-bit and 64-bit
machines?
it depends on who you ask...

it is perfectly possible to have a 32 bit machine with some 64 or 128 bit
registers (as is the case with MMX and SSE).

the issue is not quite as clear-cut as it may seem.
Example:

uint32_t x = SOME_LARGE_NO;
uint64_t y;
...

y = (uint64_t)(10000 * x); /* Will overflow occur before the cast? */
y = (int64_t)(x) * 10000; /* or, is it better to do the cast first?
*/

Please comment.
my answer:
y = ((int64_t)x) * 10000;
reason:
casts change the output type, not the input type.

so, yeah, in the first case, the overflow may well occur before cast to the
larger type. however, afaik, what happens, exactly, is up to the compiler
(for example, it may internally upcast when loading, for example because the
arch may have a load-and-extend instruction, wheras to load and then up-cast
would involve additional instructions).

and so on...

/Why Tea
Jan 10 '08 #11

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

21 posts views Thread by Stephen Biggs | last post: by
43 posts views Thread by Mehta Shailendrakumar | last post: by
6 posts views Thread by Francois Grieu | last post: by
7 posts views Thread by barikat | last post: by
7 posts views Thread by Hallvard B Furuseth | last post: by
27 posts views Thread by jacob navia | last post: by
7 posts views Thread by GCRhoads | last post: by
reply views Thread by NPC403 | last post: by
3 posts views Thread by gieforce | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.