Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: kernel/microcode.c error from new 64bit code
Original-Message-ID: <Pine.LNX.4.58.0402210914530.3301@ppc970.osdl.org>
Date: Sat, 21 Feb 2004 17:15:02 GMT
Message-ID: <fa.guu1tm2.8i0qhi@ifi.uio.no>

On Sat, 21 Feb 2004, Pavel Machek wrote:
>
> > +	wrmsr(MSR_IA32_UCODE_WRITE,
> > +		(unsigned long) uci->mc->bits,
> > +		(unsigned long) uci->mc->bits >> 16 >> 16);
> 				             ~~~~~~~~~~~~
>
> I see what you are doing, but this is evil. At least comment /* ">> 32"
> is undefined on i386 */ ?

Sorry, but you're wrong.

">> 32" is undefined PERIOD! It has nothing to do with x86, it's a C
standards issue. It's undefined on any 32-bit architecture. (shifting by
the wordsize or bigger is simply not a defined C operation).

The above is not evil. The above is the standard way of doing this in C if
you know the word-size is 32-bits or bigger.

		Linus

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: kernel/microcode.c error from new 64bit code
Original-Message-ID: <Pine.LNX.4.58.0402210944050.3301@ppc970.osdl.org>
Date: Sat, 21 Feb 2004 17:40:59 GMT
Message-ID: <fa.gse5ue2.a2crpi@ifi.uio.no>

On Sat, 21 Feb 2004, Pavel Machek wrote:
>
> I'm just afraid that someone will mail you a patch replacing that with
> >> 32 and you'll overlook it.

Well, the good news is that ">> 32" should cause gcc to complain with a
big warning (exactly because it's undefined behaviour on a 32-bit
architecture), so I don't think it's easy to overlook.

		Linus

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: kernel/microcode.c error from new 64bit code
Original-Message-ID: <Pine.LNX.4.58.0402221230390.1395@ppc970.osdl.org>
Date: Sun, 22 Feb 2004 20:29:05 GMT
Message-ID: <fa.gte00e3.a22o9h@ifi.uio.no>

On Sun, 22 Feb 2004, H. Peter Anvin wrote:
>
> The above code is just plain wrong: the cast to (unsigned long) has
> higher precedence than the shift, so on i386 (which I presume this is)
> it will become an unsigned long, and the shifts will bring it down to
> zero.

WHICH IS WHAT WE WANT. On x86.

But ..

> You might as well write zero if that's what you mean.

No. Because on x86-64 it is NOT zero. Because there "unsigned long" is
64-bit, and it results in the high 32 bits. Which is, again, exactly what
we want.

Guys, give it up. The code is not only already committed, it's simply the
best way to do what it does.

		Linus