lkml.org 
[lkml]   [1998]   [Apr]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Ext2 patches
On Sat, Apr 11, 1998 at 04:43:33PM -0400, tytso@mit.edu wrote:

> Date: Thu, 09 Apr 1998 21:08:17 -0400
> From: Joseph Malicki <jmalicki@geocities.com>
>
> Well, I was wrong...... but it still is defined in the Intel
> architecture, at least >>according to Intel<<, I havent had a chance
> to try it in assembly.... Intel says the mask all bit shifts by
> 0x01F, so x >> 32 will become x >> 0
>
> According to Intel that's what the shift right instruction does.
> However, there's no guarantee that the C >> operator is mapped to the
> Intel i386 right shift instruction.
>
> The ANSI C standard says that x >> 32 is undefined on 32 bit platforms.
> That means that a C compiler that replaced the expression x >> 32 with
> PI, E, or some other random number would be ANSI C compliant. It would
> be user hostile, but still standards compliant.

Maybe it's useful to explain people why the standard had to implement things
as they are. That way they can also see that and why they're not even going
to be on the safe side within the same architecture.

Most architectures feature shift instructions for which the shift count is
a number in a register. Usually this shift count is used as the input
into a barrel shifter. As side effect of this implementation most of these
architectures will actually execute value >> shift_count as something like

value >> (shift_count % (sizeof(register) * BIT_PER_BYTE))

with interesting consequences. Using these variable count shift instructions

value >> shift_count == value >> (shift_count + 32)

is actually always true.

That was obvious? Then take a look at m68k. They actually implement
variable shift counts as

value >> (shift_count % 64)

Yes, Motorola had planned for 64 bit extensions of the architecture back in
'79 or so. The most funny architecture with rsp. to shifts were the
transputers. Dunno if all of them are affected but some actually implement
value >> shift_count as

i = shift_count;
temp = value;
while (temp--)
temp >>= 1;
return temp;

Which means a variable count shift instructions of 2^32-1 bits may take almost
three minutes to complete at 25MHz ...

In short the is a lot of wirdness hidden in the hardware out there and you
may get caught easily because nothing guarantess you that the compiler will
pick the right instruction for you that you were speculation at. All this
hardware headacke also made the ANSI comitee decide that the behaviour of
such shifts is undefined. Compilers can make ``interesting'' use of this
undefined beaviour as Theodore Tso already pointed out above.

ANSI could have spec'd another reasonable behaviour like implementing things
as

value >> (shift_count % (sizeof(register) * BIT_PER_BYTE))

but that would have forced compilers to generate additional code for many
architectures which was considered worse.

For more fun with shifts try to research the behaviour of >> with respect to
the sign bit. It's also undefined and some compilers will implement this
as arithmetic shifts, others as logic shifts.

Ralf

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.069 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site