Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Assigning unsigned long to unsigned long long

Reply
Thread Tools

Assigning unsigned long to unsigned long long

 
 
George Marsaglia
Guest
Posts: n/a
 
      07-08-2003
The essence of a multiply-with-carry RNG is to have
declarations in the RNG proc, such as

unsigned long mwc( ){
static unsigned long x = 123456789, c = 362436;
unsigned long long t, a = 916905990LL;
\*
then reatedly form the 64-bit t = a*x+c, after which
the new carry c is the top 32,
and the new x (output), is the bottom 32 bits of t:
*/
t = a*x+c; c = t>>32; return x=t ;
}

Some compilers may give a warning for
assigning an unsigned long to an unsigned long long.
If so, would casting,
x=(unsigned long),
or chopping,
x=t&0xffffffff;
supress such warnings?
Would some compilers balk at the assignment
x=t; ?

Warnings aside, in machines for which
unsigned longs are 32 bits and
unsigned long longs are 64,
would the three versions
x = t;
x = (unsigned long) t;
x = t&0xffffffff;
all produce the required result: the bottom 32-bits of t?


Is the assembler code likely to differ?

I use gcc via djgpp in DOS, and x = t; works as expected,
with no warnings when compiled with the -Wall option.

George Marsaglia



 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      07-08-2003
George Marsaglia wrote:
>
> The essence of a multiply-with-carry RNG is to have
> declarations in the RNG proc, such as
>
> unsigned long mwc( ){
> static unsigned long x = 123456789, c = 362436;
> unsigned long long t, a = 916905990LL;
> \*
> then reatedly form the 64-bit t = a*x+c, after which
> the new carry c is the top 32,
> and the new x (output), is the bottom 32 bits of t:
> */
> t = a*x+c; c = t>>32; return x=t ;
> }
>
> Some compilers may give a warning for
> assigning an unsigned long to an unsigned long long.
> If so, would casting,
> x=(unsigned long),
> or chopping,
> x=t&0xffffffff;
> supress such warnings?


Compilers can issue whatever diagnostics they feel
like: "suspicious" conversions, comparisons of unsigned
integers to negative numbers, or spellnig errors in your
comments. There is no particular language construct that
is guaranteed to shut up all compilers all the time.

That said, the cast is more likely than the mask to
quiet a compiler's squeaky wheels. The masking operation
produces the result you desire, but the type will still
be u.l.l. -- and a compiler that likes to complain about
type demotions is still likely to do so, not realizing
that in the case at hand no damage can occur. (True story:
a certain compiler once complained about `float f = 0.0;'
on the grounds that demotion from `double' to `float' might
lose precision; I had to rewrite as `float f = 0.0f;' to
get it to shut its stupid mouth ...). Of course, even with
the cast the compiler may still bitch about the phase of
the moon or something.

> Would some compilers balk at the assignment
> x=t; ?


Some might. They've got to accept and execute the code
(absent any other problems), but they're free to whinge.
A cast may or may not shut 'em up.

> Warnings aside, in machines for which
> unsigned longs are 32 bits and
> unsigned long longs are 64,
> would the three versions
> x = t;
> x = (unsigned long) t;
> x = t&0xffffffff;
> all produce the required result: the bottom 32-bits of t?


Yes. The first two differ only in that the conversion
is implicit in the first and explicit in the second; the
exact same conversion occurs anyhow. The third develops
the value in u.l.l. form and then demotes it to u.l. without
further change. All three assign the same value to `x'.

> Is the assembler code likely to differ?


Yes. No. Maybe. And that's definite! At a guess, the
mask version might be different from the other two -- but
it's even in the realm of possibility that three entirely
different instruction sequences might be generated.

> I use gcc via djgpp in DOS, and x = t; works as expected,
> with no warnings when compiled with the -Wall option.


<off-topic>

I'd suggest using -W as well as -Wall -- I don't know
off-hand whether that would elicit additional diagnostics
for the case you mention, but it's occasionally saved me
from my own blunders. I've always been fond of encouraging
the compilers/linkers/assemblers/whatever to give me all
the constructive criticism they're capable of ...

</off-topic>

--
http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
(int) -> (unsigned) -> (int) or (unsigned) -> (int) -> (unsigned):I'll loose something? pozz C Programming 12 03-20-2011 11:32 PM
Assigning methods to objects, and assigning onreadystatechange to an XMLHttpRequest -- an inconsistency? weston Javascript 1 09-22-2006 09:33 AM
unsigned long long int to long double Daniel Rudy C Programming 5 09-20-2005 02:37 AM
unsigned long to unsigned char ashtonn@gmail.com Python 1 06-01-2005 07:00 PM
comparing unsigned long and unsigned int sridhar C Programming 6 11-03-2004 03:52 AM



Advertisments