RE: 32-bit operations
- Posted by "Derek Parnell" <ddparnell at bigpond.com> Feb 27, 2004
- 432 views
> -----Original Message----- > From: Juergen Luethje [mailto:j.lue at gmx.de] > Subject: Re: 32-bit operations > > > > Derek wrote: > > > Hi all, > > it turns out that I can't use Juergen's routines after all. > I need to do > > arithetic that can have temporary values that extend beyond > Euphoria's > > 30-bit integer limit. Thanks to being reminded about the > bits_to_int() and > > int_to_bits() routines, I've come up with this little > function that gives me > > the correct values now. It seems to run fast enough for my uses too! > > > > global function ClipBits(atom pValue) > > if pValue > #FFFFFFFF or pValue < 0 then > > pValue = bits_to_int(int_to_bits(pValue,32)) > > end if > > return pValue > > end function > > My routines in 'bit.e' should handle any 32-bit signed or unsigned > integer. Agreed, however I still have to use an ATOM to hold a 32-bit integer. Euphoria's INTEGER doesn't work with more than 30 bits. > They were not designed to handle values > #FFFFFFFF, that are > beyond the 32-bit limit. The Euphoria wrapper functions use > user defined types, to catch those "oversized" parameters. That's my problem. For example, I've adding two 32-bit integers and I need to ignore overflow. Sure I can add two atoms together, but when I use you routines (eg. shift_left(x,0)) to strip off the overflow, I get a type-check error. I guess if you could include some addition and subtraction routines that ignore overflow/underflow situations, that would help. > > But the machine functions themselves seem to clip the parameters, like > you want. Using the following test program, I wasn't able to > generate an > error. What is/are the error/s that you get with 'bit.e', Derek? Type check errors. For example ... c:\dparnell\win32lib\include\bit.e:105 in function shift_left() type_check failure, a is -3141312130 and ... c:\dparnell\win32lib\include\bit.e:105 in function shift_left() type_check failure, a is 6010708479 But that's because I am using the function wrappers you supplied, and they do type checking on the parameters. When I use the c_func(SHIFT_LEFT,{...}) method it works fine. [snip] I now use this ... global function TEA_encypher(atom y, atom z, atom k1, atom k2, atom sum) -- The input parameters are all 32-bit unsigned integers. -- I return a 32-bit unsigned integer -- The seperate assignments are there to ensure that I -- don't lose any precision by simulating 32-bit UINTs -- with atoms. y = c_func(SHIFT_LEFT,{y + c_func(SHIFT_LEFT,{z,4}), 0}) y = c_func(SHIFT_LEFT,{y + xor_bits(k1, z), 0}) y = c_func(SHIFT_LEFT,{y + xor_bits(sum, c_func(SHIFT_RIGHT,{z,5})),0}) y = c_func(SHIFT_LEFT,{y + k2, 0}) return y end function Though if we had a 32-bit add I could do this instead... global function TEA_encypher(atom y, atom z, atom k1, atom k2, atom sum) -- The input parameters are all 32-bit unsigned integers. -- I return a 32-bit unsigned integer -- The seperate assignments are there to ensure that I -- don't lose any precision by simulating 32-bit UINTs -- with atoms. y = c_func(ADD32,{y, c_func(SHIFT_LEFT,{z,4})}) y = c_func(ADD32,{y, xor_bits(k1, z)}) y = c_func(ADD32,{y, xor_bits(sum, c_func(SHIFT_RIGHT,{z,5}))}) y = c_func(ADD32,{y, k2}) return y end function Thanks for the help. -- Derek