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...
Can someone enlighten me (with CC' as I am not subscribed) ?
Nico
On Thu, 20 Nov 2003 12:02 pm, 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.
I may be wrong, but afaik the 0xff's are there to truncate the other values to
8-bit. 0xff == 0b11111111, which is 8-bit.
>From the bitshifting above, cpu_rev seems to be a 32-bit value, so the four
sections of cpu_rev (>>24, >>16, >>8 and >>0) are being ANDed with 0xff to
show only the 8 low bits (post-shift).
>
> And I don't understand why we do this for 8bit and shifting the
> cpu_rev...
>
> Can someone enlighten me (with CC' as I am not subscribed) ?
>
> Nico
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Ben
Ben Collins wrote:
> And (0 & 1) makes 1, not 0. That's an AND, not an OR.
Not quite Ben... 0 & _anything_ is still 0.
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/
EDIT: Oops, meant to reply-all. Apologies Ben.
On Thu, 20 Nov 2003 12:53 pm, Ben Collins wrote:
> 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.
I'm willing to put some safe money on (0 & 1) equalling 0.
It has to, for your explanation below to work. :)
>
> 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
--
Ben
Quoting Ben Collins <[email protected]>:
> 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.
Last I checked, 0 AND anything is 0. Think of it this way:
A B A & B
------------
T F F
T T T
F T F
F F F
So, anything ANDed with F is false.
-sandalle
--
PGP Key Fingerprint: FCFF 26A1 BE21 08F4 BB91 FAED 1D7B 7D74 A8EF DD61
http://search.keyserver.net:11371/pks/lookup?op=get&search=0xA8EFDD61
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/E/IT$ d-- s++:+>: a-- C++(+++) BL++++VIS>$ P+(++) L+++ E-(---) W++ N+@ o?
K? w++++>-- O M-@ V-- PS+(+++) PE(-) Y++(+) PGP++(+) t+() 5++ X(+) R+(++)
tv(--)b++(+++) DI+@ D++(+++) G>+++ e>+++ h---(++) r++ y+
------END GEEK CODE BLOCK------
Eric Sandall | Source Mage GNU/Linux Developer
[email protected] | http://www.sourcemage.org/
http://eric.sandall.us/ | SysAdmin @ Inst. Shock Physics @ WSU
http://counter.li.org/ #196285 | http://www.shock.wsu.edu/
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
Thank you all guys for your answers, it looks like it was
more obvious I would like to admit.
So to recapitulate it, the and with the 0xff 8-Bit value
with an 32Bit Value let's us cut out values, to cut within
a value 'with a pair of scissors' like this:
0x AA BB CC DD
| | | |
| 0xBB| 0xDD
0xAA 0xCC
Have a nice day, I will read on the small transmeta code...
I am still interested whether there are possibilities to
a) use the crusoe without the morphing software (to use its native
command set)
b) to fine tune Linux to my specific processor, to make it use all
available feautures the processor has.
Nico
On Wed, Nov 19, 2003 at 08:06:50PM -0700, Kevin P. Fleming wrote:
> Ben Collins wrote:
>
> >And (0 & 1) makes 1, not 0. That's an AND, not an OR.
>
> Not quite Ben... 0 & _anything_ is still 0.
Typing too fast. Brain running slow. That's what I get.
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/
Followup to: <[email protected]>
By author: Nico Schottelius <[email protected]>
In newsgroup: linux.dev.kernel
>
> I am still interested whether there are possibilities to
> a) use the crusoe without the morphing software (to use its native
> command set)
No. You really don't want to -- the native instruction set doesn't
look like anything Linux likes to see, and worse, there are binary
incompatibilities not just from processor to processor but sometimes
from silicon revision to silicon revision.
It's also not faster in any meaningful way, since the dynamic
translator does optimistic optimization.
> b) to fine tune Linux to my specific processor, to make it use all
> available feautures the processor has.
The biggest problem we've found is that a lot of distributions will
install an i586 libc even though we have (and export) all the
necessary features. Crusoe reports family = 5 mainly to work around a
bug in Some Other Operating System[TM], but supports all
userspace-visible i686 features gcc expects.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
If you send me mail in HTML format I will assume it's spam.
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64
H. Peter Anvin wrote:
> It's also not faster in any meaningful way, since the dynamic
> translator does optimistic optimization.
Statically compiled code for the Crusoe chips may not be faster.
(Arguably statically compiled code for _any_ CPU is not the best
strategy for fast code).
But if someone is able to write better code morphing software than
Transmeta, that would be faster :)
-- Jamie
Quote from Jamie Lokier <[email protected]>:
> H. Peter Anvin wrote:
> > It's also not faster in any meaningful way, since the dynamic
> > translator does optimistic optimization.
>
> Statically compiled code for the Crusoe chips may not be faster.
> (Arguably statically compiled code for _any_ CPU is not the best
> strategy for fast code).
>
> But if someone is able to write better code morphing software than
> Transmeta, that would be faster :)
The idea of a CMS which only implemented the subset of X86
instructions that gcc actually uses was discussed on the list a few
months ago, but unsuprisingly it never progressed beyond the thought
experiment stage.
John.
John Bradford wrote:
> > > It's also not faster in any meaningful way, since the dynamic
> > > translator does optimistic optimization.
> >
> > Statically compiled code for the Crusoe chips may not be faster.
> > (Arguably statically compiled code for _any_ CPU is not the best
> > strategy for fast code).
> >
> > But if someone is able to write better code morphing software than
> > Transmeta, that would be faster :)
>
> The idea of a CMS which only implemented the subset of X86
> instructions that gcc actually uses was discussed on the list a few
> months ago, but unsuprisingly it never progressed beyond the thought
> experiment stage.
What would be the point in that? Surely the CMS overhead for decoding
the rarely used x86 instructions is negligable, precisely because of
their rarity?
-- Jamie
Followup to: <[email protected]>
By author: Jamie Lokier <[email protected]>
In newsgroup: linux.dev.kernel
>
> What would be the point in that? Surely the CMS overhead for decoding
> the rarely used x86 instructions is negligable, precisely because of
> their rarity?
>
Pretty much.
The bulk of the time spent in CMS is in the backend scheduler, at
which time the original x86 instructions are pretty much
unrecognizable.
If there is something that one could imagine doing at the CMS level to
help on Linux, it would probably be something like making it optional
to actually perform stores beneath the stack pointer, in which case a
lot of stack frame operations could be done purely in registers. CMS
will do them in registers already, but will be forced to perform a
store at the end of the translation anyway in order to keep exact x86
semantics.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
If you send me mail in HTML format I will assume it's spam.
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64
H. Peter Anvin wrote:
> If there is something that one could imagine doing at the CMS level to
> help on Linux, it would probably be something like making it optional
> to actually perform stores beneath the stack pointer, in which case a
> lot of stack frame operations could be done purely in registers. CMS
> will do them in registers already, but will be forced to perform a
> store at the end of the translation anyway in order to keep exact x86
> semantics.
You couldn't enable that globally, because it'd break userspace
programs which write below the stack safely using sigaltstack(), or
which even use the stack pointer as a general purpose register (I've
coded games which do that in tight rendering loops), or during funky
thunking code.
It sounds like a good thing to add as a per-task feature though.
-- Jamie