473,388 Members | 1,956 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,388 software developers and data experts.

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 4289
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 thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

21
by: Stephen Biggs | last post by:
Given this code: void f(void){} int main(void){return (int)f+5;} Is there anything wrong with this in terms of the standards? Is this legal C code? One compiler I'm working with compiles this...
5
by: joshc | last post by:
After reading the Standard section 6.3 multiple times and consulting K&R I can't seem to figure out what would happen in the following case assuming longs are 32 bits(have typedefs for this): ...
43
by: Mehta Shailendrakumar | last post by:
Hello, Can anyone suggest me operator to perform arithmetic shift in C? May it be for a perticular compiler. Thank you in advance. Regards, Shailendra
6
by: Francois Grieu | last post by:
Are these programs correct ? #include <stdio.h> unsigned char a = {1,2}; int main(void) { unsigned char j; for(j=1; j<=2; ++j) printf("%u\n", *( a+j-1 )); return 0; }
7
by: barikat | last post by:
int a; int *Ptr1, *Ptr2; Ptr1 = a; Ptr1++; Ptr2 = a; printf("Ptr1 : %p\n", Ptr1); printf("Ptr2 : %p\n\n", Ptr2);
26
by: Bill Reid | last post by:
Bear with me, as I am not a "professional" programmer, but I was working on part of program that reads parts of four text files into a buffer which I re-allocate the size as I read each file. I...
2
by: jbe3d | last post by:
Here is a snippet of code that returns 0 (c = any number) d = 5 / 9 * (c-32); here it works as I expect it should, resulting in the expected numeric value d = (c-32) * 5 / 9; I'm spending...
7
by: Hallvard B Furuseth | last post by:
I'm trying to clean up a program which does arithmetic on text file positions, and also reads text files in binary mode. I can't easily get rid of it all, so I'm wondering which of the following...
27
by: jacob navia | last post by:
As Richard Bos rightly pointed out, I had left in my classification of types the C99 types Complex and boolean. Here is a new classification. Those are not mentioned in the classification of...
7
by: GCRhoads | last post by:
I'm looking for a very basic high-precision arithmetic library. I need to be able to specify a fixed number of bits or decimal digits (32 decimal digits should be all I need). The only arithmetic...
0
by: Charles Arthur | last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
0
by: ryjfgjl | last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
0
by: emmanuelkatto | last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud. Please let me know. Thanks! Emmanuel
0
BarryA
by: BarryA | last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
1
by: nemocccc | last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
1
by: Sonnysonu | last post by:
This is the data of csv file 1 2 3 1 2 3 1 2 3 1 2 3 2 3 2 3 3 the lengths should be different i have to store the data by column-wise with in the specific length. suppose the i have to...
0
by: Hystou | last post by:
There are some requirements for setting up RAID: 1. The motherboard and BIOS support RAID configuration. 2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
0
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
0
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers,...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.