Re: Why is UInt32 << 32 a no-op?
Re: Why is UInt32 << 32 a no-op?
- Subject: Re: Why is UInt32 << 32 a no-op?
- From: Jonas Maebe <email@hidden>
- Date: Tue, 17 Nov 2009 23:28:57 +0100
On 17 Nov 2009, at 23:06, Jens Ayton wrote:
> On Nov 17, 2009, at 19:28, Alastair Houghton wrote:
>>
>>
>> The reason, of course, is that some hardware has this limitation, whereas other hardware does not. The most likely two results you'd see are (a) a shift of (shift2), or (b) 0, if shift >= 32. Some architectures (and I have a suspicion that PowerPC may be one of them) may not even define which is to be expected at the assembly level, and may leave it to individual implementations even there.
>
> Not PowerPC, no.
>
> rlwnm[.] rA,rS,rB,MB,ME:
> "The contents of rS are rotated left the number of bits specified by the low-order five bits of rB."
rlwnm cannot be used for a variable shift left on ppc (since MB and ME are constants). You have to use slw instead, and that one makes the result 0 if bit 58 is 1 (IBM always numbers bits starting from the most significant bit, so that bit corresponds to 1 << 5). Note that this is *only* about that bit, so if you e.g. do a shift left by 10000, then the result won't be 0 (but "x << (1000 % 32)")
Here's the logic from the manual:
slw[.] rA,rS,rB
n ← rB[59–63]
r ← ROTL[32](rS[32–63], n)
if rB[58] = 0 then
m ← MASK(32, 63 – n)
else
m ← (64)0
rA ← r & m
So while the behaviour is defined, it will get you 0 for "<< 32".
Jonas _______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden