lkml.org 
[lkml]   [2003]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] Fix do_div() for all architectures
Date
On Thursday 10 July 2003 22:19, Andrea Arcangeli wrote:

> > Without type based alias analysis, the compiler is forced to flush
> > all registers containing copies of memory objects before function
> > call and reloading values from memory afterwards.
>
> the kernel isn't complaint with the alias analysis, that's why it has
> to be turned off (-fnostrict-aliasing) or stuff would break.

Yeah, I noticed. Writing low-level code without breaking strict aliasing
rules can be quite difficult if you don't want to give up any of your clever
tricks. I have a set of macros for handling linked lists that I can't get to
compile without those damn alias warnings with the latest GCC versions.

Besides, pushing our philosophycal discussion forward, what the generic
do_div() is doing might be vary bad for performance. After extracting the
address of n, the compiler must conservatively assume that any following
pointer dereference or function call could alter the contents of n.

Since strict aliasing is turned off, access to the divisor will become
slow as hell. Almost as if it was declared volatile.

Ok, as Richard said, it's just the generic version for those who don't
care enough to write their own optimized version.

> > Boy, that's ugly! It's too bad C can't do it the Perl way:
> >
> > (n,rem) = __div64_32(n, base);
>
> or the python way:
>
> n, rem = __div64_32(n, base)
>
> ;)

You beat me!

--
// 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


-
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/

\
 
 \ /
  Last update: 2005-03-22 13:46    [W:0.061 / U:1.400 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site