From: Bernardo Innocenti <bernie@develer.com>
To: Andrew Morton <akpm@digeo.com>
Cc: linux-kernel@vger.kernel.org, torvalds@transmeta.com
Subject: Re: [PATCH] Kill div64.h dupes, parenthesize do_div() macro params
Date: Wed, 2 Jul 2003 05:15:17 +0200 [thread overview]
Message-ID: <200307020515.17722.bernie@develer.com> (raw)
In-Reply-To: <20030701193250.1cbd4af9.akpm@digeo.com>
On Wednesday 02 July 2003 04:32, you wrote:
> > By the way, what do you think about getting rid of the do_div()
> > macro altogether?
>
> I think we leave it the way it is because 64-bit divides are slow.
Wait! It's not documented at all that do_div() really does a
64bit/32bit division with 32bit remainder.
rem = (unsigned long)div % (unsigned)base;
div = (unsigned long)div / (unsigned)base;
What the generic version really does on 64bit architectures is a
64bit/32bit division, since "long" is usually 64bit.
What's worse, it has different semantics on different architectures:
alpha 64/32 -> 64q + 32r (generic)
arm 64/32 -> 64q + 32r (asm function call)
arm26 32/32 -> 32q + 32r (generic)
cris 32/32 -> 32q + 32r (generic)
h8300 32/32 -> 32q + 32r (generic)
i386 64/32 -> 64q + 32r (inline asm + C for 64bit case)
ia64 64/32 -> 64q + 32r (generic)
m68k 64/32 -> 64q + 32r (inline asm + C for 64bit case)
m68knommu 32/32 -> 32q + 32r (generic)
mips 64/32 -> 64q + 32r (inline asm)
mips64 64/32 -> 64q + 32r (generic)
parisc 64/32 -> 64q + 32r (inline C)
ppc 64/32 -> 64q + 32r (inline C + call for 64bit case)
ppc64 64/32 -> 64q + 32r (generic)
s390 64/32 -> 64q + 32r (generic for s390x, otherwise inline asm)
sh 32/32 -> 32q + 32r (generic)
sparc 32/32 -> 32q + 32r (generic)
sparc64 64/32 -> 64q + 32r (generic)
um like host
v850 32/32 -> 32q + 32r (generic)
x86_64 64/32 -> 64q + 32r (generic)
This table might be incorrect for some architectures I'm not familiar with.
> It is very easy to go accidentally adding 64-bit divides. Say, by
> changing the disk indexing to use 64-bit sector numbers as we did
> earlier in 2.5.
> By requiring an explicit do_div we are made aware of all those 64-bit
> divides and are made to think about them.
Nothing in div64.h prevents one from using the normal C syntax for
making divisions between long long numbers.
Besides, using the macros is much slower on some architectures. gcc cannot
see through blocks of inline asm, therefore it won't be able to do proper
constant propagation and dead code elimination.
> Why 64-bit divides in particular were victimised in this manner is a
> matter for speculation ;)
Let me guess: perhaps older gcc versions (pre 2.95) had some bugs
with long long and somone decided to fix the problem that way ;-)
--
// Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/ http://www.develer.com/
Please don't send Word attachments - http://www.gnu.org/philosophy/no-word-attachments.html
next prev parent reply other threads:[~2003-07-02 3:01 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-02 0:32 [PATCH] Kill div64.h dupes, parenthesize do_div() macro params Bernardo Innocenti
[not found] ` <20030701173612.280d1296.akpm@digeo.com>
2003-07-02 2:24 ` Bernardo Innocenti
2003-07-02 2:32 ` Andrew Morton
2003-07-02 3:15 ` Bernardo Innocenti [this message]
2003-07-02 5:12 ` Linus Torvalds
2003-07-02 7:53 ` Russell King
2003-07-02 8:14 ` Ian Molton
2003-07-02 5:09 ` Linus Torvalds
2003-07-02 7:02 ` Bernardo Innocenti
2003-07-02 7:54 ` Matti Aarnio
2003-07-02 3:36 ` Peter Chubb
2003-07-02 4:37 ` Bernardo Innocenti
2003-07-02 5:57 ` Andrea Arcangeli
2003-07-02 6:52 ` Bernardo Innocenti
2003-07-02 7:19 ` Andrea Arcangeli
2003-07-02 7:28 ` Bernardo Innocenti
2003-07-02 8:38 ` Andrea Arcangeli
2003-07-02 16:16 ` Linus Torvalds
2003-07-03 10:43 ` [PATCH] Fix do_div() for all architectures Bernardo Innocenti
2003-07-02 7:56 ` [PATCH] Kill div64.h dupes, parenthesize do_div() macro params Russell King
2003-07-02 5:06 ` Linus Torvalds
2003-07-02 14:23 ` Geert Uytterhoeven
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200307020515.17722.bernie@develer.com \
--to=bernie@develer.com \
--cc=akpm@digeo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.