On Wed, Jul 02, 2003 at 09:02:05AM +0200, Bernardo Innocenti wrote:
> On Wednesday 02 July 2003 07:09, Linus Torvalds wrote:
> > > Why 64-bit divides in particular were victimised in this manner is a
> > > matter for speculation ;)
> > Because gcc historically _cannot_ generate an efficient 64/32->64
> > divide. It ends up doing a full 64/64 divide thing.
> You're right here. I've been too quick in putting my faith in gcc ;-)
> Shouldn't we complain to the gcc people? The 64/32 division is a
> rather common operation in many applications besides the kernel, so
> you'd expect gcc to get it right without polluting every single
> project with reimplementations of do_div().
The thinking behind there has been:
a) arbitrary 64/32 division is _rare_, and shall be used only
in places that are non-critical to system speed
b) all places in filesystems, etc. should handle things by
doing these things with >> operators, which of course,
requires divisor to be power of two, and given as log2()
of the divisor.
c) to see usage of sub-optimal speed things, linkage against
libgcc is expressly forbidden in kernel.
Thus when you see that _divxyz3() can not be linked in, the
bug is in its _need_, and thus the code, not in lack of library
to supply it! The do_div64() is there to supply those non-
speed-critical rare uses.
At some platforms there is no way around this rule, but Linux's
primary platform is i386, and there those enforcements are shown.
To an extent, for example Alpha platform got several libgcc
functions copied in its arch library, to solve some unavoidable
builtin function needs, while still not blindly linking with
> // Bernardo Innocenti - Develer S.r.l., R&D dept.
> \X/ http://www.develer.com/
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 07 2003 - 22:00:15 EST