[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <527599002.20081210205651@emcraft.com>
Date: Wed, 10 Dec 2008 20:56:51 +0300
From: Yuri Tikhonov <yur@...raft.com>
To: Scott Wood <scottwood@...escale.com>
CC: Al Viro <viro@...IV.linux.org.uk>, Wolfgang Denk <wd@...x.de>,
Detlev Zundel <dzu@...x.de>, <linux-kernel@...r.kernel.org>,
Milton Miller <miltonm@....com>, <linuxppc-dev@...abs.org>,
Geert Uytterhoeven <Geert.Uytterhoeven@...ycom.com>,
Ilya Yanok <yanok@...raft.com>
Subject: Re[2]: [PATCH] fork_init: fix division by zero
Hello Scott,
On Wednesday, December 10, 2008 you wrote:
> On Wed, Dec 10, 2008 at 01:29:12PM +0300, Yuri Tikhonov wrote:
>> On Wednesday, December 10, 2008 you wrote:
>> > x * y / z is parsed as (x * y) / z, not x * (y / z).
>>
>> Here we believe in preprocessor: since all PAGE_SIZE, 8, and
>> THREAD_SIZE are the constants we expect it will calculate this.
>>
>> E.g. here is the result from this line as produced by cross-gcc
>> 4.2.2:
>>
>> lis r9,0
>> rlwinm r29,r29,2,16,29
>> stw r29,0(r9)
>>
>> As you see - only rotate-left, i.e. multiplication to the constant.
> Yes, and also note that it is masking the result by 0xfffc, to preserve
> the effect of any overflow in (x * y).
Right, such a mask was the result of missed brackets. Now (see
"[PATCH][v2] fork_init: fix division by zero" I've just posted) the
situation is better:
lis r9,0
rlwinm r29,r29,2,0,29
stw r29,0(r9)
I.e. the mask is 0xFFFFFFFC.
Regards, Yuri
--
Yuri Tikhonov, Senior Software Engineer
Emcraft Systems, www.emcraft.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists