Date: Wed, 19 Nov 2003 21:53:15 -0500
From: Ben Collins <bcollins@debian.org>
To: Nico Schottelius <nico-mutt@schottelius.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: transmeta cpu code question
Message-ID: <20031120025315.GR11983@phunnypharm.org>
References: <20031120020218.GJ3748@schottelius.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20031120020218.GJ3748@schottelius.org>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1478
Lines: 48

On Thu, Nov 20, 2003 at 03:02:18AM +0100, Nico Schottelius wrote:
> Hello!
> 
> What does this do:
> 
>                 printk(KERN_INFO "CPU: Processor revision %u.%u.%u.%u,
> %u MHz\n",
>                        (cpu_rev >> 24) & 0xff,
>                        (cpu_rev >> 16) & 0xff,
>                        (cpu_rev >> 8) & 0xff,
>                        cpu_rev & 0xff,
>                        cpu_freq);
> 
> (from arch/i386/kernel/cpu/transmeta.c)
> 
> Does not & 0xff make no sense? 0 & 1 makes 0, 1 & 1 makes 1, 
> no changes.
>
> And I don't understand why we do this for 8bit and shifting the
> cpu_rev...

You are a bit confused. The cpu_rev is a 4 byte value, each byte is a
decimal of the revision.

And (0 & 1) makes 1, not 0. That's an AND, not an OR.

Think about it this way. If cpu_rev == 0x01040801, then this would
produce:

(0x01040801 >> 24 & 0xff) -> (0x01 & 0xff) ->     0x01

(0x01040801 >> 16 & 0xff) -> (0x0104 & 0xff) ->   0x04

(0x01040801 >> 8  & 0xff) -> (0x010408 & 0xff) -> 0x08

(0x01040801 & 0xff)                            -> 0x01


-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/